[{"data":1,"prerenderedAt":6549},["ShallowReactive",2],{"/en-us/blog/tags/features/":3,"navigation-en-us":19,"banner-en-us":437,"footer-en-us":449,"features-tag-page-en-us":661},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/features","tags",false,"",{"tag":9,"tagSlug":9},"features",{"template":11},"BlogTag","content:en-us:blog:tags:features.yml","yaml","Features","content","en-us/blog/tags/features.yml","en-us/blog/tags/features","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":433,"_type":13,"title":434,"_source":15,"_file":435,"_stem":436,"_extension":18},"/shared/en-us/main-navigation","en-us",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":374,"minimal":405,"duo":424},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/","gitlab logo","header",{"text":29,"config":30},"Get free trial",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Talk to sales",{"href":36,"dataGaName":37,"dataGaLocation":27},"/sales/","sales",{"text":39,"config":40},"Sign in",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,184,189,295,355],{"text":45,"config":46,"cards":48,"footer":71},"Platform",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"The most comprehensive AI-powered DevSecOps Platform",{"text":52,"config":53},"Explore our Platform",{"href":54,"dataGaName":47,"dataGaLocation":27},"/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":59,"config":60},"Meet GitLab Duo",{"href":61,"dataGaName":62,"dataGaLocation":27},"/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":67,"config":68},"Learn more",{"href":69,"dataGaName":70,"dataGaLocation":27},"/why-gitlab/","why gitlab",{"title":72,"items":73},"Get started with",[74,79,84],{"text":75,"config":76},"Platform Engineering",{"href":77,"dataGaName":78,"dataGaLocation":27},"/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Developer Experience",{"href":82,"dataGaName":83,"dataGaLocation":27},"/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":166},"Product",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/solutions/",[98,123,145],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/solutions/continuous-integration/",{"text":112,"config":113},"AI-Assisted Development",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":27,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":104,"dataGaLocation":27,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":27,"icon":130},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[132,135,140],{"text":133,"config":134},"Security & Compliance",{"href":128,"dataGaLocation":27,"dataGaName":133},{"text":136,"config":137},"Software Supply Chain Security",{"href":138,"dataGaLocation":27,"dataGaName":139},"/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"Compliance & Governance",{"href":143,"dataGaLocation":27,"dataGaName":144},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":146,"link":147,"items":152},"Measurement",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":27},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[153,157,161],{"text":154,"config":155},"Visibility & Measurement",{"href":150,"dataGaLocation":27,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Value Stream Management",{"href":160,"dataGaLocation":27,"dataGaName":158},"/solutions/value-stream-management/",{"text":162,"config":163},"Analytics & Insights",{"href":164,"dataGaLocation":27,"dataGaName":165},"/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab for",[169,174,179],{"text":170,"config":171},"Enterprise",{"href":172,"dataGaLocation":27,"dataGaName":173},"/enterprise/","enterprise",{"text":175,"config":176},"Small Business",{"href":177,"dataGaLocation":27,"dataGaName":178},"/small-business/","small business",{"text":180,"config":181},"Public Sector",{"href":182,"dataGaLocation":27,"dataGaName":183},"/solutions/public-sector/","public sector",{"text":185,"config":186},"Pricing",{"href":187,"dataGaName":188,"dataGaLocation":27,"dataNavLevelOne":188},"/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":282},"Resources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"View all resources",{"href":196,"dataGaName":192,"dataGaLocation":27},"/resources/",[198,231,254],{"title":199,"items":200},"Getting started",[201,206,211,216,221,226],{"text":202,"config":203},"Install",{"href":204,"dataGaName":205,"dataGaLocation":27},"/install/","install",{"text":207,"config":208},"Quick start guides",{"href":209,"dataGaName":210,"dataGaLocation":27},"/get-started/","quick setup checklists",{"text":212,"config":213},"Learn",{"href":214,"dataGaLocation":27,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Product documentation",{"href":219,"dataGaName":220,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Best practice videos",{"href":224,"dataGaName":225,"dataGaLocation":27},"/getting-started-videos/","best practice videos",{"text":227,"config":228},"Integrations",{"href":229,"dataGaName":230,"dataGaLocation":27},"/integrations/","integrations",{"title":232,"items":233},"Discover",[234,239,244,249],{"text":235,"config":236},"Customer success stories",{"href":237,"dataGaName":238,"dataGaLocation":27},"/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":27},"/blog/","blog",{"text":245,"config":246},"Remote",{"href":247,"dataGaName":248,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":250,"config":251},"TeamOps",{"href":252,"dataGaName":253,"dataGaLocation":27},"/teamops/","teamops",{"title":255,"items":256},"Connect",[257,262,267,272,277],{"text":258,"config":259},"GitLab Services",{"href":260,"dataGaName":261,"dataGaLocation":27},"/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":27},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Events",{"href":275,"dataGaName":276,"dataGaLocation":27},"/events/","events",{"text":278,"config":279},"Partners",{"href":280,"dataGaName":281,"dataGaLocation":27},"/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","Insights for the future of software development",{"altText":287,"config":288},"the source promo card",{"src":289},"/images/navigation/the-source-promo-card.svg",{"text":291,"config":292},"Read the latest",{"href":293,"dataGaName":294,"dataGaLocation":27},"/the-source/","the source",{"text":296,"config":297,"lists":299},"Company",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"About",{"href":305,"dataGaName":306,"dataGaLocation":27},"/company/","about",{"text":308,"config":309,"footerGa":312},"Jobs",{"href":310,"dataGaName":311,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":27},{"text":316,"config":317},"Leadership",{"href":318,"dataGaName":319,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":321,"config":322},"Team",{"href":323,"dataGaName":324,"dataGaLocation":27},"/company/team/","team",{"text":326,"config":327},"Handbook",{"href":328,"dataGaName":329,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Investor relations",{"href":333,"dataGaName":334,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Trust Center",{"href":338,"dataGaName":339,"dataGaLocation":27},"/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":27},"/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":27},"/company/contact/","newsletter",{"text":351,"config":352},"Press",{"href":353,"dataGaName":354,"dataGaLocation":27},"/press/","press",{"text":356,"config":357,"lists":358},"Contact us",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":34,"config":362},{"href":36,"dataGaName":363,"dataGaLocation":27},"talk to sales",{"text":365,"config":366},"Get help",{"href":367,"dataGaName":368,"dataGaLocation":27},"/support/","get help",{"text":370,"config":371},"Customer portal",{"href":372,"dataGaName":373,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Close",{"text":377,"link":378},"To search repositories and projects, login to",{"text":379,"config":380},"gitlab.com",{"href":41,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Suggestions",[386,388,392,394,398,402],{"text":56,"config":387},{"href":61,"dataGaName":56,"dataGaLocation":382},{"text":389,"config":390},"Code Suggestions (AI)",{"href":391,"dataGaName":389,"dataGaLocation":382},"/solutions/code-suggestions/",{"text":108,"config":393},{"href":110,"dataGaName":108,"dataGaLocation":382},{"text":395,"config":396},"GitLab on AWS",{"href":397,"dataGaName":395,"dataGaLocation":382},"/partners/technology-partners/aws/",{"text":399,"config":400},"GitLab on Google Cloud",{"href":401,"dataGaName":399,"dataGaLocation":382},"/partners/technology-partners/google-cloud-platform/",{"text":403,"config":404},"Why GitLab?",{"href":69,"dataGaName":403,"dataGaLocation":382},{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Start free trial",{"href":409,"dataGaName":32,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"Gitlab Icon",{"src":414,"dataGaName":415,"dataGaLocation":410},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"/images/brand/gitlab-logo-type.svg",{"text":420,"config":421},"Get Started",{"href":422,"dataGaName":423,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"Learn more about GitLab Duo",{"href":61,"dataGaName":428,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":430},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":432},{"src":418,"dataGaName":415,"dataGaLocation":410},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":438,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"config":444,"_id":446,"_type":13,"_source":15,"_file":447,"_stem":448,"_extension":18},"/shared/en-us/banner","GitLab Duo Agent Platform is now in public beta!",{"text":67,"config":441},{"href":442,"dataGaName":443,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"layout":445},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":450,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":451,"_id":657,"_type":13,"title":658,"_source":15,"_file":659,"_stem":660,"_extension":18},"/shared/en-us/main-footer",{"text":452,"source":453,"edit":459,"contribute":464,"config":469,"items":474,"minimal":649},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":454,"config":455},"View page source",{"href":456,"dataGaName":457,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":460,"config":461},"Edit this page",{"href":462,"dataGaName":463,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":465,"config":466},"Please contribute",{"href":467,"dataGaName":468,"dataGaLocation":458},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":470,"facebook":471,"youtube":472,"linkedin":473},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[475,498,555,584,619],{"title":45,"links":476,"subMenu":481},[477],{"text":478,"config":479},"DevSecOps platform",{"href":54,"dataGaName":480,"dataGaLocation":458},"devsecops platform",[482],{"title":185,"links":483},[484,488,493],{"text":485,"config":486},"View plans",{"href":187,"dataGaName":487,"dataGaLocation":458},"view plans",{"text":489,"config":490},"Why Premium?",{"href":491,"dataGaName":492,"dataGaLocation":458},"/pricing/premium/","why premium",{"text":494,"config":495},"Why Ultimate?",{"href":496,"dataGaName":497,"dataGaLocation":458},"/pricing/ultimate/","why ultimate",{"title":499,"links":500},"Solutions",[501,506,509,511,516,521,525,528,532,537,539,542,545,550],{"text":502,"config":503},"Digital transformation",{"href":504,"dataGaName":505,"dataGaLocation":458},"/topics/digital-transformation/","digital transformation",{"text":133,"config":507},{"href":128,"dataGaName":508,"dataGaLocation":458},"security & compliance",{"text":122,"config":510},{"href":104,"dataGaName":105,"dataGaLocation":458},{"text":512,"config":513},"Agile development",{"href":514,"dataGaName":515,"dataGaLocation":458},"/solutions/agile-delivery/","agile delivery",{"text":517,"config":518},"Cloud transformation",{"href":519,"dataGaName":520,"dataGaLocation":458},"/topics/cloud-native/","cloud transformation",{"text":522,"config":523},"SCM",{"href":118,"dataGaName":524,"dataGaLocation":458},"source code management",{"text":108,"config":526},{"href":110,"dataGaName":527,"dataGaLocation":458},"continuous integration & delivery",{"text":529,"config":530},"Value stream management",{"href":160,"dataGaName":531,"dataGaLocation":458},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":458},"/solutions/gitops/","gitops",{"text":170,"config":538},{"href":172,"dataGaName":173,"dataGaLocation":458},{"text":540,"config":541},"Small business",{"href":177,"dataGaName":178,"dataGaLocation":458},{"text":543,"config":544},"Public sector",{"href":182,"dataGaName":183,"dataGaLocation":458},{"text":546,"config":547},"Education",{"href":548,"dataGaName":549,"dataGaLocation":458},"/solutions/education/","education",{"text":551,"config":552},"Financial services",{"href":553,"dataGaName":554,"dataGaLocation":458},"/solutions/finance/","financial services",{"title":190,"links":556},[557,559,561,563,566,568,570,572,574,576,578,580,582],{"text":202,"config":558},{"href":204,"dataGaName":205,"dataGaLocation":458},{"text":207,"config":560},{"href":209,"dataGaName":210,"dataGaLocation":458},{"text":212,"config":562},{"href":214,"dataGaName":215,"dataGaLocation":458},{"text":217,"config":564},{"href":219,"dataGaName":565,"dataGaLocation":458},"docs",{"text":240,"config":567},{"href":242,"dataGaName":243,"dataGaLocation":458},{"text":235,"config":569},{"href":237,"dataGaName":238,"dataGaLocation":458},{"text":245,"config":571},{"href":247,"dataGaName":248,"dataGaLocation":458},{"text":258,"config":573},{"href":260,"dataGaName":261,"dataGaLocation":458},{"text":250,"config":575},{"href":252,"dataGaName":253,"dataGaLocation":458},{"text":263,"config":577},{"href":265,"dataGaName":266,"dataGaLocation":458},{"text":268,"config":579},{"href":270,"dataGaName":271,"dataGaLocation":458},{"text":273,"config":581},{"href":275,"dataGaName":276,"dataGaLocation":458},{"text":278,"config":583},{"href":280,"dataGaName":281,"dataGaLocation":458},{"title":296,"links":585},[586,588,590,592,594,596,598,603,608,610,612,614],{"text":303,"config":587},{"href":305,"dataGaName":298,"dataGaLocation":458},{"text":308,"config":589},{"href":310,"dataGaName":311,"dataGaLocation":458},{"text":316,"config":591},{"href":318,"dataGaName":319,"dataGaLocation":458},{"text":321,"config":593},{"href":323,"dataGaName":324,"dataGaLocation":458},{"text":326,"config":595},{"href":328,"dataGaName":329,"dataGaLocation":458},{"text":331,"config":597},{"href":333,"dataGaName":334,"dataGaLocation":458},{"text":599,"config":600},"Environmental, social and governance (ESG)",{"href":601,"dataGaName":602,"dataGaLocation":458},"/environmental-social-governance/","environmental, social and governance",{"text":604,"config":605},"Diversity, inclusion and belonging (DIB)",{"href":606,"dataGaName":607,"dataGaLocation":458},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":609},{"href":338,"dataGaName":339,"dataGaLocation":458},{"text":346,"config":611},{"href":348,"dataGaName":349,"dataGaLocation":458},{"text":351,"config":613},{"href":353,"dataGaName":354,"dataGaLocation":458},{"text":615,"config":616},"Modern Slavery Transparency Statement",{"href":617,"dataGaName":618,"dataGaLocation":458},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":620,"links":621},"Contact Us",[622,625,627,629,634,639,644],{"text":623,"config":624},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":458},{"text":365,"config":626},{"href":367,"dataGaName":368,"dataGaLocation":458},{"text":370,"config":628},{"href":372,"dataGaName":373,"dataGaLocation":458},{"text":630,"config":631},"Status",{"href":632,"dataGaName":633,"dataGaLocation":458},"https://status.gitlab.com/","status",{"text":635,"config":636},"Terms of use",{"href":637,"dataGaName":638,"dataGaLocation":458},"/terms/","terms of use",{"text":640,"config":641},"Privacy statement",{"href":642,"dataGaName":643,"dataGaLocation":458},"/privacy/","privacy statement",{"text":645,"config":646},"Cookie preferences",{"dataGaName":647,"dataGaLocation":458,"id":648,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,655],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":458},{"text":640,"config":654},{"href":642,"dataGaName":643,"dataGaLocation":458},{"text":645,"config":656},{"dataGaName":647,"dataGaLocation":458,"id":648,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":662,"featuredPost":6528,"totalPagesCount":6547,"initialPosts":6548},[663,688,711,731,754,772,794,814,836,858,879,901,921,941,962,983,1006,1028,1050,1070,1090,1110,1131,1150,1173,1194,1215,1236,1257,1277,1297,1319,1340,1362,1382,1404,1424,1444,1464,1482,1500,1521,1540,1560,1580,1599,1617,1637,1658,1679,1698,1719,1739,1759,1779,1799,1820,1840,1859,1880,1900,1921,1943,1963,1983,2004,2025,2047,2066,2085,2104,2124,2143,2163,2182,2203,2223,2245,2265,2284,2304,2324,2343,2361,2380,2400,2420,2440,2460,2481,2501,2520,2539,2558,2577,2596,2616,2636,2657,2678,2696,2715,2735,2755,2774,2793,2812,2830,2850,2869,2889,2909,2927,2948,2968,2987,3005,3023,3043,3065,3084,3106,3125,3145,3165,3184,3204,3225,3245,3264,3283,3303,3321,3341,3360,3380,3399,3418,3437,3456,3475,3494,3514,3534,3552,3572,3590,3611,3630,3651,3670,3690,3709,3729,3749,3768,3788,3807,3826,3846,3866,3885,3904,3924,3942,3961,3981,4000,4019,4039,4057,4078,4097,4117,4137,4156,4174,4193,4214,4233,4253,4273,4292,4311,4328,4348,4367,4386,4406,4426,4445,4465,4485,4504,4524,4543,4562,4581,4601,4619,4637,4657,4675,4693,4712,4731,4750,4768,4788,4807,4827,4848,4867,4887,4906,4924,4943,4962,4983,5002,5022,5041,5062,5081,5099,5117,5138,5157,5176,5196,5214,5233,5251,5269,5288,5306,5326,5345,5365,5383,5402,5421,5439,5457,5477,5496,5515,5535,5555,5574,5591,5609,5628,5646,5664,5682,5701,5720,5741,5761,5781,5801,5821,5842,5861,5880,5899,5918,5937,5956,5975,5994,6015,6034,6053,6072,6091,6111,6130,6150,6168,6187,6206,6225,6244,6264,6284,6302,6321,6340,6360,6378,6397,6415,6434,6453,6472,6490,6509],{"_path":664,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":673,"config":681,"_id":684,"_type":13,"title":685,"_source":15,"_file":686,"_stem":687,"_extension":18},"/en-us/blog/2019-year-in-review",{"title":666,"description":667,"ogTitle":666,"ogDescription":667,"noIndex":6,"ogImage":668,"ogUrl":669,"ogSiteName":670,"ogType":671,"canonicalUrls":669,"schema":672},"Highlights from 2019","2019 was a big year for GitLab! We look back on our achievements and growth from the past year.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665651/Blog/Hero%20Images/gitlab-holiday-2019-blog-cover.png","https://about.gitlab.com/blog/2019-year-in-review","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Highlights from 2019\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2020-01-09\",\n      }",{"title":666,"description":667,"authors":674,"heroImage":668,"date":676,"body":677,"category":678,"tags":679},[675],"Sara Kassabian","2020-01-09","\n\nAt GitLab, we’re going into 2020 with big energy. 🙌 Take a look at the 2019 milestones that laid a solid foundation for the company as we gear up for our IPO, planned for November 2020.\n\nIn 2019, our company more than doubled in size as we hired more talented folks, many of whom helped us move our product closer to being a true [multicloud solution](/topics/multicloud/). But the core of GitLab is our open source community, and in 2019 our community made plenty of valuable contributions in merge requests, feature fixes, and security checks! Explore some of the 2019 highlights for the GitLab product, community, and company.\n\n- [Product highlights](#product)\n- [Community highlights](#community)\n- [Company highlights](#company)\n\n\n## Product\n\nWe introduced many exciting new features to help our GitLab product better serve the needs of our users.\n\n### Multi-level child epics make project management a breeze\n\nBefore our 11.7 release, epics were limited to a two-level structure, but [in 11.7 we introduced multi-level child epics](/releases/2019/01/22/gitlab-11-7-released/#multi-level-child-epics), so you can now have an ancestor epic that contains up to five levels of child epics, as well as issues. This feature allows longer-term work strategies to be defined in ancestor epics, with strategy and deliverables being articulated in the lower tiers.\n\n\n\n### Auto-renew certs using Let’s Encrypt\n\nOne of our most highly-requested features was the introduction of a custom domain in GitLab pages [that automates HTTPS certificate renewals.](https://gitlab.com/gitlab-org/gitlab-foss/issues/28996) We delivered in 12.1 by integrating with Let’s Encrypt to transition this process from being manual to automated.\n\n### Totally buggin’: Track errors using Sentry\n\nUsing Sentry, our users can get more visibility into their entire stack, making it faster and easier to identify and remediate bugs in your code. [Read this blog post to dive deeper into how our integration with Sentry works](/blog/sentry-integration-blog-post/) or watch the video below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/KUHk1uuXWhA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Accelerate delivery using scoped labels\n\n[We created the scoped labels in 11.10](/blog/issue-labels-can-now-be-scoped/), making it simpler for users to customize workflows and accelerate delivery.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Great news, friends! Issue labels can now be scoped 😍\u003Cbr>\u003Cbr>Scoped Labels make it possible for teams to define a basic custom field that avoids confusion and cleans up issue lists ✔️\u003Ca href=\"https://t.co/U2T9BBIgBs\">https://t.co/U2T9BBIgBs\u003C/a>\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1141782522013134848?ref_src=twsrc%5Etfw\">June 20, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWatch the video below to see two use cases for scoped labels.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/4BCBby6du3c\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Merge trains keep your pipeline running\n\nBroken master is a developer’s worst enemy. We want our users to keep their pipelines moving, which is [why we created merge trains to keep your pipelines in the green](/blog/how-to-avoid-broken-master-with-pipelines-for-merge-requests/).\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">GitLab 12.1 released with Parallel Merge Trains, Merge Requests for Confidential Issues, Automated Let’s Encrypt certificates for GitLab Pages and much more! Enjoy! 🎉🙌🚀\u003Ca href=\"https://t.co/oRp7YF9mmo\">https://t.co/oRp7YF9mmo\u003C/a>\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1153319179266809857?ref_src=twsrc%5Etfw\">July 22, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n### CE and EE are in a single codebase\n\nIn August, [we officially migrated GitLab CE and GitLab EE to a single codebase](/blog/a-single-codebase-for-gitlab-community-and-enterprise-edition/). Keeping CE and EE in their own repositories made the development process more complex than was necessary, and by moving to a single codebase we simplified a problem that was becoming more complicated over time. A migration of this size wasn’t a simple process. [Our blog post dives into more detail about how we managed the migration](/blog/a-single-codebase-for-gitlab-community-and-enterprise-edition/).\n\n### Multicloud: This is the way\n\n#### Create and deploy to an EKS cluster\n\nGitLab is designed to be cloud-agnostic and in the spirit of multicloud, [we added an EKS integration to 12.5](/releases/2019/11/22/gitlab-12-5-released/#easily-create-and-deploy-to-an-eks-cluster). Now, users can create and deploy an EKS cluster by selecting the EKS option on the GitLab clusters page rather than having to build the integration from scratch. Watch the demo below to see how it works, or [read our documentation page](/releases/2019/11/22/gitlab-12-5-released/#easily-create-and-deploy-to-an-eks-cluster).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/DGvPEJUnXME\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Deploy to any cloud with GitLab CI/CD\n\nLearn more about how [GitLab CI/CD makes it possible to work with any cloud provider](/blog/gitlab-ci-cd-is-for-multi-cloud/). Study our [Guide to the Cloud](/resources/guide-to-the-cloud/) to become an expert in this topic.\n\nOther notable accomplishments include:\n\n*   [How our delivery team used the “boring solution” to migrate GitLab.com to CI/CD](/blog/gitlab-journey-to-cicd/).\n*   The introduction of [instance-level Kubernetes](https://docs.gitlab.com/ee/user/instance/clusters/).\n*   [DAG pipelines](/releases/2019/08/22/gitlab-12-2-released/#directed-acyclic-graphs-dag-for-gitlab-pipelines), which allow certain jobs to be completed in a non-consecutive order between stages.\n\n## Community\n\nIn 2019, GitLab benefitted from a highly engaged and collaborative community of contributors.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">While GitLab the company is growing quickly, we also have over 2500 contributors to GitLab from the wider community. \u003Cbr>\u003Cbr>Those contributors are providing over 200 contributions per month 💥\u003Ca href=\"https://twitter.com/hashtag/GitLabCommit?src=hash&ref_src=twsrc%5Etfw\">#GitLabCommit\u003C/a> \u003Ca href=\"https://t.co/qrSCCAKtpE\">pic.twitter.com/qrSCCAKtpE\u003C/a>\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1181889359492108295?ref_src=twsrc%5Etfw\">October 9, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n### Code contributions soared\n\nIn 2018, we had 447 code contributors create 1,608 merge requests. [Our numbers nearly doubled in 2019](https://gitlab.com/gitlab-com/www-gitlab-com/issues/6075#note_262597822) with an astounding 861 code contributors creating 2,437 merge requests (as of Dec. 18 2019). This marks more than 50% year-over-year growth in merged MRs for the wider community. We can’t wait to see what you folks have in store for us in 2020!\n\n## One million merge requests\n\nIn March 2019, our community broke more records by [submitting one million merge requests to GitLab.com](/blog/1-mil-merge-requests/) in a month. In fact, the number of new MRs per active user increased by 40% year-over-year (May 2019 vs. May 2018).\n\nThe majority of these contributions were part of private projects on GitLab.com, indicating there is the potential for _even more growth_ in the New Year if our contributors resolve to submit to some of our public projects too.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">\u003Ca href=\"https://t.co/C4mACZpLWf\">https://t.co/C4mACZpLWf\u003C/a> received a record 1 million merge requests in March 2019 😱\u003Ca href=\"https://t.co/Ii57tcSbq1\">https://t.co/Ii57tcSbq1\u003C/a>\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1136714388914757633?ref_src=twsrc%5Etfw\">June 6, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n### Our bug bounty program goes public\n\nOur bug bounty program launched in 2017 but was limited to the top 10% of HackerOne contributors. But in 2019, we elected to accelerate our efforts by making the program public – and our community did not disappoint! In the first seven weeks of our program, 42% of all reporters were first-time contributors and 64% of all of the reports we received came from folks new to the GitLab program.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">"We’re proud to see the benefits and value being generated by our bug bounty program and specifically our reporter community."\u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@GitLab\u003C/a> shares where their team is succeeding and focusing on improvement after moving to a public program. Fantastic job!\u003Ca href=\"https://t.co/iZ7rYqKmmq\">https://t.co/iZ7rYqKmmq\u003C/a> \u003Ca href=\"https://t.co/7WcrPWIMbQ\">pic.twitter.com/7WcrPWIMbQ\u003C/a>\u003C/p>— HackerOne (@Hacker0x01) \u003Ca href=\"https://twitter.com/Hacker0x01/status/1154159537596899329?ref_src=twsrc%5Etfw\">July 24, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nThank you to all of our reporters who helped make our product and platform even more secure.\n\n## Company\n\nJust like any start-up, GitLab came from humble beginnings, but in 2019 we’ve had more and more organizations adopt our tool as their all-in-one DevOps solution, and our team, funding, and corporate events have grown to accommodate the demand.\n\n### GitLab valued at $2.75 billion\n\nOur plans for a 2020 IPO are off to a roaring start! 🚀 In less than a year, we’ve more than doubled our company’s valuation from $1.1 billion in 2018 to $2.75 billion in 2019, after raising $268 million in September 2019. The money comes from existing funders such as Goldman Sachs as well as nine investors that are brand new to GitLab.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">GitLab (YC W15) hauls in $268M Series E on 2.75B valuation. Congrats to the GitLab team! \u003Ca href=\"https://t.co/8tfxnfu3YN\">https://t.co/8tfxnfu3YN\u003C/a>\u003C/p>— Y Combinator (@ycombinator) \u003Ca href=\"https://twitter.com/ycombinator/status/1173998823850545157?ref_src=twsrc%5Etfw\">September 17, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWe’ll be reinvesting all of that money into making our DevOps platform the best in its class, bolstering its monitoring, security, and planning capabilities.\n\n### We’re (always) hiring!\n\nSince the company launched in 2015, our headcount has more than doubled each year. At the end of January 2019, we had roughly 452 team members at GitLab but as of Jan. 9, 2020 we've grown to 1,137 team members and counting.\n\n\u003Cembed width=\"100%\" height=\"100%\" src=\"\u003C%= signed_periscope_url(chart: 6551186, dashboard: 503779, embed: 'v2') %>\">\n\nThe chart embedded above provides an interactive look at the growth of our company.\n\nExplosive growth in team members is exciting, but when it comes time to organize GitLab Contribute, our annual event for team members and the wider GitLab community, there simply is no cookie cutter solution for accommodating more than a thousand people. Learn more about [how our corporate events team has mastered the persistent challenge of scale](/blog/how-we-scaled-our-summits/) when planning GitLab Contribute.\n\n### GitLab heads down to the bayou\n\nSpeaking of Contribute... in May 2019, more than 500 GitLab team members met in New Orleans for our yearly summit. In between bites of beignets, our [GitLab team managed to meet, mingle, and ship lots of code](/blog/contribute-wrap-up/). If you missed us in NOLA, [catch us in Prague in 2020](/events/gitlab-contribute/).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/xdtPNXtkBhE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Just arrived at \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> \u003Ca href=\"https://twitter.com/hashtag/Contribute?src=hash&ref_src=twsrc%5Etfw\">#Contribute\u003C/a>! Everything is so amazing the energy is palpable. Thankful to the Contribute Team for all their hard work. Onwards to dinner and debriefing with ma peeps now! \u003Ca href=\"https://twitter.com/hashtag/NOLA?src=hash&ref_src=twsrc%5Etfw\">#NOLA\u003C/a> \u003Ca href=\"https://t.co/NmQ1PtLdkl\">pic.twitter.com/NmQ1PtLdkl\u003C/a>\u003C/p>— Priyanka Sharma (@pritianka) \u003Ca href=\"https://twitter.com/pritianka/status/1126243914762027008?ref_src=twsrc%5Etfw\">May 8, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n### The future of DevOps starts here\n\nThe best way to get a bird’s eye view into operations and decision-making at a rapidly growing company is to start from the highest point. GitLab pioneered a [new CEO shadow program](/handbook/ceo/shadow/) designed to help current and future leaders of GitLab get a comprehensive overview of how our organization operates. The task of a CEO shadow is simple: Join GitLab CEO [Sid Sijbrandij](/company/team/#sytses) at his home office in San Francisco and follow him to relevant meetings (digitally and IRL).\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">It's been an incredible experience getting to \u003Ca href=\"https://twitter.com/hashtag/contribute?src=hash&ref_src=twsrc%5Etfw\">#contribute\u003C/a> to \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a>! I ❤️ the story my graph tells. Now, which should I be most proud of: \u003Cbr>\u003Cbr>1. Becoming an intermediate-level Git user\u003Cbr>2. Participating in the CEO Shadow Program\u003Cbr>3. Taking 5 wks of vacation last year (clear winner) \u003Ca href=\"https://t.co/hN7kcxEHay\">pic.twitter.com/hN7kcxEHay\u003C/a>\u003C/p>— Erica Lindberg (@EricaLindberg_) \u003Ca href=\"https://twitter.com/EricaLindberg_/status/1125885748878536705?ref_src=twsrc%5Etfw\">May 7, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n[Erica Lindberg](/company/team/index.html#Lindberg), Global Content Manager, kicked off the CEO shadow program back in April 2019, but since then we’ve had a rotating schedule of CEO shadows that can drop in and drop out with ease and efficiency. [Get an inside look at the life of a CEO shadow by reading Erica's blog post](https://medium.com/gitlab-magazine/acquisitions-growth-curves-and-ipo-strategies-a-day-at-khosla-ventures-2762eb02c83a) and [learn more about the logistics and enrollment criteria](/handbook/ceo/shadow/#expenses-travel-and-lodging).\n\n### GitLab launches Commit, our first user conference\n\n🥳 Contribute is for our team members and community but [GitLab Commit](/events/commit/) is all about our users. We kicked off Commit in London and Brooklyn, inviting GitLab users to join us for a day of DevOps inspiration and learning.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003C!-- first tweet -->\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">Hot take: Auto \u003Ca href=\"https://twitter.com/hashtag/DevOps?src=hash&ref_src=twsrc%5Etfw\">#DevOps\u003C/a> cures shell script madness. And \u003Ca href=\"https://twitter.com/hashtag/GitOps?src=hash&ref_src=twsrc%5Etfw\">#GitOps\u003C/a> is just another way to say git is the source of truth. Wisdom from \u003Ca href=\"https://twitter.com/digitalocean?ref_src=twsrc%5Etfw\">@digitalocean\u003C/a> Developer Relations Mgr. \u003Ca href=\"https://twitter.com/eddiezane?ref_src=twsrc%5Etfw\">@eddiezane\u003C/a> & \u003Ca href=\"https://twitter.com/NMFinancial?ref_src=twsrc%5Etfw\">@NMFinancial\u003C/a> Senior Engineers Kyle Persohn, & Sean Corkum \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> Commit. \u003Ca href=\"https://t.co/4YI5WvMRzD\">pic.twitter.com/4YI5WvMRzD\u003C/a>\u003C/p>— The New Stack (@thenewstack) \u003Ca href=\"https://twitter.com/thenewstack/status/1174035665803186176?ref_src=twsrc%5Etfw\">September 17, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C!-- second tweet -->\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">I started speaking at conferences 11 years ago, and that's the time I had to wait for an opportunity to present my first talk in English. Thanks \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> for having me at \u003Ca href=\"https://twitter.com/hashtag/GitLabCommit?src=hash&ref_src=twsrc%5Etfw\">#GitLabCommit\u003C/a> last week, for amazing days in London. So much learning, new friends and good memories. \u003Ca href=\"https://t.co/OOchLmelpe\">pic.twitter.com/OOchLmelpe\u003C/a>\u003C/p>— Mario García (@mariogmd) \u003Ca href=\"https://twitter.com/mariogmd/status/1183450205280186368?ref_src=twsrc%5Etfw\">October 13, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C!-- third tweet -->\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">And that’s a wrap! Thank you, London for an amazing time at \u003Ca href=\"https://twitter.com/hashtag/GitLabCommit?src=hash&ref_src=twsrc%5Etfw\">#GitLabCommit\u003C/a>. We loved hosting our European \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> conference with you. Can’t wait to visit again and bring back some GitLab love to the land of the Brits 💜🇬🇧🧡 \u003Ca href=\"https://t.co/XLZiB2Dgm1\">pic.twitter.com/XLZiB2Dgm1\u003C/a>\u003C/p>— Priyanka Sharma (@pritianka) \u003Ca href=\"https://twitter.com/pritianka/status/1182254193324806151?ref_src=twsrc%5Etfw\">October 10, 2019\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nJoin us in San Francisco on January 14 for our first Commit event of 2020.\n\nThank you to all the folks that contributed to making 2019 such a smashing success and cheers to what’s in store for 2020!\n\nAlso, thank you to Social Marketing Manager [Wil Spillane](/company/team/#wspillane) for helping source the social media posts featured in this blog post.\n\n\n","news",[9,266,680],"inside GitLab",{"slug":682,"featured":6,"template":683},"2019-year-in-review","BlogPost","content:en-us:blog:2019-year-in-review.yml","2019 Year In Review","en-us/blog/2019-year-in-review.yml","en-us/blog/2019-year-in-review",{"_path":689,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":696,"config":705,"_id":707,"_type":13,"title":708,"_source":15,"_file":709,"_stem":710,"_extension":18},"/en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows",{"title":691,"description":692,"ogTitle":691,"ogDescription":692,"noIndex":6,"ogImage":693,"ogUrl":694,"ogSiteName":670,"ogType":671,"canonicalUrls":694,"schema":695},"3 GitLab features to level up DevSecOps workflows","Fix broken pipelines faster, better understand security vulnerabilities, and filter out false positives with our latest platform improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665762/Blog/Hero%20Images/blog-gl17-release-hero-17-0-93-1800x945-fy25__1_.png","https://about.gitlab.com/blog/3-gitlab-features-to-level-up-devsecops-workflows","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 GitLab features to level up DevSecOps workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"}],\n        \"datePublished\": \"2024-10-29\",\n      }",{"title":691,"description":692,"authors":697,"heroImage":693,"date":699,"body":700,"category":701,"tags":702},[698],"Salman Ladha","2024-10-29","Last month, we, along with the GitLab community, introduced more than 140 improvements to our AI-powered DevSecOps platform to help you build better and more secure software, faster. With that much product innovation, we know it can be difficult to keep track of the latest GitLab has to offer. So, each quarter, we’re spotlighting the most impactful capabilities to help you consolidate toolchains, boost development efficiency, and improve application security. Here are three new features [released in GitLab](https://about.gitlab.com/releases/categories/releases/) over the past few months that make an immediate impact on your software development.\n\n > Learn why GitLab was named a Leader in the [2024 Gartner® Magic Quadrant™ for DevOps Platforms](https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/) and the [2024 Gartner® Magic Quadrant™ for AI Code Assistants](https://about.gitlab.com/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/).\n\n## Root Cause Analysis: Diagnose broken pipelines faster\n\n[Developers spend less than a quarter of their time on code creation](https://about.gitlab.com/developer-survey/), according to our 2024 Global DevSecOps Survey. The bulk of their time is consumed by administrative tasks, planning, and troubleshooting — many of which can be accelerated with AI.\n\nFor example, diagnosing broken pipelines is a frustrating task for developers, which requires them to tediously scour through dense log files to identify the cause of the error. This often leads to trial-and-error fixes, sleuthing for solutions on Google, or asking a peer for support. This is a practical scenario where [GitLab Duo Root Cause Analysis](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/) can meaningfully help developers.\n\nRoot Cause Analysis analyzes log files to uncover the core issue behind an error message in a CI/CD pipeline. Not only does it provide teams with insight into what caused the issue, but it also suggests a fix to help resolve the issue faster.\n\nWith less time spent on troubleshooting, developers can focus on building differentiated products to help their organizations win.\n\nGitLab Duo Root Cause Analysis is available as a [GitLab Duo Enterprise add-on](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=JZSgd7GTTk4y6mre\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Vulnerability Explanation: Quickly understand security risks\n\nWe know that developers are playing [an even greater role in the remediation of security vulnerabilities](https://about.gitlab.com/developer-survey/). However, not every developer is well-versed in cybersecurity or has a working knowledge of the tactics, techniques, and procedures a threat actor will use to exploit an application. This creates a knowledge gap, which is exposed when vulnerabilities are uncovered.\n\n[GitLab Duo Vulnerability Explanation](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) bridges the knowledge gap between security and development teams. It gives developers a detailed description of the vulnerability infecting their code, real-world examples of how attackers can exploit the vulnerable code, and practical suggestions for remediation.\n\nWith this feature, you can level up your security skills, resolve vulnerabilities faster, and help create a proactive security culture — all while lightening the load on your security teams.\nGitLab Duo Vulnerability Explanation is available as a [GitLab Duo Enterprise add-on](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/MMVFvGrmMzw?si=Zsx-91078XSNNUSm\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Advanced SAST: Filter out the noise\n\nFalse positives are a [top frustration](https://about.gitlab.com/developer-survey/2024/security-compliance/) for both security and development teams. Unfortunately, this is a common complaint of traditional Static Application Security Testing (SAST). While SAST is great at integrating security early in the software development lifecycle, its value diminishes when it produces inaccurate results. “Drowning in a backlog of vulnerabilities” is a reality for many security and development teams, often resulting in tension between them.\n\n[Advanced SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/), our newest security scanner, uses a proprietary detection engine with rules informed by in-house security research to identify exploitable vulnerabilities. It delivers more accurate results, so security and development teams don’t have to sort through the noise of false-positive results, shortening triage time, improving development velocity, and decreasing friction between teams.\n\nAdvanced SAST is available in the [GitLab Ultimate tier](https://about.gitlab.com/pricing/ultimate/).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xDa1MHOcyn8?si=Ff4HjNpvv5eXsSNH\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Put these features to work today\n\nAt GitLab, we’re committed to making it easier for teams to build software, faster. Capabilities like GitLab Duo Root Cause Analysis, GitLab Duo Vulnerability Explanation, and GitLab Advanced SAST are just a few of the recent innovations we’ve delivered to help developers and security teams level up their DevSecOps workflows. To learn more, check out our [releases page](https://about.gitlab.com/releases/categories/releases/).\n\n> Get started with these new features today with [a free, 30-day trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F).","product",[701,9,703,704,108],"DevSecOps","security",{"slug":706,"featured":90,"template":683},"3-gitlab-features-to-level-up-devsecops-workflows","content:en-us:blog:3-gitlab-features-to-level-up-devsecops-workflows.yml","3 Gitlab Features To Level Up Devsecops Workflows","en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows.yml","en-us/blog/3-gitlab-features-to-level-up-devsecops-workflows",{"_path":712,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":713,"content":719,"config":725,"_id":727,"_type":13,"title":728,"_source":15,"_file":729,"_stem":730,"_extension":18},"/en-us/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab",{"title":714,"description":715,"ogTitle":714,"ogDescription":715,"noIndex":6,"ogImage":716,"ogUrl":717,"ogSiteName":670,"ogType":671,"canonicalUrls":717,"schema":718},"3 signs your team is ready to uplevel security controls in GitLab","Learn when to upgrade your GitLab security practices, from permission management to compliance adherence. Discover key features in GitLab Premium that scale with your team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664299/Blog/Hero%20Images/AdobeStock_887599633.jpg","https://about.gitlab.com/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"3 signs your team is ready to uplevel security controls in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Griffin\"}],\n        \"datePublished\": \"2024-12-18\",\n      }",{"title":714,"description":715,"authors":720,"heroImage":716,"date":722,"body":723,"category":704,"tags":724},[721],"Julie Griffin","2024-12-18","Most teams start with basic security practices, such as branch protection and simple access controls. But, there's often a moment when teams realize they need more. It could be when they land their first enterprise client, when they start handling sensitive data, or when they experience their first security incident.\n\nIf you’re unsure whether you’re ready to upgrade your security, here are a few signs you’ve outgrown your security needs:\n\n* You spend more time managing permissions than writing code.  \n* Security reviews create development bottlenecks.  \n* You can't definitively say who changed what and when.  \n* You're unsure if security policies are consistently followed.\n\nDo any of these signs resonate with you? Let's explore how teams typically mature their security practices as they grow. \n\n## 1. Your organization requires advanced access controls.\n\nManual permission management can be tedious and prone to errors. While it’s manageable for a team of three, it becomes much more complex as your team grows to 15, 30, or 100 developers. \n\nThe disadvantages of an intricate permission system are two-fold:\n\n1. It becomes more likely that accidental or unauthorized changes are made to critical parts of the codebase.  \n2. Managing complex permissions takes time that could be spent developing valuable software for the business. \n\n### Features that automate permission management\n\nScaling teams need features that automate permission management. GitLab Premium offers enterprise-grade Agile planning features that provide [organizational hierarchies](https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/), enabling advanced permissions management at the group or sub-group level. \n\nThis, alongside features like [Protected Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) and restricted push and merge access, save growing teams time while providing an additional layer of security. \n\n## 2. You need to build a robust review process.\n\nMany teams have senior developers review security-sensitive code. However, as your codebase expands, it becomes more challenging to ensure the right people are reviewing the right changes. This can lead to an elongated review process or the release of insecure code before it’s been reviewed by the right parties. \n\nWhen you notice security reviews becoming inconsistent or creating bottlenecks, it’s time to consider solutions that give you tighter control over your merge request pipelines. \n\n### Features that enhance the review process\n\nGitLab Premium helps teams mature beyond manual processes with capabilities like [Multiple Approvers](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) and [push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html). These features improve your code by ensuring it’s reviewed before it is merged, preventing errors from occurring late in the development process. It also requires higher levels of authorization and verification to those who push or commit to a git branch. \n\n## 3. You need to strengthen compliance adherence.\n\nWhen your team is small, you know who is working on what projects and when deployments will occur. But, as your team grows it becomes more challenging (if not impossible) to follow all code changes and activities. It’s also easy to lose sight of security policies and whether all team members are consistently following them.\n\nThese are signs that you need tools to help you track changes and ensure code quality meets regulatory requirements. \n\n### Features that improve compliance efforts\n\nWith GitLab Premium’s [Audit Events](https://docs.gitlab.com/ee/administration/audit_event_reports.html), you can track and review changes, such as who performed certain actions at what time within the repository. At the same time, [Code Quality Reports](https://docs.gitlab.com/ee/ci/testing/code_quality.html) can check for adherence to compliance standards. This can help teams more readily prove compliance while also quickly identifying and fixing problems within the code. \n\n## Scale your security efforts with GitLab Premium \n\nIf you’re experiencing security-related growing pains as your business scales, consider upleveling your security needs before it’s too late. Empower your team with features that prioritize security and compliance, and accelerate software delivery. \n\n> #### [Upgrade to GitLab Premium today!](https://about.gitlab.com/pricing/premium/why-upgrade/)",[704,478,9],{"slug":726,"featured":90,"template":683},"3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab","content:en-us:blog:3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab.yml","3 Signs Your Team Is Ready To Uplevel Security Controls In Gitlab","en-us/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab.yml","en-us/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab",{"_path":732,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":733,"content":739,"config":748,"_id":750,"_type":13,"title":751,"_source":15,"_file":752,"_stem":753,"_extension":18},"/en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"title":734,"description":735,"ogTitle":734,"ogDescription":735,"noIndex":6,"ogImage":736,"ogUrl":737,"ogSiteName":670,"ogType":671,"canonicalUrls":737,"schema":738},"4 ways to accelerate embedded development with GitLab","Learn how automated hardware testing, standard builds, collaborative workflows, and integrated compliance eliminate bottlenecks in firmware development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 ways to accelerate embedded development with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt DeLaney\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2025-06-05\",\n      }",{"title":734,"description":735,"authors":740,"heroImage":736,"date":743,"body":744,"category":701,"tags":745},[741,742],"Matt DeLaney","Darwin Sanoy","2025-06-05","Software in embedded systems is no longer just a part number — it's a critical differentiator. This shift has led to enormous complexity in the firmware running in our cars, airplanes, and industrial machines. The number of lines of code in the average car is expected to reach [650 million](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) by the end of 2025, up from 200 million just five years ago. In aerospace systems, the complexity of embedded software has nearly [doubled every four years](https://www.mckinsey.com/industries/aerospace-and-defense/our-insights/debugging-the-software-talent-gap-in-aerospace-and-defense) for the last several decades. \n\nTraditional embedded development approaches cannot effectively handle the software challenges of modern machines. This shortcoming slows engineers down, in part, by exacerbating challenges such as: \n\n* [Hardware testing bottlenecks](#challenge-1-hardware-testing-bottlenecks) \n* [Inconsistent build environments](#challenge-2-inconsistent-build-environments)\n* [Siloed development practices](#challenge-3-siloed-development-practices)\n* [Manual functional safety compliance processes](#challenge-4-manual-functional-safety-compliance-processes)\n\nEmbedded developers need a new approach to deal with the rapid increase in code. In this article, we’ll explain four ways you can use the GitLab AI-native DevSecOps platform to shorten feedback loops, work collaboratively and iteratively, and streamline compliance.\n\n## Challenge 1: Hardware testing bottlenecks\n\nUnlike enterprise software that can run on virtually any cloud server, embedded automotive software must be tested on specialized hardware that precisely matches production environments. Traditional hardware-in-the-loop (HIL) testing processes often follow this pattern:\n\n1. Developers write code for an embedded system (e.g., an electronic control unit)  \n2. They request access to limited, expensive hardware test benches (costing $500,000-$10M each)  \n3. They wait days or weeks for their scheduled access window  \n4. They manually deploy and test their code on physical hardware at their desks  \n5. They document results, pass the hardware to the next developer, and go to the back of the hardware testing queue\n\nThis process is extremely inefficient. Embedded developers may finish writing their code today and wait weeks to test it on a hardware target. By then, they've moved on to other tasks. This context switching drains productivity. Not only that, developers may wait weeks to learn they had a simple math error in their code. \n\n### Solution: Automated hardware allocation and continuous integration\n\nYou can streamline hardware testing through automation using the [GitLab On-Premises Device Cloud](https://gitlab.com/guided-explorations/embedded/ci-components/device-cloud), a CI/CD component. This lets you automate the orchestration of scarce hardware resources, turning a manual, time-intensive process into a streamlined, continuous workflow.\n\nThe On-Premises Device Cloud:\n\n1. Creates pools of shared hardware resources  \n2. Automatically — and exclusively — allocates hardware to a developer’s hardware testing pipeline tasks based on availability  \n3. Deploys and executes tests without manual intervention  \n4. Collects and reports results through integrated pipelines  \n5. Automatically deallocates hardware back into the “available” pool\n\nAfter submitting code, you’ll receive results in hours instead of days, often without ever physically touching the test hardware.\n\nWhat this video for an introduction to the GitLab On-Premises Device Cloud CI/CD Component to orchestrate the remote allocation of shared hardware for HIL:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ltr2CIM9Zag?si=NOij3t1YYz4zKajC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nYou can also adopt multi-pronged testing strategies that balance speed and quality. Bring the following embedded test patterns and environments into automated GitLab CI pipelines:\n\n* **Software-in-the-loop (SIL):** Testing on virtual hardware simulators for quicker initial feedback  \n* **Processor-in-the-loop (PIL):** Testing on representative processor hardware for faster feedback at a lower cost  \n* **Hardware-in-the-loop (HIL):** Testing on full production-equivalent hardware and test benches for late-stage verification\n\nBy automating the orchestration of these tests within CI pipelines, you’ll be able to identify issues earlier, iterate faster, and accelerate time to market.\n\n## Challenge 2: Inconsistent build environments\n\nAnother significant challenge in embedded development is build environment inconsistency. Embedded developers often manually execute builds on their local machines with varying configurations, compiler versions, and dependencies. Then they’ll paste the binaries from their local build to a shared codebase.\n\nThis approach creates several problems:\n\n* **Inconsistent outputs:** Builds for the same source code produce different results on different machines  \n* **\"Works on my machine\" syndrome:** Code that builds locally fails in shared environments  \n* **Poor traceability:** Limited audit trail of who built what and when  \n* **Knowledge silos:** Build expertise becomes concentrated in a few individuals\n\nThis approach can lead to errors, bottlenecks, and costly delays. \n\n### Solution: Standardized build automation\n\nYou can address these challenges by implementing standardized build automation within CI/CD pipelines in GitLab. This approach creates consistent, repeatable, container-based build environments that eliminate machine-specific variations. Through the use of special Embedded Gateway Runner provisioning scripts, containers can interface with hardware for flashing and port monitoring for automated testing.\n\nKey elements of this solution include:\n\n* **Lifecycle managed environments:** Define complex embedded simulation environments as code; automatically deploy environments for testing and destroy them afterward  \n* **Containerization:** Use Docker containers to ensure identical build environments  \n* **Automated dependency management:** Control and version all dependencies  \n* **Central build execution:** Run builds on shared infrastructure rather than local machines\n\n> Follow this tutorial to learn [how to automate embedded software builds within a GitLab CI pipeline](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci/-/blob/main/TUTORIAL2.md%20).\n\nBy standardizing and automating the build process, you can ensure that every build follows the same steps with the same dependencies, producing consistent outputs regardless of who initiated it. This not only improves quality but also democratizes the build process, enabling more team members to participate without specialized knowledge.\n\n## Challenge 3: Siloed development practices\n\nEnterprise development teams have widely adopted collaborative practices such as DevOps, underpinned by shared source code management (SCM) and continuous integration/continuous delivery (CI/CD) systems. Embedded developers, on the other hand, have historically worked alone at their desks. There are valid technical reasons for this. \n\nFor example, consider hardware virtualization, which is a key enabler of DevOps automation. The industry has been slower to virtualize the massive range of specialized processors and boards used in embedded systems. This is due in large part to the difficulties of virtualizing production real-time systems and the associated lack of economic incentives. Compare that to cloud virtualization which has been commoditized and benefited enterprise SaaS development for over a decade.\n\nMany providers are now embracing virtualization-first for the sake of speeding up embedded development. If teams fail to adopt virtual testing options, however, their silos will remain and negatively impact the business through: \n\n* **Knowledge fragmentation**: Critical insights remain scattered across individuals and teams  \n* **Redundant development**: Multiple teams solve identical problems, creating inconsistencies  \n* **Late-stage discovery during big-bang integrations**: Problems are found late in the process when multiple developers integrate their code at once, when errors are more costly to fix  \n* **Stifled innovation**: Solutions from one domain rarely influence others, hampering the development of new product ideas\n\n### Solution: Collaborative engineering through a unified platform\n\nAn important step in breaking down these silos is to standardize embedded development around GitLab’s unified DevSecOps platform. In this regard, GitLab is aligned with the shift of embedded systems toward more consolidated, shared platforms on embedded devices. GitLab enables:\n\n* **Shared visibility:** Make all code, Issues, and documentation visible across teams  \n* **Collaborative workflows:** Enable peer review and knowledge sharing through merge requests  \n* **Centralized knowledge:** Maintain a single source of truth for all development artifacts  \n* **Asynchronous collaboration:** Allow teams to work together across different locations and time zones\n\nHuman-AI agent collaboration is a fundamental ingredient to fueling the customer-facing innovations that digital natives and established embedded brands desire. GitLab enables human-AI collaboration as well. By creating transparency across the development lifecycle, GitLab changes embedded development from an isolated activity to a collaborative practice. Engineers can see each other's work in progress, learn from collective experiences, and build upon shared solutions.\n\nWatch this presentation from Embedded World Germany 2025, which explains the power of embedded developers collaborating and sharing “work in progress”. The demo portion from 24:42 to 36:51 shows how to integrate HIL into a GitLab CI pipeline and enable collaborative development.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/F_rlOyq0hzc?si=eF4alDY6HK98uZPj\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPerhaps most importantly, by achieving greater collaboration through DevSecOps, teams can unlock embedded systems innovations that would otherwise remain hidden. Indeed, collaboration fuels innovation. [One study](https://www.sciencedirect.com/science/article/abs/pii/S0749597800928887), for example, found that group brainstorming, when properly structured, can lead to more innovative and creative outcomes than individuals working alone. Collaborative development is crucial in the race to develop software-defined products. \n\n## Challenge 4: Manual functional safety compliance processes\n\nEmbedded systems in the automotive and aerospace industries must comply with rigorous functional safety standards, including ISO 26262, MISRA C/C++, DO-178C, and DO-254. Traditional compliance approaches involve manual reviews, extensive documentation, and separate verification activities that occur late in the development cycle. This often creates security review bottlenecks. When specialized embedded security and code quality scanners detect vulnerabilities in a developer’s code, the scan issue gets added to a pile of other issues that haven’t been resolved. Developers can’t integrate their code, and security personnel need to wade through a backlog of code violations. This creates delays and makes compliance more difficult. \n\nSome of the challenges can best be summed up as: \n\n* **Late-stage compliance issues**: Problems discovered after development is complete  \n* **Documentation burden**: Extensive manual effort to create and maintain compliance evidence  \n* **Process bottlenecks**: Serial compliance activities that block development progress  \n* **Expertise dependence**: Reliance on limited specialists for compliance activities\n\nAs a result, teams often need to choose between velocity and compliance — a precarious trade-off in safety-critical systems.\n\n### Solution: Automated functional safety compliance workflow building blocks\n\nRather than treating security and compliance as post-development verification activities, you can codify compliance requirements and enforce them automatically through [customizable frameworks in GitLab](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/). To do this for functional safety standards, in particular, you can integrate GitLab with specialized embedded tools, which provide the depth of firmware scanning required by functional safety standards. Meanwhile, GitLab provides automated compliance checks, full audit trails, and merge request gating — all features needed to support a robust continuous compliance program. \n\nThis integrated approach includes:\n\n* **Compliance-as-code:** Define compliance requirements as automated checks  \n* **Integrated specialized tools:** Connect tools like CodeSonar into the DevSecOps platform for automotive-specific compliance  \n* **Continuous compliance verification:** Verify requirements throughout development  \n* **Automated evidence collection:** Gather compliance artifacts as a by-product of development\n\nWatch this video to learn how to use Custom Compliance Frameworks in GitLab to create your own compliance policies. You can create compliance policies related to any standard (e.g., ISO 26262) and automatically enforce those policies in GitLab.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/S-FQjzSyVJw?si=0UdtGNuugLPG0SLL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nBy shifting compliance left and embedding it within normal development workflows, you can maintain safety standards without sacrificing velocity. Automated checks catch issues early when they're easier and less expensive to fix, while continuous evidence collection reduces the documentation burden.\n\n## Realizing the power of embedded DevOps\n\nEmbedded development is changing fast. Teams that remain stuck in manual processes and isolated workflows will find themselves increasingly left behind, while those that embrace automated, collaborative practices will define the future of software-defined smart systems.\n\nExplore our [Embedded DevOps Workshop](https://gitlab.com/guided-explorations/embedded/workshops/embedded-devops-workshop-refactoring-to-ci) to start automating embedded development workflows with GitLab, or [watch this presentation from GitLab's Field Chief Cloud Architect](https://content.gitlab.com/viewer/0a35252831bd130f879b0725738f70ed) to learn how leading organizations are bringing hardware-in-the-loop testing into continuous integration workflows to accelerate embedded development.\n\n## Learn more\n\n- [Why GitLab Premium with Duo for embedded systems development?](https://content.gitlab.com/viewer/438451cba726dd017da7b95fd0fb1b59)\n- [Why GitLab Ultimate with Duo for embedded systems development?](https://content.gitlab.com/viewer/87f5104c26720e2c0d73a6b377522a44)\n- [More embedded development systems presentations from GitLab](https://content.gitlab.com/viewer/e59c40099d5e3c8f9307afb27c4a923f)",[478,746,9,747],"tutorial","embedded DevOps",{"slug":749,"featured":6,"template":683},"4-ways-to-accelerate-embedded-development-with-gitlab","content:en-us:blog:4-ways-to-accelerate-embedded-development-with-gitlab.yml","4 Ways To Accelerate Embedded Development With Gitlab","en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab.yml","en-us/blog/4-ways-to-accelerate-embedded-development-with-gitlab",{"_path":755,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":756,"content":762,"config":766,"_id":768,"_type":13,"title":769,"_source":15,"_file":770,"_stem":771,"_extension":18},"/en-us/blog/5-gitlab-premium-features-to-help-your-team-scale",{"title":757,"description":758,"ogTitle":757,"ogDescription":758,"noIndex":6,"ogImage":759,"ogUrl":760,"ogSiteName":670,"ogType":671,"canonicalUrls":760,"schema":761},"5 GitLab Premium features to help your team scale","Explore how GitLab Premium boosts team collaboration and productivity, enabling organizations to scale with streamlined workflows and advanced capabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665151/Blog/Hero%20Images/blog-image-template-1800x945__27_.png","https://about.gitlab.com/blog/5-gitlab-premium-features-to-help-your-team-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 GitLab Premium features to help your team scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julie Griffin\"}],\n        \"datePublished\": \"2024-12-18\",\n      }",{"title":757,"description":758,"authors":763,"heroImage":759,"date":722,"body":764,"category":701,"tags":765},[721],"As development teams grow, what once worked for a small team often becomes a bottleneck. Code standards become inconsistent, operational silos develop, and technical debt accumulates faster. What was a well-oiled machine is now dysfunctional as more team members, projects, and tools are added on. \n\nMany teams experience these challenges as they grow, but how you handle and address these growing pains can save you time, energy, and money in the long run. In this article, we’ll explore the common pitfalls growing teams face and how successful organizations address them. \n\n## 1. Consistent code quality\n\nOne of the challenges growing teams face is [maintaining consistent code quality](https://about.gitlab.com/blog/transform-code-quality-and-compliance-with-automated-processes/) as more developers contribute to the codebase. Quality issues that were once caught quickly now take longer to identify and fix.\n\nSuccessful teams address these challenges through automated code analysis throughout their development workflow. Instead of relying solely on manual reviews, they implement systems to identify potential issues and enforce consistent standards before code even reaches human reviewers. This approach helps detect complexity issues early and flags potential security vulnerabilities, allowing reviewers to focus on more strategic aspects of code review.\n\n### Features that maintain consistent code quality\n\n* Start by automating code analysis in your workflow. With GitLab Premium, you can set up [Code Quality Reports](https://docs.gitlab.com/ee/ci/testing/code_quality.html) in your merge requests. This helps catch issues early by analyzing code complexity and quality before review begins. For example, when a developer submits changes that might increase technical debt, the report will flag these issues automatically.  \n* Next, establish automated quality standards. Configure Quality Gates to define what \"good code\" means for your team. This could include test coverage requirements, complexity limits, or specific coding patterns. When code doesn't meet these standards, merges are automatically blocked until issues are addressed.  \n* Finally, prevent issues before they even reach review. [Push Rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) let you enforce standards right at commit time. You might start with simple rules like requiring certain commit message formats, then gradually add more sophisticated checks as your team adapts.\n\n## 2. Improve collaboration and productivity\n\nThe priorities for startups are often budget and speed, but as businesses grow, tracking DevSecOps workflows across a patchwork of tools can actually deter productivity.\n\nDisparate tools cause developers to context switch between platforms, decreasing focus time and development speed. Toolchain sprawl also limits visibility among teams, creating operational silos that lead to miscommunication.\n\nTo address these challenges, teams often turn to Agile solutions to help with project management, align timelines, and improve cross-team collaboration. When combined with a DevSecOps environment, [Agile](https://about.gitlab.com/topics/agile-devsecops/) creates a powerful system for software development that marries the iterative Agile approach with a security-first mindset. \n\n### Features that improve collaboration and productivity\n\n* With GitLab Premium, teams can access enterprise-grade Agile tools within their DevSecOps platforms. You can start by creating [groups and projects](http://%20epics), assigning team members roles, and determining their level of permission.   \n* [Milestones](https://docs.gitlab.com/ee/user/project/milestones/) and [epics](https://docs.gitlab.com/ee/user/group/epics/index.html) help teams plan large-scale initiatives across multiple projects to track dependencies, progress, and align on deliverables. This gives everyone clear visibility into the process.  \n* Then, dive deeper into each task with [issues](https://docs.gitlab.com/ee/user/project/issue_board.html). With customizable workflows and multi-assignee capabilities, teams can visualize project progress, dynamically adjust priorities, and collaborate on issue resolution.\n\n## 3. Increase deployment velocity\n\nIn theory, teams should be more productive as they scale. However, if tools aren’t updated to accommodate a growing team, the CI/CD pipeline can feel clunky and inefficient. \n\nTeams turn to tools that help them automate and optimize the [CI/CD pipeline](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/). By automating components like code reviews, merge trains, and permissions, teams can streamline the CI/CD pipeline and improve deployment speed. \n\n### Features that increase deployment velocity\n\nGitLab Premium offers advanced features that help you build, maintain, deploy, and monitor complex pipelines. Increase the speed of deployment through the CI/CD pipeline with more control over code reviews and merge request processes.\n\n* You can automate the merging of multiple changes in a controlled sequence with Merge Trains. This reduces integration issues and improves deployment efficiency.  \n* Gain visibility into whether your jobs passed or failed with Multi-Project Pipeline Graphs. Access all related jobs for a single commit and the net result of each stage of your pipeline to quickly see what failed and fix it.  \n* Team leaders can access comprehensive insights and make data-informed decisions with [Code Review Analytics](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html) that provide detailed metrics and merge request analytics. This helps teams identify bottlenecks, optimize review cycles, and establish data-driven process improvements. \n\n## 4. Enhance security and compliance controls\n\nWithout rigorous governance policies, inefficient and insecure code may be released. With smaller companies, security reviews are often manual and the reviews often take a backseat to speed. This can lead to teams releasing incorrect or unsafe code to production causing costly delays. \n\nTo [evolve their security practices](https://about.gitlab.com/blog/3-signs-your-team-is-ready-to-uplevel-security-controls-in-gitlab/), teams turn to stricter access controls, a more refined and delineated review process, as well as features that enable teams to review and track changes. \n\n### Features that enhance security and compliance controls\n\n* With stricter access controls, such as [Protected Branches and Protected Environments](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html), you can restrict push and merge access, securing those areas from unwanted changes by unauthorized users.  \n* To strengthen security review processes, implement [Multiple Approvers in Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/). This requires team members to review and approve code changes before they’re pushed through.  \n* Review who performed a certain action within the repository and at what time with [Audit Events](https://docs.gitlab.com/ee/administration/audit_event_reports.html). By tracking changes, you’re able to stay on top of compliance requirements. \n\n## 5. Avoid downtime and delays\n\nWithout support, teams are left to troubleshoot issues themselves. This can lead to major delays or periods of downtime where the company is unable to deliver value. As companies grow, this downtime becomes more and more detrimental to the business. \n\nIt’s important to evaluate what your company’s threshold is for downtime. When the value of the downtime outweighs the cost of support, it’s time to scale your DevSecOps platform to meet those needs. \n\n### Support services to avoid downtime and delays\n\nWith GitLab Premium, customers of both SaaS and self-managed instances have access to [Priority Support](https://about.gitlab.com/support/#priority-support). GitLab customer support offers Tiered Support response times, ranging from emergency to low-impact services, and can help you resolve issues quickly, minimizing downtime and disruption to your development cycle.\n\nPlus, for self-managed customers moving to Premium, GitLab offers support for any issues that occur after implementation and upgrade assistance to provide a seamless transition. \n\n## Build today, scale for tomorrow with GitLab Premium\n\nInstead of struggling with the challenges that growing teams face, scale your DevSecOps platform with GitLab Premium. \n\nGitLab Premium provides teams with the project management, pipeline tools, security, and support needed to work efficiently and effectively across the software development lifecycle. \n\n> #### Learn more about [why you should upgrade to GitLab Premium](https://about.gitlab.com/pricing/premium/why-upgrade/).",[478,9],{"slug":767,"featured":6,"template":683},"5-gitlab-premium-features-to-help-your-team-scale","content:en-us:blog:5-gitlab-premium-features-to-help-your-team-scale.yml","5 Gitlab Premium Features To Help Your Team Scale","en-us/blog/5-gitlab-premium-features-to-help-your-team-scale.yml","en-us/blog/5-gitlab-premium-features-to-help-your-team-scale",{"_path":773,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":774,"content":780,"config":788,"_id":790,"_type":13,"title":791,"_source":15,"_file":792,"_stem":793,"_extension":18},"/en-us/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive",{"title":775,"description":776,"ogTitle":775,"ogDescription":776,"noIndex":6,"ogImage":777,"ogUrl":778,"ogSiteName":670,"ogType":671,"canonicalUrls":778,"schema":779},"5 things to know from our LinkedIn Live Security Deep Dive","Security experts and product leaders offered their take on new developments in application security and the latest from GitLab 17.5.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","https://about.gitlab.com/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 things to know from our LinkedIn Live Security Deep Dive\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2024-10-28\",\n      }",{"title":775,"description":776,"authors":781,"heroImage":777,"date":783,"body":784,"category":704,"tags":785},[782],"Fatima Sarah Khalid","2024-10-28","[GitLab's October LinkedIn Live broadcast](https://www.linkedin.com/feed/update/urn:li:activity:7255246777077936128) brought together security experts and product leaders to discuss the latest developments in application security and highlight key features from the GitLab 17.5 release. In case you missed it, here's what you need to know.\n\n## 1. Software is moving faster and security is struggling to keep up\nDevelopment teams are shipping at record speeds, but their security counterparts are finding it difficult to meet that pace. Our [DevSecOps survey](https://about.gitlab.com/developer-survey/) revealed that 66% of companies are shipping code twice as fast as last year, while 55% of security teams are finding vulnerabilities after code is merged to test environments. With 80% of top data breaches coming from application layer attacks, this gap must be addressed.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023367700?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Market Insights\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 2. Advanced SAST is getting smarter\nGitLab's new [Advanced SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/) capabilities are a game-changer for security testing. Built on technology acquired from Oxeye, Advanced SAST offers cross-file and cross-function scanning with taint analysis. The star feature is a code flow view that lets developers trace vulnerabilities from source to sink, making it easier to understand and fix security issues.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023369304?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Advanced SAST\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> Learn even more with our [Advanced SAST tutorial](https://about.gitlab.com/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai/).\n\n## 3. Accidental secret commits are a thing of the past\nGitLab's new [secret push protection feature](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/) stops sensitive information from reaching your GitLab repository by checking the contents of each commit. Instead of dealing with the aftermath of exposed credentials, the system catches secrets before they're committed, saving security teams countless hours of remediation work.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023370222?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Secret Push\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 4. AI is a security catalyst\nAI isn't just for code completion anymore. GitLab Duo has evolved to understand merge requests and provide contextual security assistance. With the new Quick Chat feature (accessible via Alt+C), developers can get security insights without leaving their editor.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023385333?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"AI Security\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## 5. Static reachability reduces security noise\nThe new static reachability feature for Python and Java helps teams focus on vulnerabilities that matter. By identifying which dependencies are actually used in your code, it reduces false positives and helps teams prioritize real security threats.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1023388137?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Static Reachability\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Watch on-demand now\n\n[Watch the full \"Security Deep Dive\" recording](https://www.linkedin.com/feed/update/urn:li:activity:7255246777077936128) to see these features in action and hear more insights from our security experts.\n\nBe sure to follow GitLab on LinkedIn to be notified of our monthly broadcasts and get more insights and the latest news about AI-powered DevSecOps.",[786,704,787,703,9],"AI/ML","webcast",{"slug":789,"featured":90,"template":683},"5-things-to-know-from-our-linkedin-live-security-deep-dive","content:en-us:blog:5-things-to-know-from-our-linkedin-live-security-deep-dive.yml","5 Things To Know From Our Linkedin Live Security Deep Dive","en-us/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive.yml","en-us/blog/5-things-to-know-from-our-linkedin-live-security-deep-dive",{"_path":795,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":796,"content":801,"config":808,"_id":810,"_type":13,"title":811,"_source":15,"_file":812,"_stem":813,"_extension":18},"/en-us/blog/5-videos-and-interactive-tours-to-learn-gitlab-duo-fast",{"title":797,"description":798,"ogTitle":797,"ogDescription":798,"noIndex":6,"ogImage":777,"ogUrl":799,"ogSiteName":670,"ogType":671,"canonicalUrls":799,"schema":800},"5 videos and interactive tours to learn GitLab Duo fast","Get to know GitLab Duo's capabilities and benefits, and use these visual learning tools to understand how to incorporate AI throughout your software development lifecycle.\n","https://about.gitlab.com/blog/5-videos-and-interactive-tours-to-learn-gitlab-duo-fast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 videos and interactive tours to learn GitLab Duo fast\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2024-08-28\",\n      }",{"title":797,"description":798,"authors":802,"heroImage":777,"date":804,"body":805,"category":806,"tags":807},[803],"Cesar Saavedra","2024-08-28","GitLab Duo is a suite of AI-powered features designed to assist DevSecOps teams throughout the software development lifecycle. Integrated seamlessly into the GitLab platform, GitLab Duo leverages artificial intelligence to enhance productivity, improve code quality, and streamline various development and security processes. This article introduces you to GitLab Duo's capabilities and benefits, and lists five videos and interactive tours to help you learn how to incorporate this AI powerhouse into your own workflow.\n\nIn this article:\n- [GitLab Duo features](#gitlab-duo-features)\n- [Benefits of GitLab Duo](#benefits-of-gitlab-duo)\n- [5 videos and interactive tours](#5-videos-and-interactive-tours-to-learn-gitlab-duo)\n\n## GitLab Duo features\n\n[GitLab Duo](https://about.gitlab.com/gitlab-duo/) offers a wide range of AI-powered capabilities to help you ship more secure software faster and deliver better results for your customers.\n\n### Feature development\n\n- **Code Suggestions:** Helps developers write code more efficiently by generating code and showing suggestions as they type.\n\n- **Chat:** A conversational interface that answers questions and assists with various tasks throughout the development process.\n\n- **Code Explanation:** Helps understand selected code by providing clear explanations.\n\n- **GitLab Duo for the CLI:** Helps discover or recall Git commands when and where you need them.\n\n-  **Merge Commit Message Generation:** Helps merge more quickly by generating meaningful commit messages.\n\n- **Test Generation:** Helps catch bugs early by automatically generating tests for selected code.\n\n### Securing applications\n\n- **Vulnerability Explanation:** Shows information about security vulnerabilities in code and explains how to fix them.\n\n- **Vulnerability Resolution:** Helps resolve a vulnerability by generating a merge request that addresses it. (Beta)\n\n### Facilitating collaboration\n\n- **AI Impact Dashboard:** Measures the effectiveness and impact of AI on software development lifecycle metrics.\n\n- **Code Review Summary:** Makes merge request handover to reviewers easier by summarizing all the comments in a merge request review. (Experimental)\n\n- **Discussion Summary:** Helps everyone get up to speed by summarizing lengthy conversations in an issue. (Beta)\n\n- **Issue Description Generation:** Helps populate an issue quickly by generating a more in-depth description based on a short summary. (Experimental)\n\n- **Merge Request Summary:** Helps populate a merge request more quickly by generating a description based on the code changes. (Beta)\n\n- **Product Analytics:** Processes and responds to questions about your application's usage data.\n\n### Advanced troubleshooting\n\n- **Root Cause Analysis:** Helps determine the cause of CI/CD job failures by analyzing logs.\n\nThese components work together to provide comprehensive AI-assisted support throughout the software development lifecycle.\n\n## Benefits of GitLab Duo\n\nGitLab Duo offers numerous benefits to development teams and organizations. By integrating AI-powered assistance throughout the development lifecycle, it helps increase productivity, improve code quality, and enhance security. \nDevelopers can write code faster, understand complex codebases more easily, and catch potential issues earlier in the development process.\n\nGitLab Duo also helps streamline collaboration, speed up code reviews, and provide valuable insights into the impact of AI on ROI metrics. These benefits contribute to faster delivery of high-quality, secure software.\n\n## 5 videos and interactive tours to learn GitLab Duo\n\nTo help you get acquainted with GitLab Duo and its capabilities quickly, we've compiled a list of five videos and interactive tours. These visual learning tools provide an in-depth look at an array of GitLab Duo features and demonstrate how they can be integrated into your development workflow.\n\n__1. GitLab Duo Overview__\n\nThis comprehensive video introduces the core concepts of GitLab Duo and showcases its integration within the GitLab platform.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/o2xmLTV1y0I?si=90yPCHS_x2zSBAqe\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n__2. Code Suggestions in Action__\n\nAn interactive tour demonstrating how GitLab Duo Code Suggestions works in real-time, helping developers write code more efficiently.\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\n__3. Vulnerability Resolution Walkthrough__\n\nThis video guide takes you through the process of using GitLab Duo to understand and resolve security vulnerabilities in your code.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VJmsw_C125E?si=cUmRiQNJbrv5Yd9D\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n__4. Chat Demo__\n\nAn interactive session showing how developers can leverage GitLab Duo Chat to get answers, generate code, and solve problems throughout the development process.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"\nhttps://www.youtube.com/embed/RJezT5_V6dI?si=QomHCGUKstnAwplM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n__5. AI Impact Dashboard Tutorial__\n\nA detailed look at how to use and interpret the AI Impact Dashboard to measure the effectiveness of GitLab Duo in your development processes.\n\n\u003Ca href=\"https://gitlab.navattic.com/ai-impact\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175921/Blog/hn7gflmqswrjb33unuja.png\" alt=\"GitLab Duo AI Impact Dashboard cover image\">\u003C/a>\u003C/p>\n\n## Get started with GitLab Duo today\n\nThese videos and interactive tours offer practical insights into how GitLab Duo can enhance your development workflow. By exploring these resources, you'll gain a better understanding of how to leverage AI-powered assistance to improve productivity, code quality, and security in your projects.\n\n> #### Become a GitLab Duo expert: [Start your free, 60-day trial today!](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)\n\n## Read more\n- [10 best practices for using AI-powered GitLab Duo Chat](https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/)\n- [Refactor code into modern languages with AI-powered GitLab Duo](https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/)\n- [Developing GitLab Duo blog series](https://about.gitlab.com/blog/developing-gitlab-duo-series/)\n- [Mastering GitLab admin tasks with GitLab Duo Chat](https://about.gitlab.com/blog/mastering-gitlab-admin-tasks-with-gitlab-duo-chat/)","ai-ml",[786,9,746,701],{"slug":809,"featured":6,"template":683},"5-videos-and-interactive-tours-to-learn-gitlab-duo-fast","content:en-us:blog:5-videos-and-interactive-tours-to-learn-gitlab-duo-fast.yml","5 Videos And Interactive Tours To Learn Gitlab Duo Fast","en-us/blog/5-videos-and-interactive-tours-to-learn-gitlab-duo-fast.yml","en-us/blog/5-videos-and-interactive-tours-to-learn-gitlab-duo-fast",{"_path":815,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":816,"content":822,"config":830,"_id":832,"_type":13,"title":833,"_source":15,"_file":834,"_stem":835,"_extension":18},"/en-us/blog/a-go-micro-language-framework-for-building-dsls",{"title":817,"description":818,"ogTitle":817,"ogDescription":818,"noIndex":6,"ogImage":819,"ogUrl":820,"ogSiteName":670,"ogType":671,"canonicalUrls":820,"schema":821},"Lingo: A Go micro language framework for building Domain Specific Languages","Design, build and integrate your own Domain Specific Language with Lingo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682320/Blog/Hero%20Images/typeset.png","https://about.gitlab.com/blog/a-go-micro-language-framework-for-building-dsls","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lingo: A Go micro language framework for building Domain Specific Languages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2022-05-26\",\n      }",{"title":817,"description":818,"authors":823,"heroImage":819,"date":825,"body":826,"category":827,"tags":828},[824],"Julian Thome","2022-05-26","\n\nDomain Specific Languages (DSL) are small, focused languages with a narrow\ndomain of applicability. DSLs are tailored towards their target domain so that\ndomain experts can formalize ideas based on their knowledge and background.\n\nThis makes DSLs powerful tools that can be used for the purpose of increasing\nprogrammer efficiency by being more expressive in their target\ndomain, compared to general purpose languages, and by providing concepts to\nreduce the cognitive load on their users.\n\nConsider the problem of summing up the balances of different bank accounts in a\nCSV file. A sample CSV file is provided in the example below where the first\ncolumn contains the name of the account holder and the second column contains\nthe account balance.\n\n``` csv\nname, balance\nLisa, 100.30\nBert, 241.41\nMaria, 151.13\n```\n\nYou could solve the problem of summing up balances by using a general-purpose\nlanguage such as [Ruby](https://www.ruby-lang.org/en/) as in the code snippet\nbelow. Apart from the fact that the code below is not very robust, it contains\na lot of boilerplate that is irrelevant to the problem at hand, i.e., summing\nup the account balances.\n\n``` ruby\n#!/usr/bin/env ruby\n\nexit(1) if ARGV.empty? || !File.exist?(ARGV[0])\n\nsum = 0\nFile.foreach(ARGV[0]).each_with_index do |line, idx|\n  next if idx == 0\n  sum += Float(line.split(',')[1])\nend\n\nputs sum.round(2)\n```\n\nBelow is an example [AWK script](https://en.wikipedia.org/wiki/AWK) that solves\nthe same problem. AWK is a DSL that was specifically designed to address\nproblems related to text-processing.\n\n``` awk \n#!/usr/bin/awk -f\n\nBEGIN{FS=\",\"}{sum+=$2}END{print sum}\n```\n\nThe Ruby program has a size of 208 characters, whereas the AWK program has a size of 56. The AWK program is roughly 4x smaller than its Ruby\ncounterpart. In addition, the AWK implementation is more robust by being less\nprone to glitches that may appear in the CSV file (e.g., empty newlines,\nwrongly formatted data-fields). The significant difference in terms of size\nillustrates that DSLs, by being more focused on solving specific problems, can\nmake their users more productive by sparing them the burden to write\nboilerplate code and narrowing the focus of the language on the problem at\nhand.\n\nSome popular DSLs most software developers use on a regular basis include\n[Regular Expressions](https://en.wikipedia.org/wiki/Regular_expression) for\npattern matching, AWK for text\ntransformation or [Standard Query Language](https://en.wikipedia.org/wiki/SQL)\nfor interacting with databases.\n\n## Challenges when designing Domain Specific Languages\n\nPrototyping, designing and evolving DSLs is a\nchallenging process. In our experience this is an exploratory cycle where you\nconstantly prototype ideas, incorporate them into the language, try them out in\nreality, collect feedback and improve the DSL based on the feedback. \n\nWhen designing a DSL, there are many components that have to be implemented and\nevolved. At a very high level there are two main components: the language\nlexer/parser and the language processor. The lexer/parser\nis the component that accepts input as per the language definition which is\nusually specified specified by means of a language grammar. The parsing/lexing\nphase produces a syntax tree which is then passed onto the language processor.\nA language processor evaluates the syntax tree. In the example we saw earlier,\nwe ran both the Ruby and AWK interpreters providing our scripts and the CSV\nfile as input; both interpreters evaluated the scripts and this evaluation\nyielded the sum of all the account balances as a result.\n\nTools such as parser generators can significantly reduce the effort of\nlexer/parser development by means of code generation. Sophisticated DSL\nframeworks such as [JetBrains MPS](https://www.jetbrains.com/mps/) or\n[Xtext](https://www.eclipse.org/Xtext/) also provide features that help\nimplement custom language support in IDEs. However, if present at all, the\nsupport for building the language processors is usually limited to generating\nplaceholders functions or boilerplate code for the language components that\nhave to be filled-in by the DSL developer. Moreover, such large and powerful DSL\nframeworks usually have a fairly steep learning curve so that they are probably\na better fit for more sophisticated DSLs as opposed to small, easily\nembeddable, focused languages, which we refer to as _micro languages_.\n\nIn some situations, it may be worth considering working around these problems\nby just relying on standard data exchange formats such as `.toml`, `.yaml` or\n`.json` as a means of configuration. Similar to the parser generators, using\nsuch a format may relieve some of the burden when it comes to parser\ndevelopment effort. However, this approach does not help when it comes to the\nimplementation of the actual language processor. In addition, most standard data\nexchange formats are inherently limited to representing data in terms of simple\nconcepts (such as lists, dictionaries, strings and numbers). This limitation\ncan lead to bloated configuration files quickly as shown in the following\nexample.\n\nImagine the development of a calculator that operates on integers using\nmultiplication `*`, addition `+`. When using a data-description language like\nYAML in the example below, you can see that even a small simple term like `1 + 2 * 3 + 5` \ncan be hard to reason about, and by adding more terms the configuration\nfile would get bloated quickly.\n\n``` yaml\nterm:\n  add: \n    - 1\n    - times:\n      - 2\n      - 3\n    - 5\n```\n\nThis blog post is focused on the design of micro languages. The core idea is to\nprovide a simple, extensible language core that can be easily extended with\ncustom-types and custom functions; the language can evolve without having\nto touch the parser or the language processor. Instead, the DSL designer can\njust focus on the concepts that ought to be integrated into the DSL by\nimplementing interfaces and \"hooking\" them into the core language\nimplementation.\n\n## Lingo: A micro language framework for Go\n\nAt GitLab, Go is one of our main programming languages and some of the tools we\ndevelop required their own, small, embeddable DSLs so that users could properly\nconfigure and interact with them. \n\nInitially, we tried to integrate already existing, embeddable and expandable\nlanguage implementations. Our only condition was that they had to be\nembeddable natively into a Go application. We explored several great free and\nopen-source (FOSS) projects such as [go-lua](https://github.com/Shopify/go-lua)\nwhich is Lua VM implemented in Go, [go-yeagi](https://github.com/traefik/yaegi)\nwhich provides a Go interpreter with which Go can be used as a scripting\nlanguage or [go-zygomys](https://github.com/glycerine/zygomys) which is a LISP\ninterpreter written in Go. However, these packages are essentially modules to\nintegrate general-purpose languages on top of which a DSL could be built. These modules ended up being fairly complex. In contrast, we wanted to have basic support to design, implement, embed and evolve DSLs natively into a Go\napplication that is flexible, small, simple/easy to grasp, evolve and\nadapt.\n\nWe were looking for a micro language framework with the properties listed below:\n\n1. Stability: Changes applied to the DSL should neither require any changes to the core lexer/parser implementation nor to the language processor implementation.\n1. Flexibility/Composability: New DSL concepts (data-types, functions) can be integrated via a simple plug-in mechanism.\n1. Simplicity: the language framework should have just\nenough features to provide a foundation that is powerful enough to implement\nand evolve a custom DSL. In addition, the whole implementation of the micro\nlanguage framework should be in pure Go so that it is easily embeddable in Go\napplications.\n\nSince none of the available FOSS tools we looked at was able to\nfulfill all of those requirements, we developed our own micro language framework\nin Go called Lingo which stands for \"**L**ISP-based Domain Specific Languages\n(DSLs) **in Go**\". Lingo is completely FOSS and available in the [Lingo Git repository](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nunder the free and open source space of the [Vulnerability Research Team](https://about.gitlab.com/handbook/engineering/development/sec/secure/vulnerability-research/).\n\n[Lingo](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nprovides a foundation for building DSLs based on Symbolic Expressions (S-expressions), i.e.,\nexpressions provided in the form of nested lists `(f ...)` where `f` can be\nconsidered as the placeholder that represents the function symbol. Using this format,\nthe mathematical term we saw earlier could be written as S-expression `(+ 1 (* 2 3) 5)`. \n\nS-expressions are versatile and easy to process due to their uniformity. In\naddition, they can be used to represent both code and data in a consistent\nmanner.\n\nWith regards to the Stability, Flexibility and Composability properties, \n[Lingo](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nprovides a simple plug-in mechanism to add new functions as well as types\nwithout having to touch the core parser or language processor. From the\nperspective of the S-expression parser, the actual function symbol is\nessentially irrelevant with regards to the S-expression parsing. The language processor is just evaluating S-expressions and dispatching the execution to the interface implementations. These implementations are provided by the plug-ins based on the function symbol.\n\nWith regards to Simplicity, the Lingo code base is roughly 3K lines of pure Go code including the lexer/parser, an\nengine for code transformation, and the interpreter/evaluator. The small size\nshould make it possible to understand the entirety of the implementation.  \n\nReaders that are interested in the technical details of\nLingo itself can have a look at the\n[README.md](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo/-/blob/main/README.md)\nwhere the implementation details and the used theoretical foundations are explained.\nThis blog post focuses on how\nLingo can be used to build a DSL from scratch.\n\n## Using Lingo to design a data generation engine\n\nIn this example we are designing a data-generation engine in Go using\nLingo as a foundation. Our data generation engine may be used to generate structured input\ndata for fuzzing or other application contexts. This example illustrates how\nyou can use Lingo to create a language and the corresponding language\nprocessor. Going back to the example from the beginning, let us assume we would\nlike to generate CSV files in the format we saw at the beginning covering\naccount balances.\n\n``` csv\nname, balance\nLisa, 100.30\nBert, 241.41\nMaria, 151.13\n```\n\nOur language includes the following functions:\n\n1. `(oneof s0, s1, ..., sN)`: randomly returns one of the parameter strings `sX` (0 \u003C= X \u003C= N).\n1. `(join e0, e1, ..., eN)`: joins all argument expressions and concatenates their string representation `eX` (0 \u003C= X \u003C= N).\n1. `(genfloat min max)`: generates a random float number X (0 \u003C= X \u003C= N) and returns it.\n1. `(times num exp)`: repeats the pattern generated by exp num times.\n\nFor this example we are using\nLingo to build the language and the language processor to automatically generate CSV\noutput which we are going to feed back into the Ruby and AWK programs we saw in\nthe introduction in order to perform a stress test on them. \n\nWe refer to our new language/tool as _Random Text Generator_ (RTG) `.rtg`.\nBelow is a sample script `script.rtg` we'd like our program to digest in order\nto randomly generate CSV files. As you can see in the example below, we are\njoining sub-strings starting with the CSV header `name, balance`\nafter which we randomly generate 10 lines of names and balance amounts. In\nbetween, we also randomly generate some empty lines.\n\n```\n(join \n  (join \"name\" \",\" \"balance\" \"\\n\")\n  (times 10 \n    '(join \n      (oneof \n        \"Jim\" \n        \"Max\" \n        \"Simone\" \n        \"Carl\" \n        \"Paul\" \n        \"Karl\" \n        \"Ines\" \n        \"Jane\" \n        \"Geralt\" \n        \"Dandelion\" \n        \"Triss\" \n        \"Yennefer\" \n        \"Ciri\") \n      \",\" \n      (genfloat 0 10000) \n      \"\\n\" \n      (oneof \"\" \"\\n\"))))\n```\n\nOur engine takes the script above written in RTG and generates random CSV\ncontent. Below is an example CSV file generated from this script.\n\n``` csv\nname,balance\nCarl,25.648205\nInes,11758.551\n\nCiri,13300.558\n...\n```\n\nFor the remainder of this section, we explore how we can implement a\ndata generation engine based on Lingo. The implementation of RTG requires\nthe two main ingredients: (1) a float data type and a result object to integrate a float\nrepresentation and (2) implementations for the `times`, `oneof`, `genfloat` and\n`join` functions.\n\n### Introducing a float data type and result objects\n\nLingo differentiates between data types and result objects. Data types indicate how data is\nmeant to be used and result objects are used to pass intermediate results\nbetween functions where every result has a unique type. In the code snippet\nbelow, we introduce a new `float` data type. The comments in the code snippet below\nprovide more details.\n\n``` go \n// introduce float type\nvar TypeFloatId, TypeFloat = types.NewTypeWithProperties(\"float\", types.Primitive)\n// introduce token float type for parser\nvar TokFloat = parser.HookToken(parser.TokLabel(TypeFloat.Name))\n\n// recognize (true) as boolean\ntype FloatMatcher struct{}\n\n// this function is used by the parser to \"recognize\" floats as such\nfunc (i FloatMatcher) Match(s string) parser.TokLabel {\n  if !strings.Contains(s, \".\") {\n    return parser.TokUnknown\n  }\n\n  if _, err := strconv.ParseFloat(s, 32); err == nil {\n\treturn TokFloat.Label\n  }\n\n  return parser.TokUnknown\n}\nfunc (i FloatMatcher) Id() string {\n  return string(TokFloat.Label)\n}\n\nfunc init() {\n  // hook matcher into the parser\n  parser.HookMatcher(FloatMatcher{})\n}\n```\n\nIn addition, we also require a result object which we can use to pass around\nfloat values. This is an interface implementation where most of the functions names\nare self-explanatory. The important bit is the `Type` function\nthat returns our custom `float` type we introduced in the last snippet.\n\n``` go\ntype FloatResult struct{ Val float32 }\n// deep copy\nfunc (r FloatResult) DeepCopy() eval.Result { return NewFloatResult(r.Val) }\n// returns the string representation of this result type\nfunc (r FloatResult) String() string {\n  return strconv.FormatFloat(float64(r.Val), 'f', -1, 32)\n}\n// returns the data type for this result type\nfunc (r FloatResult) Type() types.Type   { return custtypes.TypeFloat }\n// call-back that is cleaned up when the environment is cleaned up\nfunc (r FloatResult) Tidy()              {}\n\nfunc (r FloatResult) Value() interface{} { return r.Val }\nfunc (r *FloatResult) SetValue(value interface{}) error {\n  boolVal, ok := value.(float32)\n  if !ok {\n    return fmt.Errorf(\"invalid type for Bool\")\n  }\n  r.Val = boolVal\n  return nil\n}\nfunc NewFloatResult(value float32) *FloatResult {\n  return &FloatResult{\n    value,\n  }\n}\n```\n\n### Implementing the DSL functions\n\nSimilar to the data type and return object, implementation of a DSL function is\nas simple as implementing an interface. In the example below we implement the\n`genfloat` function as an example. The most important parts are the `Symbol()`,\n`Validate()` and `Evaluate()` functions. The `Symbol()` function returns the\nfunction symbol which is `genfloat` in this particular case. \n\nBoth, the `Validate()` and `Evaluate()` functions take the environment `env`\nand the parameter Stack `stack` as the parameter. The environment is used to store\nintermediate results which is useful when declaring/defining variables. The `stack` includes the input parameters of the function. For\n`(genfloat 0 10000)`, the stack would consist out of two `IntResult` parameters\n`0` and `10000` where `IntResult` is a standard result object already provided by the\ncore implementation of Lingo. `Validate()` makes sure that the parameter can be\ndigested by the function at hand, whereas `Evaluate()` actually invokes the\nfunction. In this particular case, we are generating a float value within the\nspecified range and return the corresponding `FloatResult`.\n\n``` go\ntype FunctionGenfloat struct{}\n\n// returns a description of this function\nfunc (f *FunctionGenfloat) Desc() (string, string) {\n  return fmt.Sprintf(\"%s%s %s%s\",\n    string(parser.TokLeftPar),\n    f.Symbol(),\n\t\"min max\",\n\tstring(parser.TokRightPar)),\n\t\"generate float in rang [min max]\"\n}\n\n// this is the symbol f of the function (f ...)\nfunc (f *FunctionGenfloat) Symbol() parser.TokLabel {\n  return parser.TokLabel(\"genfloat\")\n}\n\n// validates the parameters of this function which are passed in\nfunc (f *FunctionGenfloat) Validate(env *eval.Environment, stack *eval.StackFrame) error {\n  if stack.Size() != 2 {\n    return eval.WrongNumberOfArgs(f.Symbol(), stack.Size(), 2)\n  }\n\n  for idx, item := range stack.Items() {\n    if item.Type() != types.TypeInt {\n\t  return eval.WrongTypeOfArg(f.Symbol(), idx+1, item)\n\t}\n  }\n  return nil\n}\n\n// evaluates the function and returns the result\nfunc (f *FunctionGenfloat) Evaluate(env *eval.Environment, stack *eval.StackFrame) (eval.Result, error) {\n  var result float32\n  rand.Seed(time.Now().UnixNano())\n  for !stack.Empty() {\n    max := stack.Pop().(*eval.IntResult)\n    min := stack.Pop().(*eval.IntResult)\n\n\tminval := float32(min.Val)\n\tmaxval := float32(max.Val)\n\n\tresult = minval + (rand.Float32() * (maxval - minval))\n  }\n\n  return custresults.NewFloatResult(result), nil\n}\n\nfunc NewFunctionGenfloat() (eval.Function, error) {\n  fun := &FunctionGenfloat{}\n  parser.HookToken(fun.Symbol())\n  return fun, nil\n}\n```\n\n### Putting it all together\n\nAfter implementing all the functions, we only have to register/integrate them\n(`eval.HookFunction(...)`) so that Lingo properly resolves them when processing\nthe program. In the example below, we are registering all of the custom functions\nwe implemented, i.e., `times`, `oneof`, `join`, `genfloat`. The `main()`\nfunction in the example below includes the code required to evaluate our script\n`script.rtg`.\n\n``` go\n// register function\nfunc register(fn eval.Function, err error) {\n  if err != nil {\n    log.Fatalf(\"failed to create %s function %s:\", fn.Symbol(), err.Error())\n  }\n  err = eval.HookFunction(fn)\n  if err != nil {\n    log.Fatalf(\"failed to hook bool function %s:\", err.Error())\n  }\n}\n\nfunc main() {\n  // register custom functions\n  register(functions.NewFunctionTimes())\n  register(functions.NewFunctionOneof())\n  register(functions.NewFunctionJoin())\n  register(functions.NewFunctionGenfloat())\n  register(functions.NewFunctionFloat())\n  if len(os.Args) \u003C= 1 {\n    fmt.Println(\"No script provided\")\n    os.Exit(1)\n  }\n  // evaluate script\n  result, err := eval.RunScriptPath(os.Args[1])\n  if err != nil {\n    fmt.Println(err.Error())\n    os.Exit(1)\n  }\n\n  // print output\n  fmt.Printf(strings.ReplaceAll(result.String(), \"\\\\n\", \"\\n\"))\n\n  os.Exit(0)\n}\n```\n\nThe source code for RTG is available\n[here](https://gitlab.com/julianthome/lingo-example). You can find information\nabout how to build and run the tool in the\n[README.md](https://gitlab.com/julianthome/lingo-example/-/blob/main/README.md).\n\nWith approx. 300 lines of Go code, we have successfully designed a language and\nimplemented a language processor. We can now use RTG to test the robustness of\nthe Ruby (`computebalance.rb`) and AWK scripts (`computebalance.awk`) we used\nat the beginning to sum up account balances. \n\n``` bash\ntimeout 10 watch -e './rtg script.rtg > out.csv && ./computebalance.awk out.csv'\ntimeout 10 watch -e './rtg script.rtg > out.csv && ./computebalance.rb out.csv'\n```\n\nThe experiment above shows that the files generated by means of RTG can be\nproperly digested by the AWK script which is much more robust since it can cope\nwith the all generated CSV files. In contrast, executing of the Ruby script\nresults in errors because it cannot properly cope with newlines as they appear\nin the CSV file.\n\nCover image by [Charles Deluvio](https://unsplash.com/@kristianstrand) on [Unsplash](https://unsplash.com/photos/p8gzCnZf39k)\n{: .note}\n\n","open-source",[829,746,9],"collaboration",{"slug":831,"featured":6,"template":683},"a-go-micro-language-framework-for-building-dsls","content:en-us:blog:a-go-micro-language-framework-for-building-dsls.yml","A Go Micro Language Framework For Building Dsls","en-us/blog/a-go-micro-language-framework-for-building-dsls.yml","en-us/blog/a-go-micro-language-framework-for-building-dsls",{"_path":837,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":838,"content":844,"config":852,"_id":854,"_type":13,"title":855,"_source":15,"_file":856,"_stem":857,"_extension":18},"/en-us/blog/a-look-ahead-for-gitlab-cicd",{"title":839,"description":840,"ogTitle":839,"ogDescription":840,"noIndex":6,"ogImage":841,"ogUrl":842,"ogSiteName":670,"ogType":671,"canonicalUrls":842,"schema":843},"New up and coming GitLab CI/CD Features","DAG, Multi-project Pipelines, Runner Setup for Kubernetes and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666889/Blog/Hero%20Images/photo-cicd12xlookahead.jpg","https://about.gitlab.com/blog/a-look-ahead-for-gitlab-cicd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New up and coming GitLab CI/CD Features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-08-07\",\n      }",{"title":839,"description":840,"authors":845,"heroImage":841,"date":847,"body":848,"category":849,"tags":850},[846],"Jason Yavorska","2019-08-07","\n_Since this blog post was published, we have updated our planning based on emerging priorities and customer need. For the latest on what we've got coming next, check out our [CI/CD direction page](/direction/ops/), which is always current._\n\nHey everyone, [Jason Yavorska](https://gitlab.com/jyavorska) here – product manager for CI/CD at GitLab. Back in June we\nreached the mid-point of the year and we're heading into our big 12.0 release, so I took the opportunity to\nsummarize some of the [highlights of our 11.x series of releases](/blog/look-back-on-11-11-cicd/).\nHopefully you had a chance to read it, if not, please take a moment to scan through and I bet you'll find an\ninteresting feature or two that can help improve your pipelines.\n\nWe're a couple of releases into the 12.x cycle now and I couldn't wait to share some\nof the things that we're looking forward to delivering the remainder of this year. Some of the features I am most excited about include DAG, a directed acyclic graph that makes it easy to run pipeline steps out of order, expanding our pipelines for merge requests/results feature to also work with forks, as well as making multi-project pipelines a Core feature. With about 3.44M job instances per week/13.76M per month, GitLab CI is growing at a rapid rate to help our customers and users with their deployment needs. Read on below to learn more about all of the exciting CI/CD features in the 12.0 series of releases that will help you to deploy your code quickly.\n\n## What's recent\n\nIn 12.0, we released [visual reviews](https://docs.gitlab.com/ee/ci/review_apps/index.html#visual-reviews),\nwhich allows users to provide issue feedback directly from the review apps that\nyour pipelines create. This makes it easy for all your team members to provide accurate\nfeedback on the changes you're making. We also added [collapsible job logs](https://docs.gitlab.com/ee/ci/pipelines/index.html#expand-and-collapse-job-log-sections),\nmaking output of pipelines easier to use, and enabled [multiple extends](https://docs.gitlab.com/ee/ci/yaml/#extends)\nfor pipeline jobs to make templatizing behaviors in your configuration even easier.\n\n![Visual Review Apps](https://about.gitlab.com/images/12_0/visual-review-apps.png \"Visual Review Apps\"){: .shadow.medium.center}\n\n[Visual Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html#visual-reviews) were released in GitLab 12.0\n{: .note .text-center}\n\nIn 12.1, we delivered [parallel execution for merge trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html),\nexpanding on our [pipelines for merged results](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html)\nto make it very easy to automatically build and test a series of merge requests heading\ninto the same target branch in a fast, safe, and efficient way. For GitLab Pages we also\nadded [automatic HTTPS certificate renewal](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.html),\nand completely refactored the GitLab Runner to be able to be [extensible for custom behaviors](http://docs.gitlab.com/runner/executors/custom.html),\nenabling many new kinds of operation modes for your runners including but not limited to\nsupporting any kind of proprietary virtualization environment.\n\n## What's next\n\nNow that you're up to speed with the first couple of 12.x releases, let's look ahead to what's coming next in each monthly release from 12.2 this month to 12.6 in December.\n\n## 12.2 (August 22)\n\n_Since this blog post was published, we have updated our planning based on emerging priorities and customer need. For the latest on what we've got coming next, check out our [CI/CD direction page](/direction/ops/), which is always current._\n\n12.2 is just around the corner and it's also looking to be a big one.\n\nOne really exciting feature for this release is that we're adding a hybrid directed acyclic graph (DAG) to GitLab CI.\nThis is really just a fancy way of saying you'll be able to run pipeline steps out of order, breaking the\nstage sequencing you're familiar with in GitLab, and allowing jobs to relate to each other directly. This can\nbe valuable for monorepo situations where you have different folders in your repo that can build, test, and maybe\neven deploy independently, or in general it can provide a nice speed boost for your pipeline steps that relate to\neach other (for example, things like artifact processing or sequential test runs.) Read more in our [public issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/47063)\nabout how this great feature is going to work.\n\n![Directed Acyclic Graph](https://about.gitlab.com/images/blogimages/dag_execution.png \"Directed Acyclic Graph\"){: .shadow.medium.center}\n\nOut of order execution using the [Directed Acyclic Graph](https://gitlab.com/gitlab-org/gitlab-ce/issues/47063)\n{: .note .text-center}\n\nIn addition to the DAG, we're rethinking the way that [rules can be set up for pipelines](https://gitlab.com/gitlab-org/gitlab-ce/issues/60085),\nmaking it much easier to understand what a job is going to do compared with trying to figure out how a collection\nof `only/except` rules interact with each other. Another highlight is that we're adding the ability to\n[control behavior for individual users with Feature Flags](https://gitlab.com/gitlab-org/gitlab-ee/issues/11459) along with\n[percentage rollout across all users](https://gitlab.com/gitlab-org/gitlab-ee/issues/8240). These will give you a lot of\nflexibility to [progressively control](/direction/ops/#progressive-delivery) how changes are rolled out to your users\neven when the code is already in production.\n\n## 12.3 (September 22)\n\n_Since this blog post was published, we have updated our planning based on emerging priorities and customer need. For the latest on what we've got coming next, check out our [CI/CD direction page](/direction/ops/), which is always current._\n\nThe individual change in the 12.3 release that I'm most excited about has got to be\n[associating a milestone with a release](https://gitlab.com/gitlab-org/gitlab-ce/issues/62402). One of the greatest\nstrengths of GitLab is the connected ecosystem of features – by tying a release to a milestone, it becomes\npossible to connect all kinds of interesting data in GitLab to the release – issues, merge requests, and more, all\nat your fingertips and curated automatically by GitLab.\n\nWe're also going to be making [runner setup for Kubernetes](https://gitlab.com/gitlab-org/gitlab-ce/issues/63768)\nrequire just a single click to get going, and making a key architectural change to GitLab Pages that will\n[bring initial availability time for pages site down to nearly instantaneous](https://gitlab.com/gitlab-org/gitlab-ce/issues/61929).\n\n## 12.4 (October 22)\n\n_Since this blog post was published, we have updated our planning based on emerging priorities and customer need. For the latest on what we've got coming next, check out our [CI/CD direction page](/direction/ops/), which is always current._\n\nFirst up, we're planning on adding a [Hashicorp Vault integration](https://gitlab.com/gitlab-org/gitlab-ce/issues/61053) that will let you tie your\nGitLab CI pipelines to your Vault instance, making it possible to keep crucial build and deployment secrets outside\nof GitLab entirely.\n\nWe're also [expanding our pipelines for merge requests/results feature to also work with forks](https://gitlab.com/gitlab-org/gitlab-ee/issues/11934),\nand (building on top of the newly associated milestone) delivering an MVC for fully automated [evidence collection for releases](https://gitlab.com/gitlab-org/gitlab-ce/issues/56030).\nThis means that things like test results, pipeline outputs, merge requests, and issues will have a snapshot\navailable for auditing and review in the context of a release, all collected automatically from throughout GitLab\nwithout having to write a line of code.\n\n## 12.5 (November 22)\n\n_Since this blog post was published, we have updated our planning based on emerging priorities and customer need. For the latest on what we've got coming next, check out our [CI/CD direction page](/direction/ops/), which is always current._\n\nFor 12.5, we plan to tackle Helm v3 charts by providing features in our container registry to\nmanage these. [Helm v3](https://helm.sh/blog/helm-3-preview-pt1/) changes a lot about how charts work, and\nwe want to ensure that GitLab is there with you as you start to adopt this very different, but powerful new way\nof working.\n\nWe also plan to revisit [how workspaces are defined and shared](https://gitlab.com/gitlab-org/gitlab-ce/issues/62802),\nmaking it easier to build up a common staging area that can be shared by different jobs/pipelines in an easier-to-use,\nmore natural way than by using the cache or artifacts in GitLab today. Last but not least, we're improving on\nour testing parallelization features by making it possible to [leave the parallelization tuning to GitLab itself](https://gitlab.com/gitlab-org/gitlab-ee/issues/12282).\n\n## 12.6 (December 22)\n\n_Since this blog post was published, we have updated our planning based on emerging priorities and customer need. For the latest on what we've got coming next, check out our [CI/CD direction page](/direction/ops/), which is always current._\n\nFor the holidays we're planning on [making multi-project pipelines a Core feature](https://gitlab.com/gitlab-org/gitlab-ce/issues/63497),\nbringing this powerful capability to all of our users. More and more we're hearing that teams are using multi-project\npipelines in all kinds of interesting ways to solve unique problems, and we want to make this feature available to\neveryone who can benefit. EDIT 2020-01-02: We resolved [this issue](https://gitlab.com/gitlab-org/gitlab/issues/31573) back in 12.4 where the trigger keyword was not working in certain cases, which satisfied the request of the folks in that issue to open source the feature. There are potential executive dashboards for cross-project pipelines in the future which will be paid features, but using triggering is in core and working fine. If there are any use cases that are not working for you, please ping me (@jyavorska) in [gitlab#29626](https://gitlab.com/gitlab-org/gitlab/issues/29626) and I'd be happy to take a look.\n\nWe are also bringing in a whole new way of working with GitLab CI/CD: [child/parent pipelines](https://gitlab.com/gitlab-org/gitlab-ce/issues/22972).\nUsing these you'll be able to trigger downstream pipelines from your main pipeline; these will run completely independently\nand in their own separate namespace from the main pipeline, but will provide status attribution back to the main pipeline. These\nchild pipelines are definable in YAML files anywhere in your repo, so if you have a monorepo (for example) you'll be able to organize\nthese independent pipelines separately but still orchestrate them from a central command and control module.\n\nFinally, we're looking to improve how we show the [change in pipeline duration over time](https://gitlab.com/gitlab-org/gitlab-ee/issues/1806)\nas well as how [test runs are changing over time](https://gitlab.com/gitlab-org/gitlab-ee/issues/1020). This trend data will make\nit easier to manage the performance of your pipelines on an ongoing basis.\n\n## In conclusion\n\nHopefully you're as excited about these features as much as we are. We'd love for you to participate\nin the public issues so we can work together to deliver these features with your input. It's\npossible some specific items may change, but overall\nthis is the direction we're headed as we continue to add iterative improvements across all of CI/CD in\nevery release.\n\nInterested in learning more about GitLab CI/CD in general, and seeing all the rest of\nthe items we plan to deliver? Visit our [CI/CD strategy page](/direction/ops/)\nfor our themes, priorities, and more details on what's coming next.\n\nPhoto by [Reginar](https://unsplash.com/photos/4fQAMZNaGUo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/arrow?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n","engineering",[851,108,9],"DevOps",{"slug":853,"featured":6,"template":683},"a-look-ahead-for-gitlab-cicd","content:en-us:blog:a-look-ahead-for-gitlab-cicd.yml","A Look Ahead For Gitlab Cicd","en-us/blog/a-look-ahead-for-gitlab-cicd.yml","en-us/blog/a-look-ahead-for-gitlab-cicd",{"_path":859,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":860,"content":866,"config":873,"_id":875,"_type":13,"title":876,"_source":15,"_file":877,"_stem":878,"_extension":18},"/en-us/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"title":861,"description":862,"ogTitle":861,"ogDescription":862,"noIndex":6,"ogImage":863,"ogUrl":864,"ogSiteName":670,"ogType":671,"canonicalUrls":864,"schema":865},"Accelerate code reviews with GitLab Duo and Amazon Q","Use AI-powered agents to optimize code reviews by automatically analyzing merge requests and providing comprehensive feedback on bugs, readability, and coding standards.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","https://about.gitlab.com/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Accelerate code reviews with GitLab Duo and Amazon Q\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":861,"description":862,"authors":867,"heroImage":863,"date":868,"body":869,"category":806,"tags":870},[803],"2025-06-02","Code reviews are critical for catching bugs, improving code readability, and maintaining coding standards, but they can also be a major bottleneck in your workflow. When you're trying to ship features quickly, waiting for multiple team members to review your code can be frustrating. The back-and-forth discussions, the scheduling conflicts, and the time it takes to get everyone aligned can stretch what should be a simple review into days or even weeks.\n\nHere's where [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), our new offering that delivers agentic AI throughout the software development lifecycle for AWS customers, comes in to transform your review process. This intelligent, AI-powered solution can perform comprehensive code reviews for you in a fraction of the time it would take your human colleagues. By leveraging advanced agentic AI capabilities, GitLab Duo with Amazon Q streamlines your entire review workflow without sacrificing the quality and thoroughness you need. Think of it as having an always-available, highly skilled reviewer who can instantly analyze your code and provide actionable feedback.\n\n## How it works: Launching a code review\n\nSo how does GitLab Duo with Amazon Q actually work? Let's say you've just finished working on a feature and created a merge request with multiple code updates. Instead of pinging your teammates and waiting for their availability, you simply enter a quick command in the comment section: \"/q review\". That's it – just those two words trigger the AI to spring into action.\n\n![Triggering a code review using GitLab Duo with Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\nOnce you've entered the command, Amazon Q Service immediately begins analyzing your code changes. You'll see a confirmation that the review is underway, and within moments, the AI is examining every line of your updates, checking for potential issues across multiple dimensions.\nWhen the review completes, you receive comprehensive feedback that covers all the bases: bug detection, readability improvements, syntax errors, and adherence to your team's coding standards. The AI doesn't just point out problems, it provides context and suggestions for fixing them, making it easy for you to understand what needs attention and why.\n\nThe beauty of this agentic AI approach is that it handles the heavy lifting of code review while you focus on what matters most: building great software. You get the benefits of thorough code reviews — better bug detection, consistent coding standards, and improved code quality — without the time sink. Your deployment times shrink dramatically because you're no longer waiting in review queues, and your entire team becomes more productive.\n\n## Why use GitLab Duo with Amazon Q?\n\nGitLab Duo with Amazon Q transforms your development workflow in the following ways:\n- Lightning-fast code reviews that don't compromise on quality\n- Consistent application of coding standards across your entire codebase\n- Immediate feedback that helps you fix issues before they reach production\n- Reduced deployment times that let you ship features faster\n- More time for your team to focus on creative problem-solving instead of repetitive reviews\n\nReady to see this game-changing feature in action? Watch how GitLab Duo with Amazon Q can revolutionize your code review process:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> To learn more about GitLab Duo with Amazon Q visit us at an upcoming [AWS Summit in a city near you](https://about.gitlab.com/events/aws-summits/) or [reach out to your GitLab representative](https://about.gitlab.com/partners/technology-partners/aws/#form).\n> \n> And make sure to join the GitLab 18 virtual launch event to learn about our agentic AI plans and more. [Register today!](https://about.gitlab.com/eighteen/)",[786,478,871,701,9,281,872,746],"code review","AWS",{"slug":874,"featured":90,"template":683},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q","content:en-us:blog:accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","Accelerate Code Reviews With Gitlab Duo And Amazon Q","en-us/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","en-us/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"_path":880,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":881,"content":887,"config":895,"_id":897,"_type":13,"title":898,"_source":15,"_file":899,"_stem":900,"_extension":18},"/en-us/blog/advanced-search-data-migrations",{"title":882,"description":883,"ogTitle":882,"ogDescription":883,"noIndex":6,"ogImage":884,"ogUrl":885,"ogSiteName":670,"ogType":671,"canonicalUrls":885,"schema":886},"GitLab's data migration process for Advanced Search","We needed a more streamlined data migration process for Advanced search. Here's what we did.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682017/Blog/Hero%20Images/advanced-search-migrations.jpg","https://about.gitlab.com/blog/advanced-search-data-migrations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's data migration process for Advanced Search\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dmitry Gruzd\"}],\n        \"datePublished\": \"2021-06-01\",\n      }",{"title":882,"description":883,"authors":888,"heroImage":884,"date":890,"body":891,"category":849,"tags":892},[889],"Dmitry Gruzd","2021-06-01","\n\nFor some time now, GitLab has been working on enabling the Elasticsearch\nintegration on GitLab.com to allow as many GitLab.com users as possible access\nto the [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_search.html)\nfeatures. Last year, after enabling Advanced Search for all licensed customers on\nGitLab.com we were thinking how to simplify the rollout of some Advanced Search\nfeatures that require changing the data in Elasticsearch.\n\n(If you're interested in the lessons we learned on our road to Enabling\nElasticsearch for GitLab.com, you can read [all about it](/blog/elasticsearch-update/).\n\n## The data migration process problem \n\nSometimes we need to change mappings of an index or backfill a field, and\nreindexing everything from scratch or using [Zero downtime reindexing](https://docs.gitlab.com/ee/integration/elasticsearch.html#zero-downtime-reindexing)\nmight seem like an obvious solution. However, this is not a scalable option for\nbig GitLab instances. GitLab.com is the largest known installation of GitLab and\nas such has a lot of projects, code, issues, merge requests and other things that\nneed to be indexed. For example, at the moment our Elasticsearch cluster has\nalmost 1 billion documents in it. It would take many weeks or even months to\nreindex everything and for all that time indexing would need to remain paused, therefore\nsearch results would quickly become outdated.\n\n## Original plan for multi-version support\n\nOriginally, we were planning to introduce multi-version support using an approach\nthat is fully reliant on GitLab to manage both indices, reading from the old one\nand writing to both until the migration is finished. You can read more information at\n[!18254](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18254) and\n[&1769](https://gitlab.com/groups/gitlab-org/-/epics/1769). As of writing this,\nmost of the code for this approach still exists in GitLab in a half-implemented form.\n\nThere were 2 primary concerns with this approach:\n\n1. Reindexing would require the GitLab application to read every single document\nfrom the storage and send it to Elasticsearch again. Doing so\nwould put a big strain on different parts of the application, such as database,\nGitaly, and Sidekiq.\n1. Reindexing everything from GitLab to the cluster again may be very wasteful on\noccasions where you only need to change a small part of the index. For example, if\nwe want to add epics to the index, it is very wasteful to reindex every document\nin the index when we could very quickly just index all the epics. There are many\nsituations where we will be trying to perform some migration that can be done more\nefficiently using a targeted approach (e.g. adding a new field to a document type\nonly requires reindexing all the documents that actually have that field).\n\nFor these reasons we've decided to create a different data migration process.\n\n## Our revised data migration process\n\nWe took inspiration from the [Rails DB migrations](https://guides.rubyonrails.org/active_record_migrations.html).\nWe wanted to apply the best practices from it without having to re-architect what\nthe Rails team has already implemented.\n\nFor example, we've decided that we would have a special directory with time-stamped\nmigration files. We wanted to achieve a strict execution order so that many\nmigrations might be shipped simultaneously. A special background processing worker\nwill be checking this folder on schedule. This is slightly different to rails background migrations where the operator is required to manually run the migration. We decided to make it fully automated and run it in the background to avoid the need for self-managed customers to add extra steps to the migration process. This would have likely made it much more difficult for everyone involved as there are many ways to run GitLab. This extra constraint also forces us to always think of migrations as possibly incomplete at any point in the code which is essential for zero-downtime.\n\nAt first, we wanted to store the migration state in the Postgresql database, but\ndecided against it since this may not be perfect for the situation where a user\nwants to connect a new Elasticsearch cluster to GitLab. It's better to store the\nmigrations themselves in the Elasticsearch cluster itself so they're more likely to be in\nsync with the data.\n\nYou can see your new migration index in your Elasticsearch cluster. It's called\n`gitlab-production-migrations`. GitLab stores a few fields there. We use the\nversion number as the document id. This is an example document:\n\n```\n{\n    \"_id\": \"20210510143200\",\n    \"_source\": {\n        \"completed\": true,\n        \"state\": {\n        },\n        \"started_at\": \"2021-05-12T07:19:08.884Z\",\n        \"completed_at\": \"2021-05-12T07:19:08.884Z\"\n    }\n}\n```\n\nThe state field is used to store data that's required to run batched migrations.\nFor example, for batched migrations we store a slice number and a task id for\ncurrent Elasticsearch reindex operation and we update the state after every run.\n\nThis is how an example migration looks:\n\n```ruby\nclass MigrationName \u003C Elastic::Migration\n  def migrate\n    # Migrate the data here\n  end\n\n  def completed?\n    # Return true if completed, otherwise return false\n  end\nend\n```\n\nThis looks a lot like [Rails DB migrations](https://guides.rubyonrails.org/active_record_migrations.html),\nwhich was our goal from the beginning. The main difference is that it has an additional method to\ncheck if a migration is completed. We've added that method because we need to\nexecute asynchronous tasks quite often and we want to check if it's completed\nlater in a different worker process.\n\n## Migration framework logic\n\nThis is a simple flow chart to demonstrate the high level logic of the new migration framework.\n\n```mermaid\ngraph TD\n    CRON(cron every 30 minutes) --> |executes| WORKER[MigrationWorker]\n    WORKER --> B(an uncompleted migration is found)\n    B --> HALT(it's halted)\n    B --> UN(it's uncompleted)\n    B --> COMP(it's finished)\n    HALT --> WARN(show warning in the admin UI)\n    WARN --> EX(exit)\n    UN --> PREF(migration preflight checks)\n    PREF --> RUN(execute the migration code)\n    COMP --> MARK(mark it as finished)\n    MARK --> EX\n```\n\nAs you can see above, there are multiple different states of a migration. For example,\nthe framework allows it to be halted when it has too many failed attempts. In\nthat case, the warning will be shown in the admin UI with a button for restarting\nthe migration.\n\n![How the warning looks like](https://about.gitlab.com/images/blogimages/advanced_search/halted_warning.png)\n\n## Configuration options\n\nWe've introduced many useful configuration options into the framework, such as:\n\n- `batched!` - Allows the migration to run in batches. If set, the worker will\nre-enqueue itself with a delay which is set using the `throttle_delay` option\ndescribed below. We use this option to reduce the load and ensure that the\nmigration won't time out.\n\n- `throttle_delay` - Sets the wait time in between batch runs. This time should be\nset high enough to allow each migration batch enough time to finish.\n\n- `pause_indexing!` - Pauses indexing while the migration runs. This setting will\nrecord the indexing setting before the migration runs and set it back to that\nvalue when the migration is completed. GitLab only uses this option when\nabsolutely necessary since we attempt to minimize the downtime as much as possible.\n\n- `space_requirements!` - Verifies that enough free space is available in the\ncluster when the migration is running. This setting will halt the migration if the\nstorage required is not available. This option is used to\nprevent situations when your cluster runs out of space when attempting to execute\na migration.\n\nYou can see the up-to-date list of options in this development [documentation section](https://docs.gitlab.com/ee/development/elasticsearch.html#migration-options-supported-by-the-elasticmigrationworker).\n\n## Data migration process results\n\nWe implemented the Advanced Search migration framework in the 13.6 release and\nhave been improving it since. You can see some details in the original issue\n[#234046](https://gitlab.com/gitlab-org/gitlab/-/issues/234046). The only\nrequirement for this new feature is that you should create your index using at\nleast version 13.0. We have that requirement since we're heavily utilizing\naliases, which were introduced in 13.0. As you might know, over the last few\nreleases we've been working on separating different document types into their own\nindices. This migration framework has been a tremendous help for our initiative.\nWe've already completed the migration of issues (in 13.8), comments (in 13.11),\nand merge requests (in 13.12) with a noticeable performance improvement.\n\nSince we've accumulated so many different migrations over the last few releases\nand they require us to support multiple code paths for a long period of time,\nwe've decided to remove older migrations that were added prior to the 13.12\nrelease. You can see some details in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/329952).\nWe plan to continue the same strategy in the future, which is one of the reasons\nwhy you should always upgrade to the latest minor version before migrating to a\nmajor release.\n\nIf you're interested in contributing to features that require Advanced Search\nmigrations, we have a dedicated [documentation section](https://docs.gitlab.com/ee/development/elasticsearch.html#creating-a-new-advanced-search-migration)\nthat explains how to create one and lists all available options for it.\n",[9,893,894],"releases","workflow",{"slug":896,"featured":6,"template":683},"advanced-search-data-migrations","content:en-us:blog:advanced-search-data-migrations.yml","Advanced Search Data Migrations","en-us/blog/advanced-search-data-migrations.yml","en-us/blog/advanced-search-data-migrations",{"_path":902,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":903,"content":909,"config":915,"_id":917,"_type":13,"title":918,"_source":15,"_file":919,"_stem":920,"_extension":18},"/en-us/blog/ai-assisted-code-suggestions",{"title":904,"description":905,"ogTitle":904,"ogDescription":905,"noIndex":6,"ogImage":906,"ogUrl":907,"ogSiteName":670,"ogType":671,"canonicalUrls":907,"schema":908},"How AI-assisted code suggestions will advance DevSecOps","In this second blog in our ‘Future of AI/ML in DevSecOps’ series, find out the impact of AI Assisted code suggestions on the software development lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","https://about.gitlab.com/blog/ai-assisted-code-suggestions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How AI-assisted code suggestions will advance DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Neha Khalwadekar\"}],\n        \"datePublished\": \"2023-03-23\",\n      }",{"title":904,"description":905,"authors":910,"heroImage":906,"date":912,"body":913,"category":806,"tags":914},[911],"Neha Khalwadekar","2023-03-23","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nArtificial intelligence (AI) and machine learning (ML) have made incredible technological strides and are now poised to [impact the software development process](/topics/devops/the-role-of-ai-in-devops/). As we can see, AI code suggestion proposals have already had a tremendous influence in helping programmers reduce repetitive tasks. AI-assisted code suggestions will enable developers to speed up coding, debugging, refactoring, documentation, and many more tasks, greatly enhancing the software development lifecycle (SDLC).\n\n![Trends adopting AI/ML from GitLab's DevSecOps Survey](https://about.gitlab.com/images/blogimages/ai-ml-adoption-03-2023.png){: .shadow}\n\n## What are suggestions for AI-assisted code?\n\nML techniques are used in AI-assisted code suggestions to assess code and recommend improvements. These recommendations involve modifying the syntax, streamlining the organization of the code, or suggesting more effective methods. By lowering errors, increasing effectiveness, and providing optimization advice, the aim is to assist developers in writing better code faster.\n\n![Animated gif image of code suggestions](https://about.gitlab.com/images/15_9/DemoFastApi.gif){: .shadow}\n\n## How can AI-assisted code suggestions help?\n\nAI-assisted code suggestions can substantially improve the programming experience by reducing errors and helping programmers write code faster, which will help reproduce the much higher production code quality. \n\nHere are some of those SDLC improvements:\n\n- **Decreased errors, increased accuracy.** The capacity of AI-assisted code suggestions to decrease errors and increase accuracy is a critical advantage over manually written code. Developers can prevent common syntax errors, organize their code better, and boost algorithm performance with code suggestions. This leads to more dependable and effective code, which produces fewer defects and higher-quality software.\n- **A rise in productivity.** AI-assisted code suggestions can increase developers' efficiency by producing better code faster and more efficiently, saving time and money. Additionally, code suggestions can automate repetitive activities like formatting code, freeing engineers to concentrate on more complex jobs.\n- **Improved collaboration.** AI-assisted code recommendations can improve developer collaboration. Code suggestions can ensure all developers are on the same page by offering consistent coding standards and ideas for improvement. This will lessen the possibility of mistakes and facilitates efficient teamwork.\n- **Faster rollout and iteration.** AI-assisted code recommendations can hasten the deployment and iteration processes. With fewer errors and more effective code, developers can iterate and release updates faster. Code reviews also are faster and more efficient. As a result, enterprises can quickly bring new features to market, providing them with a substantial competitive edge.\n\n### GitLab’s competitive advantages\n\nGitLab’s unified DevSecOps platform enables businesses to deliver software more quickly and efficiently while enhancing security and compliance and maximizing the total return of investment on software development. We anticipate GitLab AI Assisted Code Suggestions will extend and amplify these benefits to improve developer productivity, focus, and innovation without context switching and within a single DevSecOps platform using the GitLab Workflow VS Code extension to get code suggestions as they type. Depending on the user prompts, the extension provides entire code snippets like generating functions or completing the current line. Simply pressing the tab key enables you to accept the suggestions.\n\nAs AI technologies advance in sophistication, they will provide more individualized and nuanced ideas, increasing their value to programmers.\n\nThe low-code/no-code development sectors are where AI-assisted code suggestions are anticipated to have substantial impact. As these development platforms spread, we envision bringing AI-powered tools that can offer recommendations and optimizations to simplify the software creation and deployment process for non-technical users on GitLab.com. \n\nThe following are some of the critical jobs we intend to address for our customers with AI Assisted Code Suggestions in the DevSecOps Platform:\n\n- **Code optimization.** How can we drastically reduce the time and effort required for developers to examine and test their code by identifying redundant or inefficient lines of code and suggesting streamlined alternatives?\n- **Automatic bug detection and patching.** How can we analyze sizable codebases to find potential bugs or security flaws and can also offer patches to fix them?\n- **Smart debugging.** How can we assist developers in locating faults precisely and make suggestions for potential fixes? This can result in considerable time and effort savings for developers and quicker bug response.\n- **Continuous integration and deployment.** How can we facilitate continuous integration and deployment by identifying code changes that could cause potential conflicts? This will enable developers to resolve issues quickly and roll out production code faster.\n- **Predictive maintenance.** How can we monitor the performance of the code and find potential issues before they become serious? As a result, developers may proactively address faults, leading to more dependable and stable software.\n- **Programming in natural language.** How can we allow developers to build code via simple natural-language commands? This can result in more efficient development and a much shorter learning curve for new developers.\n- **Test case generation and automation.** How can we generate test cases and automate the testing process? In addition to ensuring that software is adequately tested before it is deployed, this can cut down on the time and effort needed for testing.\n- **Smart code completion.** How can we ensure developers write code faster and more precisely, which completes code snippets based on context? This may lead to fewer mistakes and more effective development.\n\nGitLab’s AI Assisted Code Suggestions are available to select Ultimate customers in a closed beta. For early access consideration, Ultimate customers can [submit this form](https://docs.google.com/forms/d/e/1FAIpQLSdSixexFKnIkFGBbmx6XJfBdEBACowhsO-DOm82q4rrAAuYmA/viewform). We’re working towards a wider open beta of this capability in the next few months. \n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":916,"featured":6,"template":683},"ai-assisted-code-suggestions","content:en-us:blog:ai-assisted-code-suggestions.yml","Ai Assisted Code Suggestions","en-us/blog/ai-assisted-code-suggestions.yml","en-us/blog/ai-assisted-code-suggestions",{"_path":922,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":923,"content":929,"config":935,"_id":937,"_type":13,"title":938,"_source":15,"_file":939,"_stem":940,"_extension":18},"/en-us/blog/ai-ml-in-devsecops-series",{"title":924,"description":925,"ogTitle":924,"ogDescription":925,"noIndex":6,"ogImage":926,"ogUrl":927,"ogSiteName":670,"ogType":671,"canonicalUrls":927,"schema":928},"AI/ML in DevSecOps Series","This blog series chronicles our journey to integrate AI/ML throughout the software development lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682693/Blog/Hero%20Images/ai-ml-in-devsecops-blog-series.png","https://about.gitlab.com/blog/ai-ml-in-devsecops-series","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI/ML in DevSecOps Series\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab AI Assisted Group\"}],\n        \"datePublished\": \"2023-04-24\",\n      }",{"title":924,"description":925,"authors":930,"heroImage":926,"date":932,"body":933,"category":806,"tags":934},[931],"GitLab AI Assisted Group","2023-04-24","\n\nOur \"AI/ML in DevSecOps\" series tracks GitLab's journey to build and integrate AI/ML into our DevSecOps platform. Throughout the series, we’ll feature blogs from our product, engineering, and UX teams to showcase how we’re infusing AI/ML into GitLab. So be sure to bookmark this page and follow along.\n\nThis series details [many features introduced during our AI Fireside Chat](/blog/gitlab-ai-assisted-features/) on May 3, 2023.\n\nGet a [full overview of our AI-powered DevSecOps platform](https://about.gitlab.com/solutions/ai/). \n\n1. [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/)\nGitLab users already benefit from a step-function increase in productivity when they adopt our platform: streamlined collaboration, operational efficiencies, and massive acceleration in time to delivery. But by introducing machine learning (ML) and other artificial intelligence (AI) capabilities into the fabric of The DevSecOps Platform feature set, we aim to take those gains to a whole new level.\n\n2. [How AI-assisted code suggestions will advance DevSecOps](/blog/ai-assisted-code-suggestions/)\nAI-assisted code suggestions can substantially improve the programming experience by reducing errors and helping programmers write code faster, which will help reproduce the much higher production code quality.\n\n3. [ML experiment: Writing SQL is about to get a lot easier](/blog/ml-experiment-sql/)\nWith the recent advancements in AI and natural language processing, it's now possible for AI models to generate SQL code from simple English language queries. This means that even people without a deep understanding of SQL can generate complex queries to analyze their data. This technology not only improves accessibility but can also save valuable time and effort for data analysts.\n\n4. [ML experiment: Explain this source code](/blog/explain-this-code/)\nDeciphering the source code of a new software project can be a daunting or at least time-consuming task. The code may be poorly documented, or it may be written in a programming language that is unfamiliar to the developer. Even if the developer is familiar with the programming language, the code may be complex and difficult to understand. But what if developers had a helpful tool to figure out very quickly what code was doing? With recent advancements in AI models, it's now possible to have code explained in natural language.\n\n5. [ML experiment: Summarizing issue comments](/blog/summarize-issues/)\nLarge language models (LLMs) power generative AI solutions by using deep learning algorithms to analyze vast amounts of natural language data. These models are trained on massive datasets to develop an understanding of language patterns and context. Once trained, the models can generate new text that mimics human language. In a rapid prototype, our own Alexandru Croitor, Senior Backend Engineer, and Nicolas Dunlar, Senior Frontend Engineer for our Plan stage, leverage generative AI LLMs to power comment summarization within GitLab's issues.\n\n6. [ML experiment: Summarize merge request changes](/blog/merge-request-changes-summary-ai/)\nMerge requests are the central point of collaboration for code changes in GitLab. They often contain a variety of changes across many files and services within a project. Often, merge requests communicate the intent of the change as it relates to an issue being resolved, but they might not describe what was changed to achieve that. As review cycles progress, the current state of the merge request can become out of sync with the realities of the proposed changes and keeping people informed. We believe that we can leverage AI and large language models (LLMs) to help provide relevant summaries of a merge request and its proposed changes, so reviewers and authors can spend more time discussing changes and less time keeping descriptions updated.\n\n7. [ML experiment: Generate tests for code changes](/blog/merge-request-suggest-a-test/)\nProposing changes and new features via merge requests is great, but what about the tests? Sometimes, tests can be the hardest part of any code change you make. We are leveraging generative AI to enable developers to create tests for merge request changes helping reduce the laborious but important task of writing tests increasing test coverage. \n\n8. [ML experiment: Explain this vulnerability](/blog/explain-this-vulnerability/)\nSecurity vulnerabilities aren't always easy to understand, especially for developers without experience or training with cybersecurity. We're leveraging AI to help developers understand security vulnerabilities and even get guidence on how to resolve them.\n\n9. [ML experiment: Use a chatbot to answer how-to questions](/blog/gitlab-chat-ai/)\nLarge language models (LLMs) have changed the way everyday people interact with large volumes of text. We thought, why not train an LLM on GitLab's extensive documentation to help users quickly answer natural language questions. Gone are the days of endless searching through vast documentation sites.\n\n10. [Track ML model experiments with new GitLab MLFlow integration](/blog/track-machine-learning-model-experiments/)\nModel experiments allow data scientists to track different variations of machine learning models directly on GitLab.\n\n11. [Code Suggestions available to all GitLab tiers while in Beta](/blog/code-suggestions-for-all-during-beta/)\nWe've made code suggestions available to all plans for free during Beta. Also, learn about recent updates to Code Suggestions.\n\n12. [ML experiment: Summarize my merge request review](/blog/summarize-my-merge-request-review/) \nLearn how GitLab is experimenting with ML-powered merge request review summaries.\n\n13. [How Code Suggestions can supercharge developers' daily productivity](/blog/code-suggestions-improves-developer-productivity/)\nLearn how you can use GitLab Code Suggestions to accelerate your development.\n\n14. [ML experiment: Extending Code Suggestions to more development environments](/blog/extending-code-suggestions/)\nLearn how we're expanding Code Suggestions to support Visual Studio, \nJetBrains IDEs, Neovim, and other development environments.\n\n15. [Train and deploy AI models with GitLab and Google Vertex AI](/blog/training-and-deploying-ai-models-with-gitlab-and-vertex-ai/)\nA demonstration of GitLab's DevSecOps capabilities combined with Vertex AI's scalable ML platform, designed with the aim of rapid and secure AI deployments. \n\n16. [Self-managed support for Code Suggestions (Beta)](/blog/self-managed-support-for-code-suggestions/)\nOne of our most popular customer requests – self-managed support for Code Suggestsions (Beta) – is expected to ship soon in GitLab 16.1. Learn how it will work.\n\n17. [Meet GitLab Duo - The suite of AI capabilities powering your workflows](/blog/meet-gitlab-duo-the-suite-of-ai-capabilities/)\nLearn about GitLab Duo, an expanding toolbox of features integrated directly into the GitLab platform to assist DevSecOps teams.\n\n18. [GitLab for Visual Studio, including code suggestions, available in Beta](/blog/gitlab-visual-studio-extension/)\nGitLab for Visual Studio extension supports GitLab Duo code suggestions for both GitLab SaaS and GitLab self-managed.\n\n19. [Empower ModelOps and HPC workloads with GPU-enabled runners integrated with CI/CD](/blog/empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners)\nLearn how to leverage our GitLab-hosted GPU-enabled runners for ModelOps and high-performance computing workloads.\n\n20. [GitLab Duo Code Suggestions for JetBrains and Neovim](/blog/gitlab-jetbrains-neovim-plugins/) GitLab plugins for JetBrains IDEs and Neovim are now available in Beta,\nbringing GitLab Duo Code Suggestions to more software development environments.\n\nWant to learn even more about AI/ML? Check out our [AI Assisted Group direction page](/direction/modelops/ai_assisted/) and more [AI/ML articles](/blog/tags.html#AI/ML).\n",[851,701,9,786],{"slug":936,"featured":6,"template":683},"ai-ml-in-devsecops-series","content:en-us:blog:ai-ml-in-devsecops-series.yml","Ai Ml In Devsecops Series","en-us/blog/ai-ml-in-devsecops-series.yml","en-us/blog/ai-ml-in-devsecops-series",{"_path":942,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":949,"config":956,"_id":958,"_type":13,"title":959,"_source":15,"_file":960,"_stem":961,"_extension":18},"/en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"title":944,"description":945,"ogTitle":944,"ogDescription":945,"noIndex":6,"ogImage":946,"ogUrl":947,"ogSiteName":670,"ogType":671,"canonicalUrls":947,"schema":948},"AI-native GitLab Premium: Transform higher education software development","The DevSecOps platform's enterprise-grade features for academic workflows, data protection, and support ensure better collaboration, security, and efficiency.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","https://about.gitlab.com/blog/ai-native-gitlab-premium-transform-higher-education-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI-native GitLab Premium: Transform higher education software development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jessica Hurwitz\"},{\"@type\":\"Person\",\"name\":\"Elisabeth Burrows\"}],\n        \"datePublished\": \"2025-06-10\",\n      }",{"title":944,"description":945,"authors":950,"heroImage":946,"date":953,"body":954,"category":701,"tags":955},[951,952],"Jessica Hurwitz","Elisabeth Burrows","2025-06-10","Educational institutions increasingly rely on modern software development practices to support teaching, research, and administrative functions. As development needs grow more complex in university and college environments, GitLab Premium with Duo provides essential capabilities that address the unique challenges faced by higher education – particularly around open source development, remote collaboration, and enterprise-grade security.\n\nGitLab's comprehensive, intelligent DevSecOps platform delivers value that extends far beyond fundamental version control. Built on an open source foundation with enterprise-grade features, GitLab Premium helps prevent costly security incidents involving student data, provides cloud-based development environments for distributed teams, and offers the professional support that educational institutions need for mission-critical systems. And now [Premium includes GitLab Duo AI essentials](https://about.gitlab.com/blog/gitlab-premium-with-duo/) Code Suggestions and Chat at no additional cost.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## The unique development environment in higher education\n\nUniversities and colleges operate in a distinctly challenging technical environment. Development teams must support multidisciplinary collaboration across technical and non-technical departments while managing vast amounts of sensitive data – from student records and financial information to research findings and faculty evaluations.\n\nMost institutions face these challenges with limited IT resources, yet must support thousands of concurrent users across numerous projects and research initiatives. Research integrity requirements add another layer of complexity, as development work often needs to maintain traceability and reproducibility standards.\n\n## Premium solutions for educational institutions\n\nGitLab Premium with Duo has the functionality that higher education needs.\n\n### Enhanced collaboration and workflow capabilities\n\nCross-departmental projects are common in educational settings – from multi-department research initiatives to custom module development for systems like Ellucian Banner, an enterprise resource planning application used by higher education. These complex projects require sophisticated workflow management that goes beyond basic version control. \n\nGitLab Premium addresses these challenges with powerful collaboration and project visualization features, including epics, roadmaps, and advanced Kanban boards for Agile development workflows. When you assign multiple approvers to certain merge requests and protected branches, you ensure higher code quality and accountability across teams. These tools allow institutions to coordinate work across departments while aligning with institution-wide objectives – essential for managing multiphase campus technology initiatives.\n\nIn Australia, [Deakin University’s](https://about.gitlab.com/customers/deakin-university/) enablement team uses GitLab to build standardized processes and reusable templates — such as custom merge request templates, templated build pipelines, and a security and compliance framework — that can be shared with the broader university community and citizen developers, driving innovation and collaboration both inside the university and with key partners. “We were trying to bring in a community of practice and help it thrive for quite some time, but we were never successful until we had this tool,” said Aaron Whitehand, director of Digital Enablement at Deakin University.\n\n> #### Read more about [how Deakin University uses GitLab to drive improvements](https://about.gitlab.com/customers/deakin-university/) in collaboration and productivity, including a 60% reduction in manual tasks.\n\n### Advanced data protection and governance\n\nEducational institutions generate and manage vast amounts of data, ranging from student records and financial information to research findings and faculty evaluations. The security stakes are particularly high. The [2023 MOVEit breach](https://universitybusiness.com/in-just-3-months-this-data-breach-has-compromised-nearly-900-institutions/), which spanned three months and compromised approximately 900 educational institutions, exposed the sensitive information of more than 62 million people. This demonstrates the critical need for proactive security measures integrated directly into higher education development workflows. \n\nVulnerability scanning stops code releases that contain security risks, enabling institutions to establish and enforce governance protocols that protect sensitive information. These capabilities help universities implement proper access controls and permission structures for research databases, creating a secure framework where authorized researchers maintain appropriate access – effectively balancing robust protection with necessary collaboration.\n\nGitLab is built from the ground up to secure your source code. Scalable Git-based repositories, granular access controls, and built-in compliance features eliminate bottlenecks in your workflow while meeting security requirements. GitLab Premium provides audit tracking and compliance capabilities essential for educational environments. Complete audit trails capture detailed logs of all code changes, access attempts, and system modifications with timestamps and user attribution. Full change management documentation ensures traceability of who made what changes, when, and why – critical for research integrity – while access control auditing monitors repository access and permissions changes. \n\n### Cloud-based development environments and remote collaboration\n\nModern educational institutions require flexible development environments that support distributed teams, remote learning scenarios, and diverse technical requirements. GitLab Premium provides:\n\n* **[GitLab Workspaces](https://docs.gitlab.com/user/workspace/):** Cloud-based development environments accessible from any device  \n* **[Web IDE integration](https://docs.gitlab.com/user/project/web_ide/):** Browser-based coding with full GitLab feature integration  \n* **[Container-based development](https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces/):** Consistent, reproducible development environments across different projects and user groups\n\nThese capabilities are particularly valuable for supporting remote and hybrid learning models, enabling students and researchers to access standardized development environments regardless of their physical location or local hardware constraints.\n\n### Professional support for critical systems\n\nSmall IT teams in educational settings often support large, complex infrastructure with minimal resources. Reaching out to user forums for answers doesn't always mean you'll get an accurate reply and isn't efficient for large teams. GitLab Premium includes dedicated professional support, providing faster issue resolution and upgrade assistance during critical periods like class enrollment or research deadlines.\n\nThis minimizes downtime for critical services and ensures continuity of operations during peak usage periods, giving stretched IT departments the enterprise-grade reliability they need for essential academic systems.\n\n### Built on open source with enterprise capabilities\n\nOpen source software is developed collaboratively in a public manner, with source code freely available for anyone to view, modify, and distribute. This development model fosters innovation through community contributions and ensures transparency in how software functions. GitLab's open source foundation resonates strongly with educational institutions' values around collaboration, transparency, and community contribution. GitLab Premium features extend this foundation with enterprise-grade capabilities while maintaining the ability to contribute back to the open source ecosystem.\n\nKey open source advantages include:\n\n* **Transparency:** Complete visibility into platform capabilities and security measures – you can examine exactly how the software works  \n* **Community contribution:** Ability to contribute improvements back to the broader community and benefit from global developer expertise  \n* **Vendor independence:** Reduced lock-in risk with open source alternatives and the freedom to modify code as needed  \n* **Co-creation opportunities:** Collaborative development with the broader community, including other educational institutions, to build shared solutions\n\n### AI assistant for software development tasks\n\nGitLab Premium with [Duo](https://about.gitlab.com/gitlab-duo/) brings powerful AI-native capabilities directly into the development workflow, including:  \n* [**Code Suggestions**](https://docs.gitlab.com/user/project/repository/code_suggestions/), which provides real-time code completion and suggestions, helping developers write code faster and more efficiently  \n* [**Chat**](https://docs.gitlab.com/user/gitlab_duo_chat/), which allows team members to get instant answers to questions, troubleshoot issues, and access documentation directly within the GitLab environment\n\nThese AI tools significantly enhance productivity, reduce errors, and streamline collaboration, making GitLab Premium an even more valuable asset for software development teams in higher education.\n\n### Transparency at the core\n\nHigher education institutions handle incredibly sensitive data — from student records and research findings to proprietary academic work and federal grant information. \n\nThe [GitLab AI Transparency Center ](https://about.gitlab.com/ai-transparency-center/)demonstrates our commitment to transparency, accountability, and protection of customer data and intellectual property, providing the privacy guarantees that educational institutions require.\n\nGitLab launched the AI Transparency Center to help customers, community, and team members better understand how GitLab upholds ethics and transparency in our AI-powered features. \n\nOur publicly available documentation highlights the comprehensive measures we take to protect your institution's data and intellectual property. [GitLab's AI Ethics Principles for Product Development](https://handbook.gitlab.com/handbook/legal/ethics-compliance-program/ai-ethics-principles/) guide us as we continue to build and evolve our AI functionality, helping higher education organizations harness the promise of AI while maintaining complete control and oversight of their most valuable information assets.\n\n## Get started with GitLab Premium today\n\nFor educational institutions, GitLab Premium with Duo represents a strategic technical investment that combines the benefits of open source development with enterprise-grade, AI-native capabilities. By providing professional-grade tools ready for the challenges familiar to the complex technical environment of higher education, GitLab Premium with Duo helps institutions address security vulnerabilities, streamline development workflows, and maintain the reliable infrastructure that academic and research operations depend on.\n\n> [Learn more about GitLab for Public Sector](https://about.gitlab.com/solutions/public-sector/) or  [speak to our sales team today](https://about.gitlab.com/sales/).\n\n## Read more\n\n- [Unlocking AI for every GitLab Premium and Ultimate customer](https://about.gitlab.com/blog/gitlab-premium-with-duo/)\n- [GitLab Duo Code Suggestions](https://docs.gitlab.com/user/project/repository/code_suggestions/)\n- [GitLab Duo Chat](https://docs.gitlab.com/user/gitlab_duo_chat/)",[549,478,701,9,183],{"slug":957,"featured":90,"template":683},"ai-native-gitlab-premium-transform-higher-education-software-development","content:en-us:blog:ai-native-gitlab-premium-transform-higher-education-software-development.yml","Ai Native Gitlab Premium Transform Higher Education Software Development","en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development.yml","en-us/blog/ai-native-gitlab-premium-transform-higher-education-software-development",{"_path":963,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":964,"content":970,"config":977,"_id":979,"_type":13,"title":980,"_source":15,"_file":981,"_stem":982,"_extension":18},"/en-us/blog/all-aboard-merge-trains",{"title":965,"description":966,"ogTitle":965,"ogDescription":966,"noIndex":6,"ogImage":967,"ogUrl":968,"ogSiteName":670,"ogType":671,"canonicalUrls":968,"schema":969},"How starting merge trains improve efficiency for DevOps","No more queuing and waiting for pipeline results! Read how merge trains will speed up your deployments while making sure master stays green.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678419/Blog/Hero%20Images/merge_trains.jpg","https://about.gitlab.com/blog/all-aboard-merge-trains","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How starting merge trains improve efficiency for DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n        \"datePublished\": \"2020-01-30\",\n      }",{"title":965,"description":966,"authors":971,"heroImage":967,"date":973,"body":974,"category":849,"tags":975},[972],"Orit Golowinski","2020-01-30","\nA large percentage of a developer's day is spent updating their branches and rebasing, they are essentially \"racing\" their teammates to get their merge requests merged. Keeping the master branch green is critical for [continuous delivery](/topics/continuous-delivery/). When the production build breaks, it means your new code isn't going live, which impacts users and revenue. The only way to be 100% sure the master branch stays green when new code merges is to run the pipeline using the latest version of the master branch. For teams that have a high volume of merges, this can be difficult or even impossible. In the time it takes the pipeline to complete one code change, other changes can get merged to master with the potential for conflict. The only way to mitigate this is to queue and sequence the changes so that once a production pipeline starts, other code doesn't get merged ahead of that change. \n\n## What are merge trains and how do they help?\n\n Merge trains introduce a way to order the flow of changes into the target branch (usually master). When you have teams with a high number of changes in the target branch, this can cause a situation where during the time it takes to validate merged code for one change, another change has been merged to master, invalidating the previous merged result.\n\nBy using merge trains, each merge request joins as the last item in that train with each merge request being processed in order. However, instead of queuing and waiting, each item takes the completed state of the previous (pending) [merge ref](https://gitlab.com/gitlab-org/gitlab-foss/issues/47110) (the merge result of the merge), adds its own changes, and starts the pipeline immediately in parallel under the assumption that everything is going to pass.\n\nIf all pipelines in the merge train are completed successfully, then no pipeline time is wasted on queuing or retrying. Pipelines invalidated through failures are immediately canceled, the MR causing the failure is removed, and the rest of the MRs in the train are requeued without the need for manual intervention.\n\nAn example of a merge train:\n\n![Diagram of merge trains](https://about.gitlab.com/images/blogimages/merge_trains-1.png){: .shadow}\n\nMR1 and MR2 join a merge train. When MR3 attempts to join, the merge fails and it is removed from the merge train. MR4 restarts at the point that MR3 fails, and attempts to run without the contents of MR3.\nMR3 will remain open in failed state, so that the author can rebase and fix the failure before attempting to merge again.\n\nHere is a demonstration video that explains the advantage of the merge train feature. In this video, we'll simulate the common problem in a workflow without merge trains, and later, we resolve the problem by enabling a merge train.\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/D4qCqXgZkHQ\" frameborder=\"0\" allowfullscreen=\"true\">\n\u003C/iframe>\n\u003C/figure>\n\n## How the merge trains feature has evolved so far\n\nAfter releasing [merge trains](/releases/2019/06/22/gitlab-12-0-released/#sequential-merge-trains) in GitLab 12.0, we immediately started to use this feature internally, and collected a lot of valuable feedback which helped us to improve and enhance the feature.\n\nWe started by tuning the [merge train concurrency](https://gitlab.com/gitlab-org/gitlab/issues/31692). We understood that while merge trains is a feature that is designed to improve efficiency by making sure that master stays green, it can also create an unwanted bottleneck that slows down productivity if your merge requests needs to wait in a long queue in order to get merged.\n\nWe also noticed that many developers were \"skipping the line\" and merging their changes immediately because they did not understand the effect that merging immediately has on other users, so we added a [warning](https://gitlab.com/gitlab-org/gitlab/issues/12679) to clarify this common misunderstanding. We intentionally left the option to still \"merge immediately\" since we also understand the importance of an urgent merge request, such as a \"hot fix\" that must be able to skip to the front of the merge train. Another improvement was the ability to [“squash & merge” as part of the merge train](https://gitlab.com/gitlab-org/gitlab/issues/13001) in order to maintain a clean commit history.\n\nHere is a demonstration video that explains how squash & merge works with merge trains.\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/pA5SfHwlq0s\" frameborder=\"0\" allowfullscreen=\"true\">\n\u003C/iframe>\n\u003C/figure>\n\n## What's next\n\nWe plan to add more important features to the support of merge trains. The first is that [merge trains should support fast-forward merge](https://gitlab.com/gitlab-org/gitlab/issues/35628). This could help solve a fundamental contention problem of fast-forward merges: The CI pipeline must be run every time the merge request is rebased, and the merge request must be rebased every time master changes – which is frequently! This problem significantly limits the frequency with which merge requests can be merged.\n\nThe second feature, [API support for merge trains](https://gitlab.com/gitlab-org/gitlab/issues/32665), will extend the ability to automate your workflows using merge trains.\n\nWe want to hear from you! Tell us how merge trains have improved your workflow, or give us more insight into how we can improve merge trains to work better for you. [Give us your feedback by commenting here](https://gitlab.com/groups/gitlab-org/-/epics/2408).\n\nCover image by [Vidar Nordli-Mathisen\n](https://images.unsplash.com/photo-1525349769815-0e6ba4e0bbdd?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1611&q=80) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[108,976,894,9],"demo",{"slug":978,"featured":6,"template":683},"all-aboard-merge-trains","content:en-us:blog:all-aboard-merge-trains.yml","All Aboard Merge Trains","en-us/blog/all-aboard-merge-trains.yml","en-us/blog/all-aboard-merge-trains",{"_path":984,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":985,"content":991,"config":1000,"_id":1002,"_type":13,"title":1003,"_source":15,"_file":1004,"_stem":1005,"_extension":18},"/en-us/blog/all-remote-is-for-everyone",{"title":986,"description":987,"ogTitle":986,"ogDescription":987,"noIndex":6,"ogImage":988,"ogUrl":989,"ogSiteName":670,"ogType":671,"canonicalUrls":989,"schema":990},"Why we believe all-remote is for everyone","Darren Murph, leading GitLab's all-remote initiatives, shares why the future of work can be embraced today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680729/Blog/Hero%20Images/dm-globe.jpg","https://about.gitlab.com/blog/all-remote-is-for-everyone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we believe all-remote is for everyone\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2019-08-15\",\n      }",{"title":986,"description":987,"authors":992,"heroImage":988,"date":994,"body":995,"category":996,"tags":997},[993],"Darren Murph","2019-08-15","\n\nWe're committed to [all-remote](/company/culture/all-remote/) work at GitLab – our whole work philosophy\nis designed around it. I joined GitLab to lead our all-remote\ninitiatives – here's a bit about my background and why I'm excited to join the team.\n\n### A pivotal moment in how society looks at remote work\n\nGitLab is known by many as an [open core company](/blog/monetizing-and-being-open-source/) which develops software for the software\ndevelopment lifecycle. What I want the world to know is that it’s *also* a pioneer in remote work,\nbuilding a transparent, empowered workforce of [over 800 team members across 57+ countries](/company/team/).\nYou read that correctly. Over 800 of us, none of whom are required to work from a central\noffice, are making GitLab one of the world’s largest all remote companies.\n\nI was recently given the honor of joining GitLab to lead its all remote initiatives. The\ncompany’s remarkable growth and impact on the world is well documented, but as I’ve\nengaged with team members – as well as pets and families in the background! – I’m beginning to\nunderstand that we’ve barely scratched the surface of what’s possible.\n\n![Embracing the remote lifestyle in Alabama Hills, California](https://about.gitlab.com/images/blogimages/dm-alabama-hills-california.jpg){: .shadow.medium.center}\nEmbracing the remote lifestyle in Alabama Hills, California\n{: .note.text-center}\n\nI believe we’re nearing a sea change in how we work. It’s easy to point to stratospheric rent prices in major urban centers, soul-crushing gridlock, and shifting mindsets in what society values in a career as reasons for turning to remote work.\n\nBut I think it’s deeper than that. We yearn to explore, and work doesn't have to stand in the way.\n\n### Positive change is possible as all-remote becomes the default for many companies\n\nThe internet has never been faster nor more ubiquitous. Computing power has never been more\naccessible. It’s time for organizations large and small to embrace these realities, to open their\nrecruiting pipelines to the world, to divert real estate budget to R&D and to recognize that\nwe’re all better workers when we’re given the space to feel truly alive.\n\nMore importantly, the communities that matter to each of us have never needed our presence more.\nWorking remotely gives each person the autonomy to serve in a place that matters to them –\na place that has shaped them – contributing significantly to the wellbeing of a population\nthat may be at risk of losing its foundation, should talent continue to flee to the usual job centers.\n\n[Research from the University of New Hampshire](https://carsey.unh.edu/publication/rural-depopulation) has found that \"35% of rural counties in the United States are experiencing protracted and significant population loss.\" Speaking to shrinking towns across Europe, [a 2016 report from the European Parliamentary Research Service](http://www.europarl.europa.eu/thinktank/en/document.html?reference=EPRS_BRI(2016)586632) notes that \"younger members of society prefer to migrate to more economically vibrant regions and cities in search of better job prospects as, in most of these territories, professional opportunities remain limited and confined to specific fields (e.g. agriculture and tourism).\" I believe all-remote has the power to pause, and perhaps even reverse, these trends of depopulation.\n\n![Remote work can have outsized positive impact in cities like Accra](https://about.gitlab.com/images/blogimages/dm-accra-ghana.jpg){: .shadow.medium.center}\nRemote work can have outsized positive impact in cities like Accra\n{: .note.text-center}\n\nWhat would traffic in London, Moscow, Mexico City, and Rome look like if every person who *could* work remotely, did?\nWhat talent might we surface by tapping into burgeoning tech hubs in cities like Accra or Lagos? How\nmany San Franciscans – locals who have been priced out of their own city – could move back if some\nof the world’s greatest technical minds were empowered to work from anywhere? What would\nunderserved communities in rural regions across the globe be capable of if well-paying jobs\ncame their way via the internet?\n\nI don’t ask these questions hypothetically. I ask them because I want to leverage GitLab’s\nplatform to change the narrative on work, and I fully expect that we’ll see those answers in\nmy lifetime. It doesn’t hurt that GitLab (the product) is [tailor-made to enable remote work](/free-trial/),\neven across large teams.\n\n### Creating more remote opportunities for others\n\nI’ve had the great privilege of working remotely my entire career. I’ve shared memories with my\nfamily in over 50 countries and have celebrated milestones with colleagues whilst flying over a\nmillion miles on a single airline (thank you, Delta!).\n\nMy wife and I experienced the beautiful and transformative journey of adoption because I\nworked for an employer that trusted me to excel from a place I needed to be to see it through.\nI’ve met countless GitLabbers who have never been happier, more fulfilled, or more engaged with\ntheir family and community, all because they’re empowered to work remotely.\n\n![Remote work encourages exploration of both locales and cultures](https://about.gitlab.com/images/blogimages/dm-delta-munich-germany.jpg){: .shadow.medium.center}\nRemote work encourages exploration of both locales and cultures\n{: .note.text-center}\n\nI share this because I realize I’m one of the fortunate few, and I long for countless others to have\nthese same opportunities. GitLab is positioned to be of service to everyone – from startups, to\nentrepreneurs, to the world’s largest enterprises – in creating a remote infrastructure that works.\nI couldn’t be more excited to help enable precisely that.\n\nIf you're new to the concept of all-remote, I'd encourage you to dive into\nour [Handbook](/handbook/)\nand [learn how it works at GitLab](/company/culture/all-remote/tips/).\n\nIf you're ready to embrace the freedoms enabled by all-remote, browse\nour [vacancies](/jobs/) and join me on this journey!\n","culture",[9,680,998,999],"remote work","careers",{"slug":1001,"featured":6,"template":683},"all-remote-is-for-everyone","content:en-us:blog:all-remote-is-for-everyone.yml","All Remote Is For Everyone","en-us/blog/all-remote-is-for-everyone.yml","en-us/blog/all-remote-is-for-everyone",{"_path":1007,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1008,"content":1015,"config":1022,"_id":1024,"_type":13,"title":1025,"_source":15,"_file":1026,"_stem":1027,"_extension":18},"/en-us/blog/android-publishing-with-gitlab-and-fastlane",{"title":1009,"description":1010,"ogTitle":1011,"ogDescription":1010,"noIndex":6,"ogImage":1012,"ogUrl":1013,"ogSiteName":670,"ogType":671,"canonicalUrls":1013,"schema":1014},"Publishing Android apps to Play Store with GitLab & fastlane","See how GitLab, together with fastlane, can build, sign, and publish apps for Android to the Google Play Store.","HPublishing Android apps to Play Store with GitLab & fastlane","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679918/Blog/Hero%20Images/android-fastlane-pipeline.png","https://about.gitlab.com/blog/android-publishing-with-gitlab-and-fastlane","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to publish Android apps to the Google Play Store with GitLab and fastlane\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-01-28\",\n      }",{"title":1016,"description":1010,"authors":1017,"heroImage":1012,"date":1018,"body":1019,"category":849,"tags":1020},"How to publish Android apps to the Google Play Store with GitLab and fastlane",[846],"2019-01-28","\n\nWhen we heard about [_fastlane_](https://fastlane.tools), an app automation tool for delivering iOS and Android builds, we wanted to give it a spin to see if a combination of GitLab and _fastlane_ could help us bring our mobile build and deployment automation to the next level and make mobile development a bit easier. You can see an [actual production deployment](https://gitlab.com/gitlab-org/gitter/gitter-android-app/pipelines/40768761) of the [Gitter Android app](https://gitlab.com/gitlab-org/gitter/gitter-android-app) that uses what we'll be implementing in this blog post; suffice to say, the results were fantastic and we've become big believers that the combination of GitLab and _fastlane_ is a truly game-changing way for developers to [enable CI/CD](/topics/ci-cd/) (continuous integration and continuous delivery) for their mobile applications. With GitLab and _fastlane_ we're getting, with minimal effort:\n\n- Source control, project home, issue tracking, and everything else that comes with GitLab.\n- Content and images (metadata) for Google Play Store listing managed in source control.\n- Automatic signing, version numbers, and changelog.\n- Automatic publishing to `internal` distribution channel in Google Play Store.\n- Manual promotion through `alpha`, `beta`, and `production` channels.\n- Containerized build environment, available in GitLab's container registry.\n\nIf you'd like to jump ahead and see the finished product, you can take a look at the already-completed Gitter for Android [.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitter/gitter-android-app/blob/master/.gitlab-ci.yml), [build.gradle](https://gitlab.com/gitlab-org/gitter/gitter-android-app/blob/master/app/build.gradle), [Dockerfile](https://gitlab.com/gitlab-org/gitter/gitter-android-app/blob/master/Dockerfile), and [_fastlane_ configuration](https://gitlab.com/gitlab-org/gitter/gitter-android-app/tree/master/fastlane).\n\n## Configuring _fastlane_\n\nWe'll begin first by setting up _fastlane_ in our project, make a couple key changes to our Gradle configuration, and then wrap everything up in a GitLab pipeline.\n\n_fastlane_ has pretty good [documentation](https://docs.fastlane.tools/getting-started/android/setup/) to get you started, and if you run into platform-specific trouble it's the first place to check, but to get under way you really just need to complete a few straightforward steps.\n\n### Initializing your project\n\nFirst up, you need to get _fastlane_ installed locally and initialize your product. We're using the Ruby `fastlane` gem so you'll need Ruby on your system for this to work. You can read about [other install options in the _fastlane_ documentation](https://docs.fastlane.tools/getting-started/android/setup/).\n\n``` ruby\nsource \"https://rubygems.org\"\n\ngem \"fastlane\"\n```\n\nOnce your Gemfile is updated, you can run `bundle update` to update/generate your `Gemfile.lock`. From this point you can run _fastlane_ by typing `bundle exec fastlane`. Later, you'll see that in CI/CD we use `bundle install ...` to ensure the command runs within the context of our project environment.\n\nNow that we have _fastlane_ ready to run, we just need to initialize our repo with our configuration. Run `bundle exec fastlane init` from within your project directory, answer a few questions, and _fastlane_ will create a new `./fastlane` directory containing its configuration.\n\n### Setting up _supply_\n\n_supply_ is a feature built into _fastlane_ which will help you manage screenshots, descriptions, and other localized metadata/assets for publishing to the Google Play Store.\n\nPlease refer to these [detailed instructions for collecting the credentials necessary to run _supply_](https://docs.fastlane.tools/getting-started/android/setup/#setting-up-supply).\n\nOnce you've set this up, simply run `bundle exec fastlane supply init` and all your current metadata will be downloaded from your store listing and saved in `fastlane/metadata/android`. From this point you're able to manage all of your store content as-code; when we publish a new version to the store later, the versions of content checked into your source repo will be used to populate the entry.\n\n### Appfile\n\nThe `./fastlane/Appfile` is pretty straightforward, and contains basic configuration you chose when you initialized your project. Later we'll see how to inject the `json_key_file` in your CI/CD pipeline at runtime.\n\n`./fastlane/Appfile`\n``` yaml\njson_key_file(\"~/google_play_api_key.json\") # Path to the json secret file - Follow https://docs.fastlane.tools/actions/supply/#setup to get one\npackage_name(\"im.gitter.gitter\") # e.g. com.krausefx.app\n```\n\n### Fastfile\n\nThe `./fastlane/Fastfile` is more interesting, and contains the first changes you'll see that we made for Gitter vs. the default one created when you run `bundle exec fastlane init`.\n\nThe first section contains our definitions for how we want to run builds and tests. As you can see, this is pretty straightforward and builds right on top of your already set up Gradle tasks.\n\n`./fastlane/Fastfile`\n``` yaml\ndefault_platform(:android)\n\nplatform :android do\n\n  desc \"Builds the debug code\"\n  lane :buildDebug do\n    gradle(task: \"assembleDebug\")\n  end\n\n  desc \"Builds the release code\"\n  lane :buildRelease do\n    gradle(task: \"assembleRelease\")\n  end\n\n  desc \"Runs all the tests\"\n  lane :test do\n    gradle(task: \"test\")\n  end\n\n...\n```\n\nCreating Gradle tasks that publish/promote builds can be complicated and error prone, but _fastlane_ makes this much easier by giving you pre-built commands (called _fastlane_ actions) that let you perform complex tasks with just a few simple actions.\n\nIn our example, we've set up a workflow where a new build can be published to the internal track and then optionally promoted through alpha, beta, and ultimately production. We initially had a new build for each track but it's safer to have the same/known build go through the whole process.\n\n``` yaml\n...\n\n  desc \"Submit a new Internal Build to Play Store\"\n  lane :internal do\n    upload_to_play_store(track: 'internal', apk: 'app/build/outputs/apk/release/app-release.apk')\n  end\n\n  desc \"Promote Internal to Alpha\"\n  lane :promote_internal_to_alpha do\n    upload_to_play_store(track: 'internal', track_promote_to: 'alpha')\n  end\n\n  desc \"Promote Alpha to Beta\"\n  lane :promote_alpha_to_beta do\n    upload_to_play_store(track: 'alpha', track_promote_to: 'beta')\n  end\n\n  desc \"Promote Beta to Production\"\n  lane :promote_beta_to_production do\n    upload_to_play_store(track: 'beta', track_promote_to: 'production')\n  end\nend\n```\n\nAn important note is that we've only scratched the surface of the kinds of actions that _fastlane_ can automate. You can [read more about available actions here](https://docs.fastlane.tools/actions/), and it's even possible to create your own.\n\n## Gradle configuration\n\nWe also made a couple of key changes to our basic Gradle configuration to make publishing easier. Nothing major here, but it does help us make things run a little more smoothly.\n\n### Secret properties\n\nThe first changed section gathers the secret variables to be used for signing. These are either loaded via configuration file, or gathered from environment variables in the case of CI.\n\n`app/build.gradle`\n``` groovy\n// Try reading secrets from file\ndef secretsPropertiesFile = rootProject.file(\"secrets.properties\")\ndef secretProperties = new Properties()\n\nif (secretsPropertiesFile.exists()) {\n    secretProperties.load(new FileInputStream(secretsPropertiesFile))\n}\n// Otherwise read from environment variables, this happens in CI\nelse {\n    secretProperties.setProperty(\"oauth_client_id\", \"\\\"${System.getenv('oauth_client_id')}\\\"\")\n    secretProperties.setProperty(\"oauth_client_secret\", \"\\\"${System.getenv('oauth_client_secret')}\\\"\")\n    secretProperties.setProperty(\"oauth_redirect_uri\", \"\\\"${System.getenv('oauth_redirect_uri')}\\\"\")\n    secretProperties.setProperty(\"google_project_id\", \"\\\"${System.getenv('google_project_id') ?: \"null\"}\\\"\")\n    secretProperties.setProperty(\"signing_keystore_password\", \"${System.getenv('signing_keystore_password')}\")\n    secretProperties.setProperty(\"signing_key_password\", \"${System.getenv('signing_key_password')}\")\n    secretProperties.setProperty(\"signing_key_alias\", \"${System.getenv('signing_key_alias')}\")\n}\n```\n\n### Automatic versioning\n\nWe also set up automatic versioning using environment variables `VERSION_CODE`, `VERSION_SHA`, which we will set up later in CI/CD (locally they will just be `null` which is fine). Because each build's `versionCode` that you submit to the Google Play Store needs to be higher than the last, this makes it simple to deal with.\n\n`app/build.gradle`\n``` groovy\nandroid {\n    defaultConfig {\n        applicationId \"im.gitter.gitter\"\n        minSdkVersion 19\n        targetSdkVersion 26\n        versionCode Integer.valueOf(System.env.VERSION_CODE ?: 0)\n        // Manually bump the semver version part of the string as necessary\n        versionName \"3.2.0-${System.env.VERSION_SHA}\"\n```\n\n### Signing configuration\n\nFinally, we inject the signing configuration which will automatically be used by Gradle to sign the release build. Depending on your configuration, you may already be doing this. We only worry about signing in the release build that would potentially be published to the Google Play Store.\n\n> When using App Signing by Google Play, you will use two keys: the app signing key and the upload key. You keep the upload key and use it to sign your app for upload to the Google Play Store.\n>\n> [*https://developer.android.com/studio/publish/app-signing#google-play-app-signing*](https://developer.android.com/studio/publish/app-signing#google-play-app-signing)\n\n> IMPORTANT: Google will not re-sign any of your existing or new APKs that are signed with the app signing key. This enables you to start testing your app bundle in the internal test, alpha, or beta tracks while you continue to release your existing APK in production without Google Play changing it.\n>\n> *`https://play.google.com/apps/publish/?account=xxx#KeyManagementPlace:p=im.gitter.gitter&appid=xxx`*\n\n`app/build.gradle`\n``` groovy\n    signingConfigs {\n        release {\n            // You need to specify either an absolute path or include the\n            // keystore file in the same directory as the build.gradle file.\n            storeFile file(\"../android-signing-keystore.jks\")\n            storePassword \"${secretProperties['signing_keystore_password']}\"\n            keyAlias \"${secretProperties['signing_key_alias']}\"\n            keyPassword \"${secretProperties['signing_key_password']}\"\n        }\n    }\n    buildTypes {\n        release {\n            minifyEnabled false\n            testCoverageEnabled false\n            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'\n            signingConfig signingConfigs.release\n        }\n    }\n}\n```\n\n## Setting up the Docker build environment\n\nWe are building a Docker image to be used as a repeatable, consistent build environment which will speed things up because it will already have the dependencies downloaded and installed. We're just fetching a few prerequisites, installing the Android SDK, and then grabbing _fastlane_.\n\n`Dockerfile`\n```dockerfile\nFROM openjdk:8-jdk\n\n# Just matched `app/build.gradle`\nENV ANDROID_COMPILE_SDK \"26\"\n# Just matched `app/build.gradle`\nENV ANDROID_BUILD_TOOLS \"28.0.3\"\n# Version from https://developer.android.com/studio/releases/sdk-tools\nENV ANDROID_SDK_TOOLS \"24.4.1\"\n\nENV ANDROID_HOME /android-sdk-linux\nENV PATH=\"${PATH}:/android-sdk-linux/platform-tools/\"\n\n# install OS packages\nRUN apt-get --quiet update --yes\nRUN apt-get --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 build-essential ruby ruby-dev\n# We use this for xxd hex->binary\nRUN apt-get --quiet install --yes vim-common\n# install Android SDK\nRUN wget --quiet --output-document=android-sdk.tgz https://dl.google.com/android/android-sdk_r${ANDROID_SDK_TOOLS}-linux.tgz\nRUN tar --extract --gzip --file=android-sdk.tgz\nRUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter android-${ANDROID_COMPILE_SDK}\nRUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter platform-tools\nRUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter build-tools-${ANDROID_BUILD_TOOLS}\nRUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-android-m2repository\nRUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-google_play_services\nRUN echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-m2repository\n# install Fastlane\nCOPY Gemfile.lock .\nCOPY Gemfile .\nRUN gem install bundle\nRUN bundle install\n```\n\n## Setting up GitLab\n\nWith our build environment ready, let's set up our `.gitlab-ci.yml` to tie it all together in a CI/CD pipeline.\n\n### Stages\n\nThe first thing we do is define the stages that we're going to use. We'll set up our build environment, do our debug and release builds, run our tests, deploy to internal, and then promote through alpha, beta, and production. You can see that, apart from `environment`, these map to the lanes we set up in our `Fastfile`.\n\n``` yaml\nstages:\n  - environment\n  - build\n  - test\n  - internal\n  - alpha\n  - beta\n  - production\n```\n\n### Build environment update\n\nNext up we're going to update our build environment, if needed. If you're not familiar with `.gitlab-ci.yml` it may look like there's a lot going on here, but we'll take it one step at a time. The very first thing we do is set up an `.updateContainerJob` yaml template which can be used to capture shared configuration for other steps that want to use it. In this case, it will be used by the subsequent `updateContainer` and `ensureContainer` jobs.\n\n#### `.updateContainerJob` template\n\nIn this case, since we're dealing with Docker in Docker (`dind`), we are running some scripts which log into the local [GitLab container registry](https://docs.gitlab.com/ee/user/packages/container_registry/index.html), fetch the latest image to be used as a layer cache reference, build a new image, and finally push the new version to the registry.\n\n``` yaml\n.updateContainerJob:\n  image: docker:stable\n  stage: environment\n  services:\n    - docker:dind\n  script:\n    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY\n    - docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG || true\n    - docker build --cache-from $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG .\n    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n```\n\n#### `updateContainer` job\n\nThe first job that inherits `.updateContainerJob`, `updateContainer`, only runs if the `Dockerfile` was updated and will run through the template steps described above.\n\n``` yaml\nupdateContainer:\n  extends: .updateContainerJob\n  only:\n    changes:\n      - Dockerfile\n```\n\n#### `ensureContainer` job\n\nBecause the first pipeline on a branch can fail, the `only: changes: Dockerfile` syntax won't trigger for a subsequent pipeline after you fix things. This can leave your branch without a Docker image to use. So the `ensureContainer` job will look for an existing image and only build one if it doesn't exist. The one downside to this is that both of these jobs will run at the same time if it is a new branch.\n\nIdeally, we could just use `$CI_REGISTRY_IMAGE:master` as a fallback when `$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG` isn't found but there isn't any syntax for this.\n\n``` yaml\nensureContainer:\n  extends: .updateContainerJob\n  allow_failure: true\n  before_script:\n    - \"mkdir -p ~/.docker && echo '{\\\"experimental\\\": \\\"enabled\\\"}' > ~/.docker/config.json\"\n    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY\n    # Skip update container `script` if the container already exists\n    # via https://gitlab.com/gitlab-org/gitlab-ce/issues/26866#note_97609397 -> https://stackoverflow.com/a/52077071/796832\n    - docker manifest inspect $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG > /dev/null && exit || true\n```\n\n### Build and test\n\nWith our build environment ready, we're ready to build our `debug` and `release` targets. Similar to above, we use a template to set up repeated steps within our build jobs, avoiding duplication. Within this section, the first thing we do is set the image to the build environment container image we built in the previous step.\n\n#### `.build_job` template\n\n``` yaml\n.build_job:\n  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n  stage: build\n\n...\n```\n\nNext up is a step that's specific to Gitter, but if you use shared assets between a iOS and Android build you might consider doing something similar. What we're doing here is grabbing the latest mobile artifacts built by the web application pipeline and placing them in the appropriate location.\n\n``` yaml\n  before_script:\n    - wget --output-document=artifacts.zip --quiet \"https://gitlab.com/gitlab-org/gitter/webapp/-/jobs/artifacts/master/download?job=mobile-asset-build\"\n    - unzip artifacts.zip\n    - mkdir -p app/src/main/assets/www\n    - mv output/android/www/* app/src/main/assets/www/\n```\n\nNext, we use [project-level variables](https://docs.gitlab.com/ee/ci/variables/) containing a binary (hex) dump of our signing keystore file and convert it back to a binary file. This allows us to inject the file into the build at runtime instead of checking it into source control, a potential security concern. To get the `signing_jks_file_hex` variable hex value, we use this binary -> hex command, `xxd -p gitter-android-app.jks`\n\n``` yaml\n    # We store this binary file in a variable as hex with this command, `xxd -p gitter-android-app.jks`\n    # Then we convert the hex back to a binary file\n    - echo \"$signing_jks_file_hex\" | xxd -r -p - > android-signing-keystore.jks\n```\n\nHere we're setting the version at runtime – these environment variables will be used by the Gradle build as implemented above. Because `$CI_PIPELINE_IID` increments on each pipeline, we can guarantee our `versionCode` is always higher than the last and be able to publish to the Google Play Store.\n\n``` yaml\n    # We add 100 to get this high enough above current versionCodes that are published\n    - \"export VERSION_CODE=$((100 + $CI_PIPELINE_IID)) && echo $VERSION_CODE\"\n    - \"export VERSION_SHA=`echo ${CI_COMMIT_SHORT_SHA}` && echo $VERSION_SHA\"\n```\n\nNext, we automatically generate a changelog to include by copying whatever you have in `CURRENT_VERSION.txt` to the current `\u003CversionCode>.text`. You can update `CURRENT_VERSION.txt` as necessary. I won't dive into the details of the merge request (MR) creation script here since it's somewhat specific to Gitter, but if you're interested in how something like this might work check out the [`create-changlog-mr.sh` script](https://gitlab.com/gitlab-org/gitter/gitter-android-app/blob/master/ci-scripts/create-changlog-mr.sh).\n\n``` yaml\n    # Make the changelog\n    - cp ./fastlane/metadata/android/en-GB/changelogs/CURRENT_VERSION.txt \"./fastlane/metadata/android/en-GB/changelogs/$VERSION_CODE.txt\"\n    # We allow the remote push and MR creation to fail because the other job could create it\n    # and it's not strictly necessary (we just need the file locally for the CI/CD build)\n    - ./ci-scripts/create-changlog-mr.sh || true\n    # Because we allow the MR creation to fail, just make sure we are back in the right repo state\n    - git checkout \"$CI_COMMIT_SHA\"\n```\n\nJust a couple of final items: First, whenever a build job is done, we remove the jks file just to be sure it doesn't get saved to artifacts, and second we set up the artifact directory from where the output of the build (`.apk`) will be saved.\n\n``` yaml\n  after_script:\n    - rm android-signing-keystore.jks || true\n  artifacts:\n    paths:\n    - app/build/outputs\n```\n\n#### `buildDebug` and `buildRelease` jobs\n\nMost of the complexity here was set up in the template, so as you can see our `buildDebug` and `buildRelease` job definitions are very clear. Both just call the appropriate _fastlane_ task (which, if you remember, then calls the appropriate Gradle task). The `buildRelease` output is associated with the `production` environment so we can define an extra production-scoped set of [project-level variables](https://docs.gitlab.com/ee/ci/variables/) which are different from our testing variables.\n\nSince we set up code signing in the Gradle config (`build.gradle`) earlier, we can be confident here that our `release` builds are appropriately signed and ready for publishing.\n\n```\nbuildDebug:\n  extends: .build_job\n  script:\n    - bundle exec fastlane buildDebug\n\nbuildRelease:\n  extends: .build_job\n  script:\n    - bundle exec fastlane buildRelease\n  environment:\n    name: production\n```\n\nTesting is really just another instance of the same thing, but instead of calling one of the build lanes we call the test lane. Note that we are using a `dependency` from the `buildDebug` job to ensure we don't need to rebuild anything.\n\n``` yaml\ntestDebug:\n  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n  stage: test\n  dependencies:\n    - buildDebug\n  script:\n    - bundle exec fastlane test\n```\n\n### Publish\n\nNow that our code is being built, we're ready to publish to the Google Play Store. We only *publish* to the `internal` testing track and *promote* this same build to the rest of the tracks.\n\nThis is achieved through the _fastlane_ integration, using a pre-built action to handle the job. In this case we are using a `dependency` on the `buildRelease` job, and creating a local copy of the Google API JSON keyfile (again stored in a [project-level variable](https://docs.gitlab.com/ee/ci/variables/) instead of checking it into source control.) We have this job (and all subsequent jobs) set to run only on `manual` action so we have full human control/intervention from this point forward. If you prefer to continuously deliver to your `internal` track you'd simply need to remove the `when: manual` entry and you'd have achieved your goal.\n\nIf you're like me, this may seem too easy to work. With everything we've configured in GitLab and _fastlane_ to this point, it's really this simple!\n\n``` yaml\npublishInternal:\n  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n  stage: internal\n  dependencies:\n    - buildRelease\n  when: manual\n  before_script:\n    - echo $google_play_service_account_api_key_json > ~/google_play_api_key.json\n  after_script:\n    - rm ~/google_play_api_key.json\n  script:\n    - bundle exec fastlane internal\n```\n\n### Promote\n\nAs indicated earlier, promotion through alpha, beta, and production are all `manual` jobs. If internal testing is good, it can be promoted one step forward in sequence all the way through to production using these manual jobs.\n\nIf you're with me to this point, there's really nothing new here and this really highlights the power of GitLab with _fastlane_. We have a `.promote_job` template job which creates the local Google API JSON key file and the promote jobs themselves are basically identical.\n\n``` yaml\n.promote_job:\n  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n  when: manual\n  dependencies: []\n  only:\n    - master\n  before_script:\n    - echo $google_play_service_account_api_key_json > ~/google_play_api_key.json\n  after_script:\n    - rm ~/google_play_api_key.json\n\npromoteAlpha:\n  extends: .promote_job\n  stage: alpha\n  script:\n    - bundle exec fastlane promote_internal_to_alpha\n\npromoteBeta:\n  extends: .promote_job\n  stage: beta\n  script:\n    - bundle exec fastlane promote_alpha_to_beta\n\npromoteProduction:\n  extends: .promote_job\n  stage: production\n  script:\n    - bundle exec fastlane promote_beta_to_production\n```\n\nNote that we're `only` allowing production promotion from the `master` branch, instead of from any branch. This is to ensure that the production build uses the separate set of `production` environment variables which only happens for the `buildRelease` job. We also have these [variables set as protected](https://docs.gitlab.com/ee/ci/variables/#protected-variables) so we can enforce that they are only used on the `master` branch which is protected.\n\n### Variables\n\nThe last step is to make sure you set up the [project-level variables](https://docs.gitlab.com/ee/ci/variables/) we used throughout the configuration above:\n\n - `google_play_service_account_api_key_json`: see [https://docs.fastlane.tools/getting-started/android/setup/#collect-your-google-credentials](https://docs.fastlane.tools/getting-started/android/setup/#collect-your-google-credentials)\n - `oauth_client_id`\n - `oauth_client_id`, protected, `production` environment\n - `oauth_client_secret`\n - `oauth_client_secret`, protected, `production` environment\n - `oauth_redirect_uri`\n - `oauth_redirect_uri`, protected, `production` environment\n - `signing_jks_file_hex`: `xxd -p gitter-android-app.jks`\n - `signing_key_alias`\n - `signing_key_password`\n - `signing_keystore_password`\n\nIf you are using the same [`create-changlog-mr.sh` script](https://gitlab.com/gitlab-org/gitter/gitter-android-app/blob/master/ci-scripts/create-changlog-mr.sh) as us,\n\n - `deploy_key_android_repo`: see [https://docs.gitlab.com/ee/user/project/deploy_tokens/](https://docs.gitlab.com/ee/user/project/deploy_tokens/)\n - `gitlab_api_access_token`: see [https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) (we use a bot user)\n\n![Project variables for Gitter for Android](https://about.gitlab.com/images/blogimages/android-fastlane-variables.png){: .shadow.medium.center}\n\n## What's next\n\nUsing this configuration we've got Gitter for Android building, signing, deploying to our internal track, and publishing to production as frequently as we like. Next up will be to do the same for iOS, so watch this space for our next post!\n\nPhoto by [Patrick Tomasso](https://unsplash.com/@impatrickt) on [Unsplash](https://unsplash.com/photos/KGcLJwIYiac)\n{: .note}\n",[108,230,1021,9],"google",{"slug":1023,"featured":6,"template":683},"android-publishing-with-gitlab-and-fastlane","content:en-us:blog:android-publishing-with-gitlab-and-fastlane.yml","Android Publishing With Gitlab And Fastlane","en-us/blog/android-publishing-with-gitlab-and-fastlane.yml","en-us/blog/android-publishing-with-gitlab-and-fastlane",{"_path":1029,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1030,"content":1036,"config":1044,"_id":1046,"_type":13,"title":1047,"_source":15,"_file":1048,"_stem":1049,"_extension":18},"/en-us/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd",{"title":1031,"description":1032,"ogTitle":1031,"ogDescription":1032,"noIndex":6,"ogImage":1033,"ogUrl":1034,"ogSiteName":670,"ogType":671,"canonicalUrls":1034,"schema":1035},"Container image provenance with Cosign in GitLab CI/CD","Use GitLab pipelines to automate building, signing, and annotating Docker images. This tutorial shares code to show you how. Try it out in your own organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098395/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2823%29_2w6waL76KROjhJHM2vXet6_1750098395162.png","https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Annotate container images with build provenance using Cosign in GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"João Pereira\"},{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-09-04\",\n      }",{"title":1037,"description":1032,"authors":1038,"heroImage":1033,"date":1041,"body":1042,"category":704,"tags":1043},"Annotate container images with build provenance using Cosign in GitLab CI/CD",[1039,1040],"João Pereira","Tim Rizzi","2024-09-04","Container security has become a critical concern in software development. As organizations increasingly rely on containerized applications, ensuring the integrity and traceability of container images is paramount. Enhancing the security and traceability of your container images directly in your GitLab CI/CD pipeline can streamline your development process while significantly boosting your security posture.\n\nThis tutorial demonstrates setting up a GitLab pipeline to automate the process of building, signing, and annotating Docker images using Cosign and the GitLab container registry. By integrating these practices, you'll secure your images and ensure that each one is easily traceable, aligning with best practices in DevSecOps.\n\n## Background on container image security\n\nBefore we dive into the technical details, it's crucial to understand why container image security is so important. In [microservices](https://about.gitlab.com/topics/microservices/) and cloud-native applications, containers have become the standard for packaging and deploying software. However, this widespread adoption has also made containers an attractive target for cyber attacks.\n\nContainer image security is a vital component of the broader [software supply chain security](https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security/) concept. This encompasses all the tools, processes, and practices that ensure your software's integrity, authenticity, and security from development to deployment. By securing your container images, you're protecting your application and your entire software supply chain.\n\n## Introduction to Cosign\n\nEnter [Cosign](https://about.gitlab.com/blog/keyless-signing-with-cosign/), a tool designed to address these security concerns. Cosign is part of the Sigstore project, an open-source initiative aimed at improving the security of the software supply chain. Cosign allows developers to sign and verify container images, ensuring their integrity and authenticity.\n\nKey benefits of Cosign include:\n\n- easy integration with existing CI/CD pipelines\n- support for various signing methods, including keyless signing\n- ability to attach and verify arbitrary metadata to container images\n\nBy incorporating Cosign into your GitLab CI/CD pipeline, you're taking a significant step towards robust [DevSecOps](https://about.gitlab.com/topics/devsecops/) practices.\n\n## Benefits of image signing and annotation\n\nImage signing serves as a seal of authenticity for your container images. It helps prevent tampering and ensures that the image deployed in your production environment is precisely the one that passed through your secure build process.\n\nAnnotations, on the other hand, provide valuable metadata about the build process. This information is used for auditing and traceability. In a security incident, having detailed provenance data can significantly speed up the investigation and remediation process.\n\n## GitLab CI/CD pipeline configuration\n\nLet's look at an example `.gitlab-ci.yml` file that outlines the process of building, signing, and annotating a Docker image using Cosign:\n\n```yaml\nstages:\n  - build\n\nbuild_and_sign:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind  # Enable Docker-in-Docker service to allow Docker commands inside the container\n  variables:\n    IMAGE_TAG: $CI_COMMIT_SHORT_SHA  # Use the commit short SHA as the image tag\n    IMAGE_URI: $CI_REGISTRY_IMAGE:$IMAGE_TAG  # Construct the full image URI with the registry, project path, and tag\n    COSIGN_YES: \"true\"  # Automatically confirm actions in Cosign without user interaction\n    FF_SCRIPT_SECTIONS: \"true\"  # Enables GitLab's CI script sections for better multi-line script output\n  id_tokens:\n    SIGSTORE_ID_TOKEN:\n      aud: sigstore  # Provide an OIDC token for keyless signing with Cosign\n  before_script:\n    - apk add --no-cache cosign jq  # Install Cosign (mandatory) and jq (optional)\n    - docker login -u \"gitlab-ci-token\" -p \"$CI_JOB_TOKEN\" \"$CI_REGISTRY\"  # Log in to the Docker registry using GitLab CI token\n  script:\n    # Build the Docker image using the specified tag and push it to the registry\n    - docker build --pull -t \"$IMAGE_URI\" .\n    - docker push \"$IMAGE_URI\"\n\n    # Retrieve the digest of the pushed image to use in the signing step\n    - IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' \"$IMAGE_URI\")\n\n    # Sign the image using Cosign with annotations that provide metadata about the build and tag annotation to allow verifying\n    # the tag->digest mapping (https://github.com/sigstore/cosign?tab=readme-ov-file#tag-signing)\n    - |\n      cosign sign \"$IMAGE_DIGEST\" \\\n        --annotations \"com.gitlab.ci.user.name=$GITLAB_USER_NAME\" \\\n        --annotations \"com.gitlab.ci.pipeline.id=$CI_PIPELINE_ID\" \\\n        --annotations \"com.gitlab.ci.pipeline.url=$CI_PIPELINE_URL\" \\\n        --annotations \"com.gitlab.ci.job.id=$CI_JOB_ID\" \\\n        --annotations \"com.gitlab.ci.job.url=$CI_JOB_URL\" \\\n        --annotations \"com.gitlab.ci.commit.sha=$CI_COMMIT_SHA\" \\\n        --annotations \"com.gitlab.ci.commit.ref.name=$CI_COMMIT_REF_NAME\" \\\n        --annotations \"com.gitlab.ci.project.path=$CI_PROJECT_PATH\" \\\n        --annotations \"org.opencontainers.image.source=$CI_PROJECT_URL\" \\\n        --annotations \"org.opencontainers.image.revision=$CI_COMMIT_SHA\" \\\n        --annotations \"tag=$IMAGE_TAG\"\n\n    # Verify the image signature using Cosign to ensure it matches the expected annotations and certificate identity\n    - |\n      cosign verify \\\n        --annotations \"tag=$IMAGE_TAG\" \\\n        --certificate-identity \"$CI_PROJECT_URL//.gitlab-ci.yml@refs/heads/$CI_COMMIT_REF_NAME\" \\\n        --certificate-oidc-issuer \"$CI_SERVER_URL\" \\\n        \"$IMAGE_URI\" | jq .  # Use jq to format the verification output for easier readability\n```\n\nLet's break down this pipeline configuration and understand each part in detail.\n\n## Detailed explanation of the pipeline\n\n### 1. Setup and prerequisites\n\nThe pipeline starts by setting up the necessary environment:\n\n* It uses the `docker:latest` image and enables Docker-in-Docker service, allowing Docker commands to be run within the CI job.\n* It defines variables for the image tag and URI using GitLab CI/CD predefined variables.\n* It sets up an OIDC token for keyless signing with Cosign.\n* In the `before_script` section, it installs Cosign and jq (for JSON processing) and logs into the GitLab container registry.\n\n### 2. Building and pushing the image\n\nThe first step in the script is to build the Docker image and push it to the GitLab container registry:\n\n```yaml\n- docker build --pull -t \"$IMAGE_URI\" .\n- docker push \"$IMAGE_URI\"\n```\n\nThis creates the image using the current directory's Dockerfile and pushes it to the registry.\n\n### 3. Signing the image with Cosign\n\nAfter building and pushing the image, the pipeline signs it using Cosign:\n\n```yaml\n- IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' \"$IMAGE_URI\")\n- |\n  cosign sign \"$IMAGE_DIGEST\" \\\n    --annotations \"com.gitlab.ci.user.name=$GITLAB_USER_NAME\" \\\n    --annotations \"com.gitlab.ci.pipeline.id=$CI_PIPELINE_ID\" \\\n    # ... (other annotations) ...\n    --annotations \"tag=$IMAGE_TAG\"\n```\n\nThis step first retrieves the image digest and then uses Cosign to sign the image, adding several annotations.\n\n## Verifying the signature and annotations\n\nAfter signing the image, it's crucial to verify the signature and the annotations we've added. This verification step ensures that the provenance data attached to the image is correct and hasn't been tampered with.\n\nIn our pipeline, we've included a verification step using the `cosign verify` command:\n\n```yaml\n- |\n  cosign verify \\\n    --annotations \"tag=$IMAGE_TAG\" \\\n    --certificate-identity \"$CI_PROJECT_URL//.gitlab-ci.yml@refs/heads/$CI_COMMIT_REF_NAME\" \\\n    --certificate-oidc-issuer \"$CI_SERVER_URL\" \\\n    \"$IMAGE_URI\" | jq .\n```\n\nThis command verifies the signature and checks the annotations. Its output will show all the annotations we've added to the image during the signing process.\n\nHere's what you might see in your pipeline logs after running this command:\n\n![verifying the signature and checking annotations](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098404/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098404260.png)\n\nIn this output, you should see all the annotations we added earlier, including:\n\n* GitLab CI user name\n* Pipeline ID and URL\n* Job ID and URL\n* Commit SHA and reference name\n* Project path\n* Image source and revision\n\nBy verifying these annotations, you can ensure that the image's provenance data is intact and matches what you expect based on your build process. This verification step is crucial for maintaining the integrity of your software supply chain. It allows you to confirm that the image you're about to deploy has gone through your secure build process and has yet to be modified since it was signed.\n\n## Summary\n\nBy integrating Cosign into your GitLab CI/CD pipeline, you've taken a significant step toward securing your software supply chain. This setup not only automates securing and annotating your container images with build metadata but also ensures a transparent and traceable build process.\n\nThe benefits of this approach are numerous:\n\n- enhanced security through image signing\n- improved traceability with detailed build provenance data\n- automated verification process\n- alignment with DevSecOps best practices\n\nAs container security continues to be a critical concern in the software development lifecycle, implementing these practices puts you ahead of potential security threats and demonstrates a commitment to software integrity.\n\n## Try it in your organization\n\nNow that you've seen how to enhance your container security using Cosign in GitLab CI/CD, it's time to put this knowledge into practice:\n\n1. **Implement in your projects**: Adapt the provided `.gitlab-ci.yml` file to fit your specific needs.\n2. **Explore further**: Dive deeper into Cosign's capabilities. Consider exploring advanced features like policy enforcement or integration with vulnerability scanning tools.\n3. **Share your experience**: After implementing this in your projects, share your experience with your team or the wider GitLab community. Your insights could help others enhance their security practices.\n4. **Stay updated**: Container security is an evolving field. Check GitLab's blog and documentation for new features and best practices updates.\n5. **Contribute**: If you find ways to improve this process or encounter any issues, consider contributing to the GitLab or Cosign open-source projects.\n\nRemember, security is a journey, not a destination. By taking these steps, you're securing your containers and contributing to a more secure software ecosystem for everyone.\n\nStart implementing these practices in your GitLab projects today, and take your container security to the next level!\n\n> Get started today! Sign up for a [free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)!\n\n## Read more\n\n- [Next-generation GitLab container registry goes GA](https://about.gitlab.com/blog/next-generation-gitlab-container-registry-goes-ga/)\n- [A beginner's guide to container security](https://about.gitlab.com/topics/devsecops/beginners-guide-to-container-security/)\n- [DevSecOps basics, including security](https://about.gitlab.com/topics/devsecops/)\n- [What is CI/CD?](https://about.gitlab.com/topics/ci-cd/)\n",[704,746,701,9],{"slug":1045,"featured":6,"template":683},"annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd","content:en-us:blog:annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd.yml","Annotate Container Images With Build Provenance Using Cosign In Gitlab Ci Cd","en-us/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd.yml","en-us/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd",{"_path":1051,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1052,"content":1058,"config":1064,"_id":1066,"_type":13,"title":1067,"_source":15,"_file":1068,"_stem":1069,"_extension":18},"/en-us/blog/auto-devops-enabled-by-default",{"title":1053,"description":1054,"ogTitle":1053,"ogDescription":1054,"noIndex":6,"ogImage":1055,"ogUrl":1056,"ogSiteName":670,"ogType":671,"canonicalUrls":1056,"schema":1057},"Auto DevOps will be enabled by default as part of GitLab’s 11.3 release","GitLab 11.3 will bring the power of Auto DevOps to every user","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/auto-devops-enabled-by-default","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Auto DevOps will be enabled by default as part of GitLab’s 11.3 release\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Gruesso\"}],\n        \"datePublished\": \"2018-09-10\",\n      }",{"title":1053,"description":1054,"authors":1059,"heroImage":1055,"date":1061,"body":1062,"category":298,"tags":1063},[1060],"Daniel Gruesso","2018-09-10","\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) was made generally available in GitLab’s 11.0 release and, while it has had great adoption,\nwe want all of GitLab's users to take advantage of its great features. From Auto Build to Auto Monitoring,\nAuto DevOps brings valuable benefits out of the box.\n\nAt GitLab, one of our product values is to [default to on](/handbook/product/product-principles/#configuration-principles).\nWhen we introduce a new configurable feature we know to be of great value, we will default to ON so that everyone can\nbenefit from it. While Auto DevOps supports projects using the most popular programming languages, there may be some\nspecialized projects for which additional configuration is required. Therefore, before we\nenable it for everyone, we want to ensure we will not be running Auto DevOps pipelines for projects\nthat are not supported. To that end, we will [disable auto devops automatically](https://gitlab.com/gitlab-org/gitlab-ce/issues/39923)\nif a pipeline fails. GitLab will notify the project owner of this attempt so they can make the necessary configuration\nchanges to work with auto devops if desired.\n\nWe will initially enable this feature gradually on gitlab.com and monitor its performance. Barring any\nissues, we will enable it as part of our 11.3 release for self-managed customers on September 22nd, 2018.\n\nWe hope that everyone will benefit from the great features Auto DevOps brings. You can read more\nabout [Auto DevOps here](https://docs.gitlab.com/ee/topics/autodevops).\n",[9,678,893],{"slug":1065,"featured":6,"template":683},"auto-devops-enabled-by-default","content:en-us:blog:auto-devops-enabled-by-default.yml","Auto Devops Enabled By Default","en-us/blog/auto-devops-enabled-by-default.yml","en-us/blog/auto-devops-enabled-by-default",{"_path":1071,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1072,"content":1078,"config":1084,"_id":1086,"_type":13,"title":1087,"_source":15,"_file":1088,"_stem":1089,"_extension":18},"/en-us/blog/auto-devops",{"title":1073,"description":1074,"ogTitle":1073,"ogDescription":1074,"noIndex":6,"ogImage":1075,"ogUrl":1076,"ogSiteName":670,"ogType":671,"canonicalUrls":1076,"schema":1077},"What's coming for Auto DevOps","We're working on a number of improvements to GitLab Auto DevOps – here's where it's at and where it's headed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667050/Blog/Hero%20Images/auto-devops-pipeline-stages.png","https://about.gitlab.com/blog/auto-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What's coming for Auto DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Ward\"}],\n        \"datePublished\": \"2020-04-30\",\n      }",{"title":1073,"description":1074,"authors":1079,"heroImage":1075,"date":1081,"body":1082,"category":678,"tags":1083},[1080],"Chris Ward","2020-04-30","[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) is designed to make CI/CD adoption easier, with baked-in best practices and automation to take care of moving your code seamlessly through the software development lifecycle. If you or your team are new to DevOps, this is a great place to start. We're excited to share some new and [upcoming improvements to Auto DevOps](#coming-soon), but first: \n\nThere is a prerequisite for Auto DevOps, and that's a Kubernetes cluster. This may or may not be an easy step for you to complete, but your team likely has a cluster set up already. If not, [read our getting started guide](https://docs.gitlab.com/ee/topics/autodevops/cloud_deployments/auto_devops_with_gke.html).\n\nAuto DevOps should be enabled by default, but if it isn't, go to _Settings > CI/CD > Auto DevOps_ and check _Default to Auto DevOps pipeline_. There are a lot of automated stages available, depending on what version and tier of GitLab you use, and which components you add to your Kubernetes cluster.\n\n1.  **Auto Build**: Builds your code using a _Dockerfile_ if your project has one, or a [Heroku buildpack](https://elements.heroku.com/buildpacks) selected based on the programming language you use, but you can manually set it.\n2.  **Auto Test**: Runs any tests included in your codebase, again using a Heroku buildpack.\n3.  **Auto Code Quality**: Runs static analysis and other checks over your code using the [code quality image](https://gitlab.com/gitlab-org/ci-cd/codequality).\n4.  **Auto SAST (Static Application Security Testing)**: Runs static analysis checks focussed on security issues using the [SAST image](https://gitlab.com/gitlab-org/security-products/sast).\n5.  **Auto Dependency Scanning**: Checks for potential security issues on project dependencies using the [dependency scanning image](https://gitlab.com/gitlab-org/security-products/dependency-scanning). \n6.  **Auto License Compliance**: Searches project dependencies for what licenses they use, using the [license compliance image](https://gitlab.com/gitlab-org/security-products/license-management).\n7.  **Auto Container Scanning**: Uses [Clair](https://github.com/quay/clair) to run static analysis and security issue checks on any Docker images used. \n8.  **Auto Review Apps**: Creates a version of an application in a temporary environment for team members to try and review.\n9.  **Auto DAST (Dynamic Application Security Testing)**: Runs further security checks using the [OWASP ZAProxy](https://github.com/zaproxy/zaproxy) tool.\n10. **Auto Deploy**: Deploys an application to a production environment as defined in the Kubernetes environment settings.\n11. **Auto Browser Performance Testing**: Tests the performance of application web pages using the [Sitespeed.io image](https://hub.docker.com/r/sitespeedio/sitespeed.io/).\n12. **Auto Monitoring**: Uses Prometheus to monitor system metrics for a deployed application.\n\n### Recent improvement: Readiness for Kubernetes 1.16 ([#32720](https://gitlab.com/gitlab-org/gitlab/issues/32720))\n\nWe recently reworked Auto DevOps features to [match changes in the Kubernetes 1.16 API](/releases/2020/03/22/gitlab-12-9-released/#auto-devops'-default-postgresql-due-to-change). Nothing you use will change, but behind the scenes, access different API endpoints, and in different ways.\n\n## Coming soon\n\nSeveral improvements are coming to Auto DevOps in our next few releases to ensure that we help your projects conform to the latest DevOps best practices, and integrate with as many of our platform features and external tools as possible.\n\n### Cloud-native buildpacks for Auto DevOps ([#25954](https://gitlab.com/gitlab-org/gitlab/issues/25954))\n\nSince Heroku created the buildback concept in 2011 when using virtual machines was typical, others have adopted the concept, and created their own that suited containers better. This change in need resulted in the Cloud Native Computing Foundation (CNCF) accepting the [Cloud Native Buildpacks project](https://buildpacks.io/) in 2018 to maintain a standard for buildpacks that suits their modern use cases. Also, in 12.10 we've added support to Cloud Native Buildpacks, and will be switching our \"traditional\" Heroku buildpacks to these newer ones in the coming months.\n\n### Running Auto DevOps on air-gapped networks ([#25642](https://gitlab.com/gitlab-org/gitlab/issues/25642))\n\nWhile many of our users have their clusters connected to the internet, we know not all do, and want to offer these customers as many features as possible. As part of GitLab 13.0, we are researching how to give you the ability to configure the locations of dependencies for Auto DevOps stages.\n\n### Upgrade to Helm 3 ([#29038](https://gitlab.com/gitlab-org/gitlab/issues/29038))\n\nWe use [Helm](https://helm.sh/) to deploy packages needed for various stages of the Auto DevOps process. In 13.1 we will upgrade Helm to version 3, which brought a series of significant changes, including removing Tiller as the \"server\" side of Helm.\n\n### NGINX alerts to auto-monitoring in Auto DevOps ([#118788](https://gitlab.com/gitlab-org/gitlab/issues/118788))\n\nNginx is a popular HTTP and reverse proxy server. In 13.0 we will add support for the metrics it exposes to Prometheus for providing alerts to our auto-monitoring feature.\n\n### Add Merge Train support to Auto DevOps ([#121933](https://gitlab.com/gitlab-org/gitlab/issues/121933))\n\n[Merge Trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) are a GitLab feature that let you queue lists of merge requests waiting for merging into a target branch. Auto DevOps doesn't currently support merge trains, but in version 13.1, we will start adding support and helping users get the configuration they need to add their Merge Trains to Auto DevOps workflows.\n\nYou can [read more about merge trains here](/blog/all-aboard-merge-trains/).\n\n## Looking further ahead\n\nThese planned features aside, one other area we are looking to improve is adopting more of a Directed Acyclic Graph (DAG) approach to Auto DevOps pipelines. You will no longer have to wait for one stage to complete before another begins, and you can focus on the results of the stages important to you. Feel free to view and comment on [the open issue](https://gitlab.com/gitlab-org/gitlab/issues/33200).\n\nWe are broadly working to make Auto DevOps work seamlessly with as many other GitLab features as possible, and hope you enjoy the time and insights it gives you.\n\nYou can [read more about Auto DevOps here](/blog/auto-devops-explained/).\n",[108,9,680],{"slug":1085,"featured":6,"template":683},"auto-devops","content:en-us:blog:auto-devops.yml","Auto Devops","en-us/blog/auto-devops.yml","en-us/blog/auto-devops",{"_path":1091,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1092,"content":1098,"config":1104,"_id":1106,"_type":13,"title":1107,"_source":15,"_file":1108,"_stem":1109,"_extension":18},"/en-us/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow",{"title":1093,"description":1094,"ogTitle":1093,"ogDescription":1094,"noIndex":6,"ogImage":1095,"ogUrl":1096,"ogSiteName":670,"ogType":671,"canonicalUrls":1096,"schema":1097},"Automate tedious coding tasks with GitLab Duo Workflow","See how agentic AI can reduce time spent on repetitive tasks, freeing you up to focus on developing innovative solutions and shipping the next big thing.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","https://about.gitlab.com/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automate tedious coding tasks with GitLab Duo Workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeff Park\"}],\n        \"datePublished\": \"2025-05-06\",\n      }",{"title":1093,"description":1094,"authors":1099,"heroImage":1095,"date":1101,"body":1102,"category":806,"tags":1103},[1100],"Jeff Park","2025-05-06","Working with large codebases often means spending significant time on repetitive tasks that, while necessary, don't really push your projects forward. The good news is that these tasks are great candidates to be completed with AI. Reducing the time spent on them will free you up to work on more important problems that you’re actually excited to tackle. With GitLab Duo Workflow, the time spent on these tasks will go from hours to minutes. \n\n[Duo Workflow](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/) is a powerful new agentic solution, currently in private beta, that lives in VS Code and is designed to help you complete complex development tasks. While many AI coding assistants are focused on helping developers write code, Duo Workflow understands your project structure, reads your files, and can make coordinated changes across your entire codebase.\n\nI created a demonstration that showcases how Duo Workflow can transform a tedious coding task into a streamlined process that saves you time and mental energy.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1081627484?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Automate tedious coding tasks with GitLab Duo Workflow\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## The challenge: Implementing a new lint rule\n\nIn this demo, we tackle a common scenario that many developers face: implementing a new lint rule and then updating multiple files across the codebase to comply with this rule. The specific issue involves validation errors occurring in several project files that need to be addressed consistently.\n\nRather than manually identifying and modifying each affected file one by one – a process that could take hours depending on the size of your codebase – we'll see how Duo Workflow can:\n\n1. Read and understand the details from an issue   \n2. Analyze the project structure to identify affected files  \n3. Create a comprehensive plan to implement the necessary changes  \n4. Draft a new lint rule to prevent future occurrences  \n5. Make consistent code changes across all relevant files  \n6. Stage the changes for your review before any commits are made\n\nA simple prompt initiates the process: \n\n\"Read through issue #1 in this project and submit code changes to resolve it. Be sure to look at each tool file and make all appropriate changes.\"\n\nFrom there, Duo Workflow takes over – reading the issue, analyzing the files, creating a plan, and implementing the solution – all while keeping me informed of its progress and reasoning.\n\n## Why this matters for your development process\n\nWhat's particularly powerful about Duo Workflow is how it maintains awareness of this wider context throughout the entire process. It's not just making text replacements based on a large language model's training data – it's understanding the code, making intelligent decisions, and proposing a complete solution that you maintain full control over.\n\nThis approach offers several key benefits:\n\n* **Consistency in implementation:** Apply changes uniformly across files  \n* **Time savings:** Focus your energy on creative problem-solving rather than repetitive tasks  \n* **Reduced context switching:** Complete complex tasks without leaving your IDE  \n* **Keeping a human in the loop:** Review all proposed modifications before committing\n\n## What's next\n\nGitLab Duo Workflow is part of our work to bring AI-powered capabilities to every stage of the software development lifecycle. While this demo focuses on code editing, the same approach can be applied to various development tasks:\n\n* Implementing new features based on issue descriptions  \n* Fixing bugs with comprehensive test coverage  \n* Refactoring legacy code to modern standards  \n* Creating documentation from codebase analysis\n\nWe believe that by automating repetitive tasks, Duo Workflow helps you focus on what matters most – solving interesting problems and creating innovative solutions for your users.\n\n> GitLab Duo Workflow is currently available in private beta for GitLab Ultimate customers. [Sign up for the waitlist today!](https://about.gitlab.com/gitlab-duo/workflow/)\n\n## Learn more\n- [Use GitLab Duo Workflow to improve application quality assurance](https://about.gitlab.com/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance/)\n- [Solving complex challenges with GitLab Duo Workflow](https://about.gitlab.com/blog/solving-complex-challenges-with-gitlab-duo-workflow/)\n- [GitLab Duo Workflow: Enterprise visibility and control for agentic AI](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [Emerging agentic AI trends reshaping software development](https://about.gitlab.com/the-source/ai/emerging-agentic-ai-trends-reshaping-software-development/)\n- [What is agentic AI?](https://about.gitlab.com/topics/agentic-ai/)\n",[786,478,9,701,746,894],{"slug":1105,"featured":90,"template":683},"automate-tedious-coding-tasks-with-gitlab-duo-workflow","content:en-us:blog:automate-tedious-coding-tasks-with-gitlab-duo-workflow.yml","Automate Tedious Coding Tasks With Gitlab Duo Workflow","en-us/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow.yml","en-us/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow",{"_path":1111,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1112,"content":1118,"config":1125,"_id":1127,"_type":13,"title":1128,"_source":15,"_file":1129,"_stem":1130,"_extension":18},"/en-us/blog/automating-with-gitlab-duo-part-1-generating-tests",{"title":1113,"description":1114,"ogTitle":1113,"ogDescription":1114,"noIndex":6,"ogImage":1115,"ogUrl":1116,"ogSiteName":670,"ogType":671,"canonicalUrls":1116,"schema":1117},"Automating with GitLab Duo, Part 1: Generating tests","Learn how we used the AI-driven DevSecOps platform to generate automated tests and improve our development speed and quality.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097480/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097480784.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automating with GitLab Duo, Part 1: Generating tests\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-02\",\n      }",{"title":1113,"description":1114,"authors":1119,"heroImage":1115,"date":1121,"body":1122,"category":806,"tags":1123},[1120],"Byron Boots","2024-12-02","Automated testing is time-consuming and can feel like it’s not moving a project forward. However, as many developers have likely experienced, automated testing provides an overall positive return on investment. In building a custom module (we'll call it gitlab-helper for this article), this was particularly true.\n\nOur initial development focused on migrating tried and used functionality from existing scripts to a new module whose sole purpose was to serve as a baseline for future functionality. Although existing scripts lacked automated testing, their consistent usage was strong anecdotal evidence the functionality worked as expected.\n\nOur objective was to deliver a more mature solution to this problem, so automated testing became a necessity. This introduced the challenge of building efficiently, while balancing the time to test and ensure a robust product; and with a total of three team members, this was no small bottleneck. Therefore, the team decided to take advantage of [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our suite of AI capabilities, for test generation, improving speed and quality of the delivered product.\n\nIn this three-part series on automating with GitLab Duo, we will cover:\n\n1. How we used GitLab Duo to generate tests for our code  \n2. How we worked interactively with GitLab Duo for more complex situations  \n3. The results we were able to achieve (Spoiler: 1 developer + GitLab Duo = 84% coverage in 2 days)\n\n## Using GitLab Duo to generate tests for code\n\nWhile functionality is available across tools, this article will cover using GitLab Duo in VS Code, with the [GitLab Workflow extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) to generate tests. Links to other GitLab Duo options are available in the [references](#references) below.\n\n### Install and enable GitLab Duo\n\nAs a prerequisite to using GitLab Duo, we ensured we had a GitLab Duo-enabled account. If you don't have GitLab Duo, you can [sign up for a free 60-day trial](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial).\n\nTo use GitLab Duo Chat in VS Code, we followed the [instructions for installation](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#use-gitlab-duo-chat-in-vs-code). Then, we were able to see the GitLab Duo Chat extension on the sidebar and open the Chat window.\n\n![Ask a question window](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097488918.png)\n\n### Generate tests with Chat\n\ngitlab-helper is a custom module built for standardizing interaction with the GitLab API across the team's work and extends other library functionalities to simplify development and scripting work. Once a method or feature was migrated to gitlab-helper and appeared to be implemented appropriately, the process to generate tests for it was simple:\n- Select the method, class, or entire file in the IDE.\n- Right-click on the selected code.\n- Under **GitLab Duo Chat**, select **Generate tests**.\n\n![Sequence to generate tests, including drop-down for generate tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097488919.png)\n\nWithin a few seconds, tests were generated and presented in the GitLab Duo Chat window. These tests can be reviewed and or added to the codebase, via copy/paste, into existing or new test files. As is the case with most natural language processing generations today, particularly around context, some of the initial tests created by GitLab Duo failed, thus requiring finetuning (for instance, when dealing with nested dependencies).\n\n> **Pro tip:** GitLab Duo does not auto-create files to add generated tests to. We found it was helpful to create new test files and add a `# Tests Generated by Duo` comment at the top of them and suffix them with `_duo.py` to indicate where the tests came from.\n\nGitLab Duo provided a great starting point for building out gitlab-helper’s automated testing and greatly improved test writing efficiency and code coverage, speeding up the development process substantially. Alongside GitLab Duo, numerous iterations of valuable tests were introduced into the gitlab-helper module with human oversight.\n\nRead the next installment in this series where we share [what we learned while using GitLab Duo for generating automated tests](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing/) and working interactively with AI for more complex situations.\n\n## References\n\nThere’s more than one way to use GitLab Duo to generate tests, check out the other options below:\n\n* The GitLab UI  \n* [The GitLab Web IDE (VS Code in the cloud)](https://docs.gitlab.com/ee/user/project/web_ide/index.html)  \n* VS Code, with the [GitLab Workflow extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow)  \n* JetBrains IDEs, with the [GitLab Duo Plugin for JetBrains](https://plugins.jetbrains.com/plugin/22325-gitlab-duo)  \n* Visual Studio for Windows, with the [GitLab Extension for Visual Studio](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio)\n",[786,746,1124,478,9],"testing",{"slug":1126,"featured":6,"template":683},"automating-with-gitlab-duo-part-1-generating-tests","content:en-us:blog:automating-with-gitlab-duo-part-1-generating-tests.yml","Automating With Gitlab Duo Part 1 Generating Tests","en-us/blog/automating-with-gitlab-duo-part-1-generating-tests.yml","en-us/blog/automating-with-gitlab-duo-part-1-generating-tests",{"_path":1132,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1133,"content":1139,"config":1144,"_id":1146,"_type":13,"title":1147,"_source":15,"_file":1148,"_stem":1149,"_extension":18},"/en-us/blog/automating-with-gitlab-duo-part-3-validating-testing",{"title":1134,"description":1135,"ogTitle":1134,"ogDescription":1135,"noIndex":6,"ogImage":1136,"ogUrl":1137,"ogSiteName":670,"ogType":671,"canonicalUrls":1137,"schema":1138},"Automating with GitLab Duo, Part 3: Validating testing","Discover what test we ran to validate the impact of GitLab Duo on our team’s automated testing – and the results we achieved.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097447/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097447404.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-3-validating-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automating with GitLab Duo, Part 3: Validating testing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-17\",\n      }",{"title":1134,"description":1135,"authors":1140,"heroImage":1136,"date":1141,"body":1142,"category":806,"tags":1143},[1120],"2024-12-17","In previous entries in this series, we covered [how we used GitLab Duo to generate tests for our code](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests/) as well as [what we learned while using GitLab Duo for generating automated tests](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing/). We also shared some of the ways we addressed making changes to GitLab Duo generated tests. This last article in the series will cover a test we ran to validate the impact of GitLab Duo on our team’s automated testing and discuss the impressive results we have achieved thus far.\n\n### Validation testing results\n\nTo validate that our usage of GitLab Duo to generate tests was adding value the way we expected, we challenged ourselves and GitLab Duo to replace and increase test coverage. The team removed all previously written tests to get our test coverage to 0% and then methodically went through the repository and created new test files to store GitLab Duo-generated tests.\n\nFrom this starting point, the team followed the steps outlined in [the first blog](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests/) to generate tests. Tests and test files were unmodified by humans to provide a stable control group and a `Tests Generated by Duo` comment at the top of them were suffixed by `duo.py` to indicate where the tests came from.\n\nAll iterations of the tests were only done through interactions with GitLab Duo through the `Generate Tests` and GitLab Duo Chat window as outlined in [the second blog in the series](https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing/). As we shared, we requested GitLab Duo to make updates based on encountered errors, test failures, and example code snippets for GitLab Duo to use as added context. \n\nAt all times. when testing with GitLab Duo, we were running tests and coverage reports so we could see if our GitLab Duo-generated tests were increasing testing coverage and adding value as we expected. Taking advantage of [GitLab's test coverage visualization](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization/), we were able to continuously monitor the results of our work.\n\nUltimately, after using GitLab Duo to regenerate tests for code previously covered through our mostly manual testing, we were able to achieve test coverage of 84%. This was a great accomplishment for the team because:\n\n1. It was a significant improvement from prior coverage, which was at 74%.  \n2. It took approximately two days by one engineer to achieve 84%, compared to the approximately four weeks across multiple engineers that the 74% had taken.\n\nSince this experiment, the team has increased coverage even further to 89% with the help of GitLab Duo, while continuing to introduce new features.\n\n![image of achievements](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097456/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097456771.png)\n\nUsing GitLab Duo allowed for increased testing efficiency and coverage, and also allowed developers with lower context around existing code to write valuable tests, quickly. This has resulted in increased confidence on the team to develop new features without worrying about introducing errors.\n\n> If you'd like to [try GitLab Duo](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/), sign up for a free, 60-day trial today!\n",[786,1124,478,9],{"slug":1145,"featured":6,"template":683},"automating-with-gitlab-duo-part-3-validating-testing","content:en-us:blog:automating-with-gitlab-duo-part-3-validating-testing.yml","Automating With Gitlab Duo Part 3 Validating Testing","en-us/blog/automating-with-gitlab-duo-part-3-validating-testing.yml","en-us/blog/automating-with-gitlab-duo-part-3-validating-testing",{"_path":1151,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1152,"content":1158,"config":1167,"_id":1169,"_type":13,"title":1170,"_source":15,"_file":1171,"_stem":1172,"_extension":18},"/en-us/blog/availability-postgres-patroni",{"title":1153,"description":1154,"ogTitle":1153,"ogDescription":1154,"noIndex":6,"ogImage":1155,"ogUrl":1156,"ogSiteName":670,"ogType":671,"canonicalUrls":1156,"schema":1157},"Introducing Patroni as the Postgres Failover Manager on GitLab.com","GitLab.com is introducing Patroni as the Postgres Failover Manager on GitLab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671280/Blog/Hero%20Images/gitlab-gke-integration-cover.png","https://about.gitlab.com/blog/availability-postgres-patroni","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing Patroni as the Postgres Failover Manager on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gerardo Lopez-Fernandez\"}],\n        \"datePublished\": \"2018-12-05\",\n      }",{"title":1153,"description":1154,"authors":1159,"heroImage":1155,"date":1161,"body":1162,"category":849,"tags":1163},[1160],"Gerardo Lopez-Fernandez","2018-12-05","\n\n## Upcoming Maintenance Windows for Patroni Deployment\n\nWe are writing this post to let our community know we are planning on performing the work necessary \nto deploy [Patroni](https://github.com/zalando/patroni) as the Postgres Failover Manager on GitLab.com over two weekends: a dry-run to test\nour migration plan and tools on Saturday, Dec 8, 2018, and the actual deployment on Saturday, December\n15, 2018.\n\nDuring the maintenance windows, the following services will be unavailable:\n\n* SaaS website ([GitLab.com](https://gitlab.com/) will be offline, but [about.gitlab.com](https://about.gitlab.com/) and [docs.gitlab.com](https://docs.gitlab.com/) will still be available)\n* Git ssh\n* Git https\n* registry\n* CI/CD\n* Pages\n\n### Maintenance Window - Dry run - Saturday, December 8 at 13:00 UTC\n\nWe will perform testing and validation of our deployment procedures and tools during this maintenance\nwindow to do final readiness checks. This maintenance window should last 30 minutes.\n\n### Maintenance Window - Actual Cutover - Saturday, December 15 at 13:00 UTC\n\nOn the day of the cutover, we are planning to start at 13:00 UTC.  The time window for GitLab.com to be\nin maintenance is currently planned to be 30 minutes. Should any times for this change, we will be updating\non the channels listed below. When this window is completed GitLab.com will be running Patroni.\n\n* [GitLab Status page](https://status.gitlab.com/)\n* [GitLab Status Twitter](https://twitter.com/gitlabstatus)\n\n",[9,9,1164,1165,1164,1166],"agile","bug bounty","contributors",{"slug":1168,"featured":6,"template":683},"availability-postgres-patroni","content:en-us:blog:availability-postgres-patroni.yml","Availability Postgres Patroni","en-us/blog/availability-postgres-patroni.yml","en-us/blog/availability-postgres-patroni",{"_path":1174,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1175,"content":1181,"config":1188,"_id":1190,"_type":13,"title":1191,"_source":15,"_file":1192,"_stem":1193,"_extension":18},"/en-us/blog/behind-the-scenes-of-gitlab-korean-translation",{"title":1176,"description":1177,"ogTitle":1176,"ogDescription":1177,"noIndex":6,"ogImage":1178,"ogUrl":1179,"ogSiteName":670,"ogType":671,"canonicalUrls":1179,"schema":1180},"Behind the scenes of GitLab's Korean translation","How a student project helped maintain linguistic consistency and deliver a unified user experience for the Korean GitLab community.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664472/Blog/Hero%20Images/gitlabflatlogomap.png","https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Behind the scenes of GitLab's Korean translation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Inchul Yoo, Sunjung Park\"}],\n        \"datePublished\": \"2023-10-05\",\n      }",{"title":1176,"description":1177,"authors":1182,"heroImage":1178,"date":1184,"body":1185,"category":827,"tags":1186},[1183],"Inchul Yoo, Sunjung Park","2023-10-05","\nGitLab is translated into many languages by community members, ensuring our product reaches a much wider audience. In recent months, software and computer engineering students from Ajou University in South Korea contributed translations as part of their classroom project, led by Prof. Hwanyong Lee. Their contributions, together with many other members of our community, resulted in [100% of strings in the GitLab UI being translated into Korean](https://translate.gitlab.com/project/gitlab-ee/ko). \n\n![photo of Korean translation contributors](https://about.gitlab.com/images/blogimages/translation-contributors-swag.jpg){: .medium.center}\n\nIn this blog post, [Inchul Yoo](https://gitlab.com/iyoo), solutions architect at GitLab, and [Sunjung Park](https://gitlab.com/sunjungp), senior product Designer at GitLab, who also volunteer as proofreaders for the Korean translation of GitLab in the [GitLab Crowdin project](https://crowdin.com/project/gitlab-ee), had the privilege to interview Prof. Lee. He shared the students' experience in contributing to GitLab and discussed areas where additional collaboration is needed for translation.\n\nThank you for your contributions to GitLab: \n- Dahee Kim (김다희, 아주대학교)\n- Myeong Seok Nam (남명석, 아주대학교)\n- Jongho Baik (백종호, 아주대학교)\n- Seoyoung Lee (이서영, 아주대학교)\n- Sungmin Lee (이승민, 아주대학교)\n- Jaeyoon Lee (이재윤, 아주대학교)\n- Hwanyong Lee (이환용 교수, 아주대학교)\n\n## Interview with Prof. Hwanyong Lee\n\n**Could you tell us about Ajou University and the department?**\n\nAjou University aims to cultivate software talents with diverse roles in the field of software as its primary focus. Using GitLab, students have opportunities to learn through practical experience covering most aspects of the DevOps lifecycle, including issue management, version control, building, and deploying software.\n\n**When did you start using GitLab, and for what purpose?**\n\nSince 2018, when Ajou University became a software-focused institution, we started to utilize GitLab for educational purposes, including tasks such as assignments and submissions. Currently, our GitLab instance hosts over 9,000 projects and serves more than 2,200 students.\n\n**What motivated you to translate all of GitLab's product interface text into Korean?**\n\nOutside of my professional responsibilities, I have been actively contributing to diverse open source projects. Given my role as a professor, I saw an opportunity to underscore the significance of open source contributions to my students and inspire them to engage in such activities. During this semester, I established the objective of involving students in open source projects, specifically focusing on Korean localization. Remarkably, more than 10 students eagerly volunteered to participate in the translation efforts of more than 10 open source projects into Korean.\n\n**How many students participated in the GitLab translation project, and how long did it take?**\n\nThere were seven students in total, both majoring and minoring in software and computer engineering. We distributed the tasks among them to collaborate on the project. The entire project was completed in approximately half a semester, which took about two months.\n\n**Each student may have different translations for the same words. How did you handle this?**\n\nWe managed this by creating our own glossary to ensure uniform translations. We collaborated to achieve consistency in the wording, and we synced regularly to discuss and resolve any ambiguous or contentious issues.\n\n**What was the most challenging aspect of the project?**\n\nOne of the biggest challenges we faced was the continuous addition of new strings and phrases with each new GitLab update. Keeping up with these additions proved to be quite challenging. Additionally, there were instances where there was no direct Korean equivalent for English terms, or where additional contextual explanations were required, making the translation process more complex.\n\nWhen students identified inconsistencies that were not covered by the glossary, I encouraged them to bring these up in the regular sync. We tried to determine which translated terms were commonly used. And we used the [Korean TTA standards (Telecommunications Technology Association) dictionary](https://terms.tta.or.kr/main.do) as a primary point of reference.\n\n**Could you provide some closing thoughts regarding the contribution?**\n\nThe students were surprised to discover their ability to actively participate in the open source software they rely on, leading to a newfound sense of pride. This transformation signified a shift in the focus to embracing the concept of community and recognizing the genuine value of open source software through their contributions to shared community-driven objectives.\n\n### Learn how you can contribute to translation\nContributing to translation is a journey that goes beyond words; it's about building a global community and making technology more accessible. As Professor Lee mentioned, students discovered they could actively engage in open source software, and this filled them with pride. It's a rewarding journey that goes beyond language, and it's an opportunity to make a meaningful impact on the tech world.\n\nSoftware can only be as usable and accessible to its users as it is understandable by them. Translation helps bridge the linguistic and cultural gaps that might be preventing your software from being adopted by a given community. Together with contributors, proofreaders also play an important role in helping new contributors succeed by ensuring the consistency and quality of translations. Did you know that the term \"merge request\" can be translated into Korean in various ways?\n\nA good place to start is the [Translate GitLab page](https://docs.gitlab.com/ee/development/i18n/), where you can learn how you can contribute to GitLab's externalization, translation, proofreading, and merging. If you have any questions, please join translate.gitlab.com or post questions on the [Crowdin discussions forum](https://translate.gitlab.com/project/gitlab-ee/discussions).\n\nTo participate in discussions building a glossary list for Korean translation, join us at [gitlab.com/korean-translation/gitlab](https://gitlab.com/korean-translation/gitlab)! Once we finalize the glossary list and establish grammar rules, we aim to consistently elevate the quality of our translations.\n",[1187,266,9],"open source",{"slug":1189,"featured":6,"template":683},"behind-the-scenes-of-gitlab-korean-translation","content:en-us:blog:behind-the-scenes-of-gitlab-korean-translation.yml","Behind The Scenes Of Gitlab Korean Translation","en-us/blog/behind-the-scenes-of-gitlab-korean-translation.yml","en-us/blog/behind-the-scenes-of-gitlab-korean-translation",{"_path":1195,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1196,"content":1201,"config":1209,"_id":1211,"_type":13,"title":1212,"_source":15,"_file":1213,"_stem":1214,"_extension":18},"/en-us/blog/best-practices-customer-feature-request",{"title":1197,"description":1198,"ogTitle":1197,"ogDescription":1198,"noIndex":6,"ogImage":1055,"ogUrl":1199,"ogSiteName":670,"ogType":671,"canonicalUrls":1199,"schema":1200},"How to incorporate private customer needs into a public product roadmap","We've had lots of experience documenting and tracking private customer feature requests effectively. Here's our best advice and how to get the most out of GitLab issues and issue trackers.","https://about.gitlab.com/blog/best-practices-customer-feature-request","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to incorporate private customer needs into a public product roadmap\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"},{\"@type\":\"Person\",\"name\":\"Neil McCorrison\"}],\n        \"datePublished\": \"2021-09-23\",\n      }",{"title":1197,"description":1198,"authors":1202,"heroImage":1055,"date":1205,"body":1206,"category":849,"tags":1207},[1203,1204],"Christina Hupy, Ph.D.","Neil McCorrison","2021-09-23","\n\nEffectively communicating a customer’s private needs to product teams is essential to a product’s success, but it can be a tricky undertaking.\n\nTeams can face several challenges in communicating and tracking customers' requests, including protecting customer confidentiality, tracking priority and progress, and making sure the product team is getting actionable feedback that can be incorporated into product milestones.\n\nThis blog post shares GitLab's best practices and lessons learned, as well as a video conversation between GitLab CEO [Sid Sijbrandij](/company/team/#sytses) and Fleet CEO [Mike McNeil](https://www.linkedin.com/in/mikermcneil/).\n\nIn line with GitLab's [open core model](/company/stewardship/) and [transparency value](https://handbook.gitlab.com/handbook/values/#transparency), our product roadmap is public and the product team uses [public issue trackers](/gitlab-com/Product/-/issues) for feature requests and to plan the work. Because the issues are public, customers and community members can see how the product team works, what direction we are headed, and what the priorities are. Contributors can even decide to create a feature themselves.\n\nEver wonder what a DevOps Platform could do for your team? [Here's what you need to know](/solutions/devops-platform/)\n\nWhen a customer indicates a feature request to a technical account manager (TAM), the manager searches for the relevant open feature request in the product teams' issue tracker and adds a comment with generic details about the customer such as number of users and product. If an issue for that feature request does not already exist, the technical account manager can create an issue with the [Feature Proposal](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Proposal%20-%20lean) issue template then and add the customer’s request as a comment.\n\nFor example, the comment should include the following:\n\n> Hello `@product-manager`,  an Ultimate customer with 1500 users (`salesforce-link`) would like to see this feature prioritized, ideally within the next 6 months. They need this feature in order to X, which is important to them because Y, and they do not currently have a workaround. Additionally, releasing this feature would result in an estimated 250 additional users.\n\nThe TAM includes a link to the account in the customer relationship management system (CRM), in GitLab’s case Salesforce, so the internal teams can view the details. We even have a [feedback template](/handbook/product/how-to-engage/#feedback-template) to ensure the proper details are captured in the comment. The comment is public but the record in the CRM is private.\n\nThe product manager reviews the request and responds. Relevant [labels](/handbook/customer-success/csm/product/#priority-of-feature-requests) are added based on priority. For example, labels include **critical requests**, **high-priority requests**, **low priority requests** or **promised to a customer**. Milestones can be assigned to track timelines and make sure the feature ships on time. The feature tracking issue should be maintained regularly and acts as the single source of truth on the customer needs. These issues can also be reviewed for metrics on previously delivered feature requests.\n\n**Elevating your DevOps skills? Join us at [Commit at KubeCon - Oct. 11!](/events/commit/)**\n\nIn this case, a noisy feature request issue with comments from customers is a good thing. It helps the product manager directly see where the action is and how customers would benefit, and it also helps when prioritizing what feature ships next. Seeing direct input from the customers provides context and also creates developer empathy and connection with the end user. Additional team members, including [solution architects](https://handbook.gitlab.com/job-families/sales/solutions-architect/) find it useful to subscribe to these issues, keeping them automatically updated on progress and discussion by the product team.\n\n**Getting the product team involved early on is essential** to the success of this workflow. Another essential element is that the CSMs bring their customers'feedback directly to the issue where the work is being planned and prioritized.\n\n**Contributing to GitLab:**   Once a product manager has triaged an issue and applied the appropriate [Product Development Workflow](/handbook/product-development-flow/) labels, it may be deemed that the feature is ready for the customer or community to help build the feature directly. Our motto is \"Everyone Can Contribute\", and the ~\"Accepting Merge Requests\" label ([handbook](/handbook/engineering/quality/triage-operations/#sts=Accepting%20merge%20requests)) is a great way to identify when a feature is ready for a community contribution. Customers who wish to contribute back to GitLab can ask for a [Merge Request Coach](https://handbook.gitlab.com/job-families/expert/merge-request-coach/) to help guide them through the process to ensure timely review and alignment with our engineering best practices.\n\nGitLab learned early on that creating a separate issue for customer feedback can get complicated and ends up being disjointed from where the product managers are doing their work.\n\nIn summary, best practices for delivering customer feature requests to the product team include:\n\n* Ensure the feedback is directly where the product managers are working and prioritizing features.\n* Provide only generic details on the customer with a link to internal confidential information, but provide as much detail as possible regarding the customer's use case and business need.\n* Share the feature request issue back with the customer. If they feel inclined, they can comment and add details. This builds trust between the customer, their account team, and the product team.\n* Labels and milestones are essential for tracking. If something is critical to the customer, make sure the labels and milestones indicate as such.\n* The feature request issue should act as the single source of truth for the customers' needs; aggregating this information elsewhere results in a disconnect between the need and the work.\n\nWatch the full discussion between Sid and Mike:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/JH2cFhoUzsI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\nSid discussing GitLab's best practices on tracking customer feedback with Fleet CEO Mike McNeil\n{: .note}\n\n",[894,9,1208,829],"customers",{"slug":1210,"featured":6,"template":683},"best-practices-customer-feature-request","content:en-us:blog:best-practices-customer-feature-request.yml","Best Practices Customer Feature Request","en-us/blog/best-practices-customer-feature-request.yml","en-us/blog/best-practices-customer-feature-request",{"_path":1216,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1217,"content":1223,"config":1230,"_id":1232,"_type":13,"title":1233,"_source":15,"_file":1234,"_stem":1235,"_extension":18},"/en-us/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"title":1218,"description":1219,"ogTitle":1218,"ogDescription":1219,"noIndex":6,"ogImage":1220,"ogUrl":1221,"ogSiteName":670,"ogType":671,"canonicalUrls":1221,"schema":1222},"Best practices to set up organizational hierarchies that scale","Learn how to model organizational hierarchy in GitLab. Create structures with clear lines of communication, strategic alignment, and more, while following Agile principles.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098165/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098164666.png","https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Best practices to set up organizational hierarchies that scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-22\",\n      }",{"title":1218,"description":1219,"authors":1224,"heroImage":1220,"date":1226,"body":1227,"category":1228,"tags":1229},[1225],"Amanda Rueda","2024-07-22","Maximizing the benefits of your GitLab subscription begins with an effective organizational setup. Here’s a straightforward guide to configuring your group, subgroup, and project structure to enhance your GitLab experience.\n\n## Understanding the structure: Groups, subgroups, and projects\n\nGroups and projects allow you to model your organizational hierarchy, enabling advanced permissions management and “team of teams” planning. Use groups and subgroups for strategic planning and configuration management that cascades into subgroups and projects lower in the hierarchy.\n\nBeyond this, you can also model your value streams, enhancing project management and collaboration across your organization.\n\n- **Project level (team level)**\n    - Nested within groups or subgroups, projects are where your actual work happens. This is where repositories live, and settings specific to the project are managed. Zoom into day-to-day activities and detailed project tracking at this level.\n    - Effective project configuration helps maintain clean, organized data, which is essential for accurate reporting and analysis.\n\n- **Subgroup level (team of teams)**\n    - Subgroups provide granular permissions management and can be tailored to specific team or project needs, ensuring consistent workflows across your organization.\n    - Subgroups function as clusters of related projects, similar to how a \"team of teams\" operates in Agile.\n    - This level is ideal for managing several teams working towards a common product or service. It facilitates cross-project visibility and integration, which supports synchronization between teams to align on interdependencies and shared objectives.\n\n- **Group level (team of team of teams)**\n    - Think of groups as your organizational pillars within GitLab where broad permissions and access are managed.\n    - At the highest level, groups encompass multiple subgroups and represent the strategic tier of project management, akin to the \"team of team of teams\" in Agile.\n    - This level sets the overarching goals and strategies, defining settings and allocating resources across projects and subgroups to ensure alignment with the company's broad business objectives.\n\nBy structuring your organization with GitLab, you parallel your chosen Agile methodology, which can help you apply Agile principles more naturally across your projects. This structure promotes clear lines of communication, efficient resource management, and strategic alignment, all while maintaining the flexibility and responsiveness inherent to Agile methodologies.\n\n> Keep up with news and insights about [GitLab Agile planning](https://about.gitlab.com/blog/categories/agile-planning/).\n\n## Leveraging the GitLab inheritance model\n\nOne of GitLab's powerful features is its [inheritance model](https://docs.gitlab.com/ee/tutorials/scrum_events/index.html#understanding-the-inheritance-model-in-gitlab), which allows settings, permissions, and configurations made at higher levels to automatically apply to lower levels within the hierarchy. Conversely, data at lower levels is instinctively available at higher levels in the structure. With the inheritance model, you gain visibility across your entire portfolio from within higher-level groups while providing distinct locations lower in the hierarchy for individual teams to manage their work.\n\nExamples:\n- **Create milestones and labels in your higher-level groups** to cascade down to all subgroups and projects promoting consistency and adherence to organizational standards.\n- **Issues and epics** in lower level projects and subgroups roll up your value stream hierarchy for ease of reference by program management and the executive layer.\n- **Manage user permissions at the group level or top-level subgroup** to optimize permissions and access control. This can simplify access control management and ensure that the right people have the right access across multiple projects without the need for repeated configuration.\n\nThese tips not only streamline administrative overhead but also reinforce security and compliance by ensuring that changes at the higher level consistently propagate downwards.\n\n![Organizational hierarchy diagram](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098179305.png)\n\n## Best practices for GitLab setup\n\nWhen setting up your GitLab organizational hierarchy, we recommend the following options depending on your organization's needs. Self-managed customers have the option to omit the \"Company Name\" root group layer, as this extra level of organization is not necessary for self-managed deployments. This flexibility ensures that your GitLab setup is tailored to your specific organizational structure and deployment preferences.\n\n### Option 1: Permissions and access are granted at the organizational subgroup level\n\nThis option is ideal for complex permission structures or large organizations needing efficient project sharing across numerous users.\n\n#### Example structure\n\n- Organizational Group\n    - Handles broad permissions typically through integrations with corporate provisioning systems.\n    - Users are added to subgroups, which will serve as the foundation for sharing the entire group with another [group](https://docs.gitlab.com/ee/user/group/manage.html#share-a-group-with-another-group) or a [project](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html) to minimize the overhead of direct user management.\n    - When creating user groups, you can utilize [group mentions](https://docs.gitlab.com/ee/user/discussions/index.html#mentions) throughout GitLab to mention large groups of users at a time.\n\n- Development Group\n    - Provides executive-level and program-management-level visibility across all development projects at the highest development group level.\n    - Features are created at the subgroup level for access across multiple repos.\n    - Projects are created to hold development repos; this is the level for Team visibility.\n\n![organizational chart for subgroup level](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_1_aHR0cHM6_1750098179306.png)\n\n### Option 2: Permissions and access are granted at any level\nThis option is best for smaller organizations with less complex access requirements. Users are added individually to the divisional groups, subgroups, or projects as access is required. This provides direct control over project management and operational visibility.\n\n#### Highlights\n- Users can be added to a group at the top of the hierarchy or to the lower-level subgroup/project depending on the granularity of access needs. Each member would need to be individually added rather than a single task of sharing a group.\n- Executive-level and program-management-level visibility across all development projects at the highest development group level.\n- Features are created at the subgroup level for access across multiple repos.\n- Projects are created to hold development repos; this is the level for Team visibility.\n\n![Permissions granted at any level](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_2_aHR0cHM6_1750098179307.png)\n\n### Additional configuration considerations\n\n- Milestones and iterations\n    - Create group-level milestones for broad visibility or when milestones need to be shared across groups.\n    - Create milestones at the project level when the milestone is specific to a single project.\n    - For teams working across different groups, setting iterations at the parent group level is beneficial for unified tracking.\n\n- Data management\n    - Leverage GitLab's roadmaps, boards, and listing pages to pull data that reflects your organizational setup. This helps you visualize progress and plan effectively across different levels of your structure.\n    - GitLab makes data available in higher-level groups even when the data is created in lower levels.\n    - Create your views at higher levels when you want to view data across groups and projects, and at lower levels when you want to hone in on a specific group or project’s data.\n\n- Template creation\n    - Create higher-level templates to ensure they cascade to all subsequent subgroups and projects, mixing general guidelines with project-specific requirements.\n    - Templates are created within their own repository within the applicable group ([related documentation](https://docs.gitlab.com/ee/user/project/description_templates.html)).\n\n- Labels\n    - Create higher-level labels to ensure they cascade to all subsequent subgroups and projects, mixing org labels with project-specific labels.\n    - Use scoped labels to define organizational structures like teams and workflow status.\n\n![Issue board with labels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098179310.png)\n\n## Leveraging GitLab’s features for optimal performance\n\nImplementing the right structure in GitLab not only streamlines the management of your software projects but also enhances the visibility across different levels of your organization, ensuring that everyone from the top management to individual contributors has the information they need to make informed decisions.\n\n> Get started modeling organizational hierarchy with [a free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n","agile-planning",[1164,9,478],{"slug":1231,"featured":6,"template":683},"best-practices-to-set-up-organizational-hierarchies-that-scale","content:en-us:blog:best-practices-to-set-up-organizational-hierarchies-that-scale.yml","Best Practices To Set Up Organizational Hierarchies That Scale","en-us/blog/best-practices-to-set-up-organizational-hierarchies-that-scale.yml","en-us/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"_path":1237,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1238,"content":1244,"config":1251,"_id":1253,"_type":13,"title":1254,"_source":15,"_file":1255,"_stem":1256,"_extension":18},"/en-us/blog/boring-solutions-faster-iteration",{"title":1239,"description":1240,"ogTitle":1239,"ogDescription":1240,"noIndex":6,"ogImage":1241,"ogUrl":1242,"ogSiteName":670,"ogType":671,"canonicalUrls":1242,"schema":1243},"Want to iterate faster? Choose boring solutions","We’ve released 106 times in 106 months, proof that boring solutions do work when it comes to software development. Here are some of our favorites.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681499/Blog/Hero%20Images/pencils2.jpg","https://about.gitlab.com/blog/boring-solutions-faster-iteration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Want to iterate faster? Choose boring solutions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-08-18\",\n      }",{"title":1239,"description":1240,"authors":1245,"heroImage":1241,"date":1247,"body":1248,"category":1249,"tags":1250},[1246],"Valerie Silverthorne","2020-08-18","\n\n*bor-ing* | *bȯr-iŋ*\n\n_Definition of boring: causing weariness and restlessness through lack of interest : causing boredom : tiresome_ –– Merriam-Webster\n\nAt GitLab we’re boring and we’re proud of it. \"Use the simplest and most boring solutions for a problem, and remember that 'boring' should not be conflated with 'bad' or technical debt,\" our [handbook](/handbook/) says. \"The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors.\"\n\nAlthough this may seem like counterintuitive behavior at a fast moving software startup, boring solutions are actually grounded in both science and history. [Boyd’s Law of Iteration](https://blog.codinghorror.com/boyds-law-of-iteration/) proves that faster iteration is superior to the quality of iteration. We feel like our history of releasing 106 times in 106 months also proves this point. We’ve managed [to iterate so quickly month after month](/blog/observations-on-how-to-iterate-faster/) *because* we’ve chosen the boring solution.\n\nIf this isn’t enough to convince your team to choose the boring solution more often, we’ve rounded up a slew of boring choices we’ve made to help you make the case (and maybe speed up your software delivery).\n\n## Issue labels\n\nAn early boring solution was the choice to use issue labels to power lists on issue boards. Instead of creating a new system, the boring solution was to use what we had to make a small iteration and get entirely new functionality. (Candidly - this design decision has become a huge pain point, but it’s still a great example of a boring solution) –– [William Chia](/company/team/#williamchia), senior product marketing manager, cloud native & [GitOps](/solutions/gitops/)\n\n## Skip the new UI\nWe created documentation around using [curl](https://curl.haxx.se) against API endpoints instead of creating a new user interface. –– [Nicholas Klick](/company/team/#nicholasklick), backend engineering manager, Configure\n\nWe chose to use a JSON Web Token to authenticate with Vault vs. building out a new UI or CLI. –– [Jackie Meshell](/company/team/#jmeshell), senior product manager, Release:Release Management\n\n## Embrace a small change\nWe recently added awareness [if a security scanner isn’t enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/214392) from the project-level security dashboard. Previously there was no way to know this without going to the Configuration page. While it’s a small change, we’ve received good feedback so far, and hopefully encourages customers to take more advantage of our Gold/ Ultimate offering (and keep their applications safer!) –– [Becka Lippert](/company/team/#beckalippert), product designer, Secure\n\n## Boring = less confusing\nWe spent some time and research deciding among multi-select dropdowns, single-select dropdowns, and plain dropdowns. It was a simple but effective process and prompted team member [Austin Regnery](/company/team/#aregnery), product designer, Manage:Compliance, to comment, “Before joining GitLab I remember reading [this issue](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/443) and being really impressed by both the boring solution and data-driven decision making.\n\n## Boring can also make work easier\nWe made it easier to read the title of an issue without having to scroll back to the top of the page. We initially proposed only the title would stick, but then we did a quick solution validation and found out the MVC was to include the issue status. We paired the first iteration back from a solution that would include other objects (like MRs, epics, etc.) and chose to scope it down just to issues. We also pushed back on making other elements sticky (like the tab nav) [in the first iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/216880). –– [Mike Long](/company/team/#mikelong), product design manager, Plan & Manage\n\n## If boring doesn’t work, abandon it\nIn GitLab’s early days, we used [Gitolite](https://gitolite.com/gitolite/index.html) and the SSH key list. They were boring solutions. They were not elegant but allowed us to focus on adding value. When it no longer worked, we [changed it](/blog/gitlab-without-gitolite/). –– [Sid Sijbrandij](/company/team/#sytses), CEO\n\n## Who needs fancy?\n\nAnd if there’s any doubt that we won’t reach for something shiny when something simple will do, we’ll leave you with these two anecdotes.\n\nWe use SQL for the CI job queue. –– [Stan Hu](/company/team/#stanhu), engineering fellow\n\nAnd, when we made the decision to move from Azure to GCP, we used the most boring solution ever – a checklist (no, really, a checklist) to help us make the process seamless. We made 140 changes to that checklist, all told, but after that careful process, [we were able to migrate from Azure to GCP with no serious issues](/blog/gitlab-journey-from-azure-to-gcp/).\n\n*Read more about faster software delivery:*\n\nPro tips for a faster [CI/CD pipeline](/blog/effective-ci-cd-pipelines/)\n\nKeep your [Kubernetes runners moving](/blog/best-practices-for-kubernetes-runners/)\n\nGet [faster and more flexible pipelines](/blog/directed-acyclic-graph/)\n\nCover image by [Frank Vessia](https://unsplash.com/@frankvex?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n","insights",[680,893,9],{"slug":1252,"featured":6,"template":683},"boring-solutions-faster-iteration","content:en-us:blog:boring-solutions-faster-iteration.yml","Boring Solutions Faster Iteration","en-us/blog/boring-solutions-faster-iteration.yml","en-us/blog/boring-solutions-faster-iteration",{"_path":1258,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1259,"content":1265,"config":1271,"_id":1273,"_type":13,"title":1274,"_source":15,"_file":1275,"_stem":1276,"_extension":18},"/en-us/blog/browser-based-dast-feature-announcement",{"title":1260,"description":1261,"ogTitle":1260,"ogDescription":1261,"noIndex":6,"ogImage":1262,"ogUrl":1263,"ogSiteName":670,"ogType":671,"canonicalUrls":1263,"schema":1264},"Introducing browser-based DAST and integrated passive checks","We're working hard on reducing noise. Here's what you need to know about the status of our browser-based DAST offering today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682466/Blog/Hero%20Images/vek-labs-e8ofKlNHdsg-unsplash.jpg","https://about.gitlab.com/blog/browser-based-dast-feature-announcement","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing browser-based DAST and integrated passive checks\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"}],\n        \"datePublished\": \"2022-10-19\",\n      }",{"title":1260,"description":1261,"authors":1266,"heroImage":1262,"date":1268,"body":1269,"category":701,"tags":1270},[1267],"Isaac Dawson","2022-10-19","\n\nThe [DAST](/direction/secure/dynamic-analysis/dast/) and [Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/) teams at GitLab are excited to announce we have fully [integrated passive checks](/releases/2022/08/22/gitlab-15-3-released/#browser-based-dast-passive-check-milestone) into our new [browser-based DAST analyzer](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html). Passive checks work by monitoring the network traffic to target applications while the web site is automatically crawled. This allows us to identify weaknesses that may exist without sending potentially disruptive network requests. This continues our effort to fully switch over to our browser-based analyzer for DAST in the coming months. If you are interested in using our new DAST analyzer please see our [documentation on how to configure a browser-based DAST scan](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html).\n\n## History of DAST at GitLab\n\nDAST was [officially launched](/releases/2018/01/22/gitlab-10-4-released/) as a part of the GitLab 10.4 release in January 2018. By utilizing the powerful OWASP [Zed Attack Proxy](https://www.zaproxy.org/) we were able to give our customers the ability to dynamically scan\ntheir web applications. From that initial minimal viable product, we have grown to the point where we are now running over a million scans a month.\n\nScanning web applications in the CI/CD context comes with challenges. Unlike [SAST](/direction/secure/static-analysis/sast/), which is relatively fast, dynamically scanning an application can take a significant amount of time. DAST is resource intensive as it needs to process each request and response to the target application. To ensure smooth operations for the majority of our customers we have to run under the assumption that our memory and CPU footprints should be as small as possible. Finally, and most likely the biggest pain point, is the disconnect that often occurs when trying to visualize or understand how a web application should be analyzed when one can not physically see any of the interactions between the scanner and the target application.\n\nZAP was originally built as a desktop application, meaning auditors could use it to see the target application while conducting their testing. Only by utilizing ZAP's scripting API could we make DAST scans viable in a CI/CD context. This surfaced some challenges: what is easy to configure in the UI may or may not be straightforward to adjust from a configuration file or a command line option. \n\nWhen reviewing our support tickets however, a very clear picture began to surface. Users were having the most problem with configuring authentication for their applications. This makes sense, as it is where the user interacts with the scanner the most. Modern applications almost require a browser to authenticate, due to relying on browser features like local or session storage. These features are commonly used for handling JSON Web Token (JWT) based authentication and authorization. \n\nIt should be noted that ZAP does have a browser based crawler extension, called AJAX Spider. This extension uses [Crawljax](https://github.com/crawljax/crawljax). GitLab provides this feature by supplying the correct CI/CD variable, but it is no longer recommended. AJAX Spider is however, only an extension, and does not represent a tight integration between the browser and the DAST tool. \n\n## A path forward\n\nWe needed a system where we could have full control over a browser to allow us to instrument interactions between a website and the DAST tool. A DAST tool which does not tightly integrate with a browser will be limited in its ability to fully interact with today's demanding web applications. Just some of the challenges of this are:\n\n- Single Page Applications (SPAs)\n- Complex, multi-step sign in features\n- Complex front-end frameworks  \n- Utilization of built-in browser features (e.g. usage of localStorage or sessionStorage) \n\nA new DAST tool based completely off instrumenting a browser and written in Go would give GitLab a lot more control going forward. What started as a side project during nights and weekends began to show some promise. The Vulnerability Research and DAST teams worked together to assess the viability of building out this DAST analyzer. To allow us to take advantage of new features without having to implement the entire engine, we opted to continue to use ZAP as the proxy. This means our analyzer is forwarding all the browser traffic through ZAP, but processing logic of crawling and passive checks are now done in our engine. While we've been relatively quiet on our progress, we've been incrementally rolling out new features with almost every release. The end goal is to completely replace ZAP with our own engine.\n\n## Where we are today\n\nOf course the biggest announcement is that we have fully switched over to using our own vulnerability check system for passive checks. These checks replace ZAP's \"passive\" checks. The Vulnerability Research team invested a lot of time looking over how each ZAP plugin worked and determined whether it was worth implementing, or if it should be implemented differently. Alert fatigue is a real concern we share with our customers. By reducing the noise (false positives) in our DAST offering, we hope to reduce the chance of our customers ignoring real findings. As such, our goal is to significantly reduce the noise that is usually associated with DAST scan results, and this is achieved through three different methods:\n\n1. Not implementing certain checks\n2. Reducing false positives (incorrect findings) \n3. Aggregating true positives (real findings)\n\nPoint one is worth expanding upon. DAST vulnerabilities are unique in that in some cases the fix for a vulnerability is reliant on the browser or user-agent being modified, and not  the target application. Browsers increase their security directly or have it increased by deprecating features that were used in attacks. Browsers deciding to disable Flash is a good example of this – what was a vulnerability yesterday may no longer be a vulnerability today. \n\nZAP's check for [Charset mis-match](https://www.zaproxy.org/docs/alerts/90011/) is another case in point. After [researching](https://gitlab.com/gitlab-org/gitlab/-/issues/331218) what was possible in 2022, it turns out this is no longer an issue worth reporting. Other DAST tools report similar issues that are no longer realistically exploitable or worth reporting, so this is not just an issue with ZAP. \n\nReducing false positives is another major initiative, and one that led us to create a rather unique system for creating new vulnerability checks. Traditionally, DAST tools use a plugin architecture of hardcoded vulnerability checks. While quick to implement, they can have the downside of being difficult to understand or error prone. They are also harder to implement in a standardized way. At GitLab we opted to use a configuration-file-based check system, much like today's SAST tools. \n\nFinally, aggregating true positives allows us to merge similar issues into a single finding. These types of issues are usually fixed by a single configuration change, such as adding a security header.\n\nOur passive checks are almost entirely written in YAML, using a custom specification that allows us to define a check as text. Where this is not feasible, reusable components are written that can be referenced by various checks. Below is an example check that looks for the `X-Content-Type-Options` header in HTTP response headers and reports if it is missing the `nosniff` value.\n\n```yaml\n",[1124,9,871],{"slug":1272,"featured":6,"template":683},"browser-based-dast-feature-announcement","content:en-us:blog:browser-based-dast-feature-announcement.yml","Browser Based Dast Feature Announcement","en-us/blog/browser-based-dast-feature-announcement.yml","en-us/blog/browser-based-dast-feature-announcement",{"_path":1278,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1279,"content":1285,"config":1291,"_id":1293,"_type":13,"title":1294,"_source":15,"_file":1295,"_stem":1296,"_extension":18},"/en-us/blog/build-and-run-containers-in-remote-development-workspaces",{"title":1280,"description":1281,"ogTitle":1280,"ogDescription":1281,"noIndex":6,"ogImage":1282,"ogUrl":1283,"ogSiteName":670,"ogType":671,"canonicalUrls":1283,"schema":1284},"Build and run containers in Remote Development workspaces","Use this easy-to-follow tutorial to create a secure, ephemeral, reproducible development environment in GitLab that can replace your local environments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663857/Blog/Hero%20Images/blog-image-template-1800x945__12_.png","https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Build and run containers in Remote Development workspaces\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vishal Tak\"}],\n        \"datePublished\": \"2025-03-03\",\n      }",{"title":1280,"description":1281,"authors":1286,"heroImage":1282,"date":1288,"body":1289,"category":701,"tags":1290},[1287],"Vishal Tak","2025-03-03","Development environments often require the ability to build and run containers as part of their local development. Securely running containers within containers can be challenging. This article will provide a step-by-step guide to securely build and run containers in a workspace.\n\nYou will learn how to:\n- [Create a Kubernetes cluster on AWS EKS](#create-a-kubernetes-cluster-on-aws-eks)\n- [Configure Sysbox](#configure-sysbox)\n- [Configure GitLab agent for Kubernetes and GitLab Workspaces Proxy](#configure-gitlab-agent-for-kubernetes-and-gitlab-workspaces-proxy)\n- [Configure sudo access for a workspace with Sysbox](#configure-sudo-access-for-a-workspace-with-sysbox)\n- [Configure Ingress Controller](#configure-ingress-controller)\n- [Build containers inside a workspace](#build-containers-inside-a-workspace)\n- [Run containers inside a workspace](#run-containers-inside-a-workspace)\n- [Get started today](#get-started-today)\n\n## Create a Kubernetes cluster on AWS EKS\nInstall the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) on your local machine. Next, configure a [named profile](https://docs.aws.amazon.com/cli/latest/reference/configure/) and export it to ensure all the following `aws` commands use the set credentials.\n\n```\naws configure --profile gitlab-workspaces-container-demo\nexport AWS_PROFILE=gitlab-workspaces-container-demo\n```\n\nInstall [eksctl](https://eksctl.io/installation/), a CLI to interact with AWS EKS. Let’s now create a Kubernetes 1.31 cluster on AWS EKS with 1 node of Ubuntu 22.04 of `c5.2xlarge` instance type. The nodes can autoscale from 0-20 nodes and each node will have a label `sysbox-install: yes` . This will be explained later in the article.\n\n```\nexport CLUSTER_NAME=\"gitlab-workspaces-container-demo-eks-sysbox\"\n\neksctl create cluster \\\n  --name \"${CLUSTER_NAME}\" \\\n  --version 1.31 \\\n  --node-ami-family=Ubuntu2204 \\\n  --nodes=1 \\\n  --nodes-min=0 \\\n  --nodes-max=20 \\\n  --instance-types=c5.2xlarge \\\n  --node-labels \"sysbox-install=yes\" \\\n  --asg-access \\\n  --external-dns-access \\\n  --full-ecr-access\n```\n\nCreate an [IAM OIDC](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) provider for your cluster.\n\n```\neksctl utils associate-iam-oidc-provider --cluster \"${CLUSTER_NAME}\" --approve\n```\n\nCreate IAM role for [EBS add-on](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) for EKS.\n\n```\neksctl create iamserviceaccount \\\n  --name ebs-csi-controller-sa \\\n  --namespace kube-system \\\n  --cluster \"${CLUSTER_NAME}\" \\\n  --role-name \"AmazonEKS_EBS_CSI_DriverRole_${CLUSTER_NAME}\" \\\n  --role-only \\\n  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \\\n  --approve\n```\n\nCreate Amazon EBS CSI driver add-on for Amazon EKS cluster.  \n\n```\neksctl utils describe-addon-versions --kubernetes-version 1.31 | grep aws-ebs-csi-driver\n\nexport AWS_ACCOUNT_ID=\"UPDATE_ME\"\n\neksctl create addon \\\n  --cluster \"${CLUSTER_NAME}\" \\\n  --name aws-ebs-csi-driver \\\n  --version latest \\\n  --service-account-role-arn \"arn:aws:iam::${AWS_ACCOUNT_ID}:role/AmazonEKS_EBS_CSI_DriverRole_${CLUSTER_NAME}\" \\\n  --force\n```\n\nInstall [kubectl](https://kubernetes.io/docs/reference/kubectl/), a command line tool for communicating with a Kubernetes cluster's control plane, using the Kubernetes API.\n\nLet’s get the [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) of the created cluster.\n\n```\naws eks update-kubeconfig --name \"${CLUSTER_NAME}\"\n```\n\n## Configure Sysbox\n\n[Sysbox](https://github.com/nestybox/sysbox) is a container runtime that improves container isolation and enables containers to run the same workloads as virtual machines.\n\n[Install](https://github.com/nestybox/sysbox#installation) Sysbox on the Kubernetes cluster using the `sysbox-deploy-k8s daemonset`.\n\n```\ncurl https://raw.githubusercontent.com/nestybox/sysbox/refs/tags/v0.6.6/sysbox-k8s-manifests/sysbox-install.yaml -o sysbox-install.yaml\n```\n\nBecause of how Sysbox releases itself, it first created a git tag, which runs a pipeline to build assets after which the YAML files for the `sysbox-deploy-k8s daemonset` are updated. Thus, we need to update the DaemonSet's `spec.template.soec.containers[0].image` to [registry.nestybox.com/nestybox/sysbox-deploy-k8s:v0.6.6-0](https://github.com/nestybox/sysbox/blob/46ba726e8e894aa22e20465a32d22dfa2863ec12/sysbox-k8s-manifests/sysbox-install.yaml#L66) .\n\n```\nnew_image_value=\"registry.nestybox.com/nestybox/sysbox-deploy-k8s:v0.6.6-0\"\ntemp_file=$(mktemp)\nsed -E \"s|^([[:space:]]*image:)[[:space:]]*.*|\\1 $new_image_value|\" \"sysbox-install.yaml\" > \"$temp_file\"\nmv \"$temp_file\" \"sysbox-install.yaml\"\n```\n\nApply the YAML file to Kubernetes and ensure all the pods of the DaemonSet are running.\n\n```\nkubectl apply -f sysbox-install.yaml\nkubectl get pod -A\nkubectl -n kube-system get daemonset\n```\n\nVerify the installation by creating a pod which uses Sysbox container runtime.\n\n```\ncat \u003C\u003CEOF | kubectl apply -f -\napiVersion: v1\nkind: Pod\nmetadata:\n  name: sysbox-verification-pod\n  namespace: default\n  annotations:\n    io.kubernetes.cri-o.userns-mode: \"auto:size=65536\"\nspec:\n  runtimeClassName: sysbox-runc\n  containers:\n  - image: \"hello-world\"\n    imagePullPolicy: Always\n    name: main\n  restartPolicy: Always\nEOF\n\nkubectl -n default get pod sysbox-verification-pod\nkubectl exec -it sysbox-verification-pod -- echo \"Pod is running successfully on a Kubernetes cluster configured with Sysbox.\"\nkubectl -n default delete pod sysbox-verification-pod\n```\n\n## Configure GitLab agent for Kubernetes and GitLab Workspaces Proxy\n\nFollow our [documentation tutorial](https://docs.gitlab.com/ee/user/workspace/set_up_gitlab_agent_and_proxies.html) to set up GitLab agent and GitLab Workspaces Proxy.  \n\n## Configure sudo access for a workspace with Sysbox\n\nFollow our [documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#with-sysbox) to configure sudo access for a workspace with Sysbox.\n\n## Configure Ingress Controller\n\nSetup [Ingress NGINX Controller for Kubernetes](https://github.com/kubernetes/ingress-nginx)\n\n```\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx --force-update\nhelm repo update\n\nhelm upgrade --install \\\n  ingress-nginx ingress-nginx/ingress-nginx \\\n  --namespace ingress-nginx \\\n  --create-namespace \\\n  --version 4.11.1 \\\n  --timeout=600s --wait --wait-for-jobs\n\nkubectl -n ingress-nginx get pod\n```\n\n## Build containers inside a workspace\n\nWe’ll use [example-go-http-app](https://gitlab.com/gitlab-org/workspaces/examples/example-go-http-app) as the project to create a workspace from. Open the workspace, start a terminal, and install [Docker](https://docs.docker.com/engine/install/).\n\n```\n# Add Docker's official GPG key:\nsudo apt-get update\nsudo apt-get install ca-certificates curl\nsudo install -m 0755 -d /etc/apt/keyrings\nsudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc\nsudo chmod a+r /etc/apt/keyrings/docker.asc\n\n# Add the repository to Apt sources:\necho \\\n  \"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \\\n  $(. /etc/os-release && echo \"${UBUNTU_CODENAME:-$VERSION_CODENAME}\") stable\" | \\\n  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null\nsudo apt-get update\nsudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin\n\n# Start the Docker Daemon\nsudo dockerd\n```\n\nBuild the container image.\n\n```\nsudo docker build -t workspaces-golang-server .\n```\n\n## Run containers inside a workspace\n\nLet’s run the container built above and expose port 3000 from the container onto the host (workspace).\n\n```\nsudo docker run -p 3000:3000 workspaces-golang-server\n```\n\nThe port `3000` is exposed in the [.devfile.yaml](https://gitlab.com/gitlab-org/workspaces/examples/example-go-http-app/-/blob/dd3dbb38cdce1143f7ed023980f34630cea991a5/.devfile.yaml#L15) used to create the workspace. Access the server running inside the container from the browser. Here is a video clip.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/JQErF0U6oFk?si=6oiK48q5ghZq312g\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Get started today\n\nFrom GitLab 17.4, you can build and run containers securely in GitLab Workspaces. See our [documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#build-and-run-containers-in-a-workspace) for more information. Replace your local development environments to GitLab Workspaces for a secure, ephemeral, reproducible development environment. \n\n## Read more\n\n- [Enable secure sudo access for GitLab Remote Development workspaces](https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces/)\n- [Quickstart guide for GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)\n- [Create a workspace quickly with the GitLab default devfile](https://about.gitlab.com/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile/)\n- [Contributor how-to: Remote Development workspaces and GitLab Developer Kit](https://about.gitlab.com/blog/gitlab-gdk-remote-development/)\n",[746,478,9,701],{"slug":1292,"featured":90,"template":683},"build-and-run-containers-in-remote-development-workspaces","content:en-us:blog:build-and-run-containers-in-remote-development-workspaces.yml","Build And Run Containers In Remote Development Workspaces","en-us/blog/build-and-run-containers-in-remote-development-workspaces.yml","en-us/blog/build-and-run-containers-in-remote-development-workspaces",{"_path":1298,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1299,"content":1305,"config":1313,"_id":1315,"_type":13,"title":1316,"_source":15,"_file":1317,"_stem":1318,"_extension":18},"/en-us/blog/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated",{"title":1300,"description":1301,"ogTitle":1300,"ogDescription":1301,"noIndex":6,"ogImage":1302,"ogUrl":1303,"ogSiteName":670,"ogType":671,"canonicalUrls":1303,"schema":1304},"Building GitLab with GitLab: How GitLab.com inspired Dedicated","Learn how the multi-tenancy SaaS solution, GitLab.com, influenced the design of the single-tenancy SaaS, GitLab Dedicated.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659740/Blog/Hero%20Images/building-gitlab-with-gitlab-no-type.png","https://about.gitlab.com/blog/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Building GitLab with GitLab: How GitLab.com inspired Dedicated\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Andrew Newdigate\"},{\"@type\":\"Person\",\"name\":\"Craig Miskell\"},{\"@type\":\"Person\",\"name\":\"John Coghlan\"}],\n        \"datePublished\": \"2023-08-03\",\n      }",{"title":1300,"description":1301,"authors":1306,"heroImage":1302,"date":1310,"body":1311,"category":849,"tags":1312},[1307,1308,1309],"Andrew Newdigate","Craig Miskell","John Coghlan","2023-08-03","\nEarlier this year, we announced [the general availability of GitLab Dedicated](https://about.gitlab.com/blog/gitlab-dedicated-available/), our single-tenancy software-as-a-service (SaaS) offering. Dedicated, which addresses the needs of customers with stringent compliance requirements while maintaining speed, efficiency, and security, was developed from the lessons we learned building and using GitLab.com, our multi-tenancy model. Although there is overlap in how we manage both platforms, such as the same service-level monitoring stack, there were significant considerations that sparked the need for new design decisions, including how we approach automation, databases, monitoring, and availability. In this blog, we share some of those decision points and their outcomes.\n\n## GitLab platform options\nBefore we dive into the evolution of GitLab Dedicated, let’s level-set on GitLab’s [portfolio of platform models](https://docs.gitlab.com/ee/subscriptions/choosing_subscription.html#choose-a-subscription):\n- GitLab.com, a.k.a. multi-tenant GitLab SaaS on our pricing page and in our documentation\n- GitLab Dedicated, single-tenant SaaS that satisfies compliance requirements such as data residency, isolation, and private networking\n- GitLab self-managed, in which customers install, administer, and maintain their own GitLab instance\n\nEach method meets the different needs of our wide range of customers and requires a unique approach for how we create, package, and deploy the application.\n\nWhile both GitLab.com and Dedicated are SaaS-based, there are key differences between the two. The multi-tenant GitLab.com is the largest hosted instance of GitLab and services thousands of customers and millions of users. Because the platform's reliability is critical to so many customers and because of the iterative nature of how GitLab.com was built, decisions have been made along the way that are unique to the scale of this specific instance.\n\nIn contrast, GitLab Dedicated is a single-tenant SaaS application that is hosted by GitLab in the customer's region of choice (GitLab.com is hosted in the U.S.). While still providing a GitLab-managed SaaS solution for our customers, Dedicated instances are fully isolated from one another, running on a platform that automates the configuration and provisioning of the instances, along with automating as many of the day-two operations as possible, such as maintenance, monitoring, and optimization.\n\nHere are some examples of how Dedicated has used the blueprint of GitLab.com.\n\n## Improved automated deployments\nGitLab.com is a permanent installation with a great deal of history, having evolved significantly since it was first developed. Originally, it was deployed on a single instance in Amazon AWS, before migrating to Microsoft Azure, where it continued to scale out. From Azure, it migrated to its current cloud, Google Cloud Platform. Since then, many customer workloads have [migrated into Kubernetes](https://about.gitlab.com/blog/year-of-kubernetes/) and are supported by the Google Kubernetes Engine ([GKE](https://cloud.google.com/kubernetes-engine)).\n\nWith GitLab Dedicated, we're building smaller instances that rely on automation, repeatability, and deterministic environments. All customer tenant GitLab instance operations must be 100% automated, including provisioning, upgrades, scaling, configuration changes, and any other routine operations. The stack relies heavily on the GitLab Environment Toolkit ([GET](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_advanced_hybrid.md)) Cloud Native Hybrid, which uses the GitLab Helm charts for stateless workloads (e.g., Rails) and Omnibus for deployments to VMs (e.g., Gitaly). GET helps with the deployments targeting [reference architectures](https://docs.gitlab.com/ee/administration/reference_architectures/) and coordinating the provisioning of cloud resources, including compute instances, Kubernetes clusters, managed Postgres databases and more.\n\nAs much as GET automates, it has a certain amount of required setup, which is acceptable to perform manually for one-off or otherwise long-lived deployments, but in order to scale Dedicated we also had to automate that process, which we did with Terraform. Because this was a greenfield approach, we were able to be particularly careful with privileges. Our current cloud deployment target is AWS, so we developed a detailed identity and access management ([IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)) policy to grant each stage of deployment only the strictly necessary access. We also use IAM role assumption from trusted workloads in a central AWS account to eliminate the need for explicit credentials.  \n\nDeployments follow this process in order:\n- An account creation job running from a trusted location creates a fresh AWS account in an [AWS Organization](https://docs.aws.amazon.com/organizations/index.html), placing it in the correct Organizational Unit to automatically have a [CloudFormation StackSet](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) applied, with ongoing updates handled by AWS when needed. This allows us to operate the entire lifecycle of the tenant account using IAM Role Assumption rather than generating and storing static IAM credentials.\n- Prepare stage sets up a fresh AWS account ready to receive a deployment; the privileges are quite high powered, but still limited to the necessary areas, including creating the next role.  \n- Onboard stage creates some high-level resources and otherwise does the setup that GET requires to be able to run, including creating the roles for the next stages with their own limited privileges.  \n- Provision stage is mostly about running GET Terraform and creating the compute and storage resources onto which GitLab will be deployed, with a few additions for our specific needs.  \n- Configure stage runs to deploy the GitLab application onto the resources created earlier. At its core, this is the GET Ansible stage, but it includes our own Terraform wrapper as well to handle our specific needs.\n\nOnce these stages complete, a fully deployed GitLab instance is ready to go.  \n\nConfiguration changes and GitLab upgrades execute the same set of stages, ensuring everything is still configured correctly and applying any pending changes. In the early days of GitLab Dedicated this was done in GitLab CI/CD pipelines operating on GitLab.com, with the tenant descriptions as JSON files in a repository, which was an effective and simple place to start.  \n\nHowever, this multi-stage deployment is now managed by [Switchboard](https://about.gitlab.com/direction/saas-platforms/switchboard/), a portal we built specifically for GitLab Dedicated. Switchboard is a bespoke Rails application, which will be the single source of truth for configuration, accessible by customers to manage customer-facing settings, as well as GitLab Dedicated staff for general management. Switchboard will be responsible for automating regular upgrades, including gradual rollouts across the fleet of Dedicated instances.\n\n## Databases geared towards the needs of single tenancy\nGitLab.com uses self-managed Postgres and Redis. For GitLab Dedicated, we wanted to leverage AWS’s managed services as much as possible. Examples include RDS, Elasticache, and OpenSearch, the AWS Elasticsearch managed service. Some of these services may not always be able to support GitLab.com-scale platforms, but they handle the traffic of a single-tenant instance well and provide reliable failovers and ongoing maintenance with no effort on our part.\n\n## Monitoring aligned with strict compliance needs\nThe observability stack for GitLab Dedicated relies on the expertise we gained from building GitLab.com. The monitoring, logging, and availability infrastructure is all maintained within the customer's AWS account, nothing is shared. We receive low-context alerts from these private systems. They serve as a mechanism to direct us to the customer account so we can review what is going on and triage the underlying issues if needed. This is helpful with regulators and compliance as nothing can leak because it doesn't leave the system.\n\nWhile Dedicated and GitLab.com share much of the same monitoring stack, Dedicated instances have tended to reveal different issues within our application. This is due to GitLab.com being a multi-tenant instance, while GitLab Dedicated instances are single-tenant. \n\nThink of the adage, \"[Your 9s are not my 9s](https://rachelbythebay.com/w/2019/07/15/giant/).\" In a platform at the scale of GitLab.com, a subset of users who encounter an issue in part of the application may be a very small percentage of the overall user base. The small impact relative to the scale of the platform may not create an alert. In a single-tenant instance, however, the same bugs or scaling issues can quickly impact a higher percentage of the overall users of the instance, escalating the issue's importance. Applying our service-level monitoring to single-tenant GitLab instances has benefited GitLab users who had encountered bugs that were overlooked in the volume of GitLab.com usage. When we identify issues in a Dedicated instance, we resolve them within the product.\n\n## High availability for all components\nConsidering the hybrid environment and the level of service that we want to offer to our customers, we have made some minor changes from the [standard reference architecture](https://docs.gitlab.com/ee/administration/reference_architectures/).\n\nOne such change is introducing high availability for all components. For the lower size (i.e., up to 2,000 users), our architecture ships by default with all the components in full redundant mode. Components like RDS and Elasticache will have a replica in a different Availability Zone. This is referred to as the primary region and we have to define how it will look in the [Geo replicas](https://docs.gitlab.com/ee/administration/geo/setup/database.html).\n\n## Only on Dedicated\nIn addition to the other changes we made, we also built some features that are only used for GitLab Dedicated:\n- Bring your own key - customers can provide and manage the encryption keys used to encrypt AWS resources such as storage, allowing a customer to revoke access should that ever become necessary. This is not something that can be offered in a multi-tenant system like GitLab.com.\n- Switchboard - as mentioned above, Switchboard was purpose-built for Dedicated. It is a multi-tenant Ruby on Rails application, accessible by GitLab Dedicated customer administrators and GitLab Dedicated team members. Using this interface, customers can change the available application runtime settings, access provided graphs, add additional products, and more. The main Switchboard instance serves as a single source of truth for global configuration and status across multiple cloud providers and regions.\n- PrivateLink networking - allows traffic between tenant AWS accounts and customer accounts without exposing data to the internet. \n- Other network features - including traffic filtering and private hosted zones.\n\nDedicated has been an exciting project and a great learning experience for our team. We were able to apply the knowledge accumulated in building GitLab.com to deliver an important new product for our customers in a very efficient way. You can learn more about GitLab Dedicated by visiting our [Dedicated page](https://about.gitlab.com/dedicated/) or contacting a GitLab sales representative.\n\n_Check out the [first installment in our \"Building GitLab with GitLab\" series](https://about.gitlab.com/blog/building-gitlab-with-gitlab-api-fuzzing-workflow/), which takes you behind the scenes of the development of our web API fuzz testing._\n",[872,478,703,9],{"slug":1314,"featured":6,"template":683},"building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated","content:en-us:blog:building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated.yml","Building Gitlab With Gitlabcom How Gitlab Inspired Dedicated","en-us/blog/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated.yml","en-us/blog/building-gitlab-with-gitlabcom-how-gitlab-inspired-dedicated",{"_path":1320,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1321,"content":1327,"config":1334,"_id":1336,"_type":13,"title":1337,"_source":15,"_file":1338,"_stem":1339,"_extension":18},"/en-us/blog/building-new-fedora-project-website-with-gitlab",{"title":1322,"description":1323,"ogTitle":1322,"ogDescription":1323,"noIndex":6,"ogImage":1324,"ogUrl":1325,"ogSiteName":670,"ogType":671,"canonicalUrls":1325,"schema":1326},"How GitLab helped Fedora build websites and community","Learn how the Fedora Project recently modernized its web development practices and streamlined team workflows with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682851/Blog/Hero%20Images/communityhands.jpg","https://about.gitlab.com/blog/building-new-fedora-project-website-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How building modern websites with GitLab led to a healthier Fedora Project community\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Akashdeep Dhar\"}],\n        \"datePublished\": \"2023-07-11\",\n      }",{"title":1328,"description":1323,"authors":1329,"heroImage":1324,"date":1331,"body":1332,"category":827,"tags":1333},"How building modern websites with GitLab led to a healthier Fedora Project community",[1330],"Akashdeep Dhar","2023-07-11","\nWhen [Fedora Linux 38](https://fedoraproject.org/) debuted in April 2023, the Fedora Project community and I had an extra reason to celebrate. The first item in the community's [official release annoucement](https://fedoramagazine.org/announcing-fedora-38/) was one we were extremely proud of: our brand-new Fedora Project websites.\n\nThe launch of the new websites was the culmination of many months of good, old-fashioned community contribution from the \n[Fedora Websites and Apps team](https://gitlab.com/fedora/websites-apps) and other teams such as [Fedora Infrastructure](https://pagure.io/fedora-infrastructure), [Fedora Marketing](https://docs.fedoraproject.org/en-US/marketing/), \n[Fedora Design](https://fedoraproject.org/wiki/Design), and many more teams. This effort didn't just involve the development of the refreshed websites; it also involved rearchitecturing the team's technical stack and aligning our workflows with modern industry's best practices. \n\nIn this article, I will explain how migrating our workflow to GitLab helped us to not only build refreshed websites for the Fedora Project but also reimagine and streamline our community's process for building, maintaining, testing, and deploying them. The result: new workflows that redefine our team's processes to incentivize contribution and avoid the looming threat of potential contributor burnout – not to mention the elegant websites themselves.\n\n## Why we embarked on this effort\nAbout two years ago, four Fedora Project community members ([Ramya Parimi](https://gitlab.com/ramyaparimi), [Nasir Hussain](https://gitlab.com/nasirhm), [Justin W. Flory](https://gitlab.com/jwflory), and [myself](https://gitlab.com/t0xic0der)) were working on a project together when we discovered that only a tiny group of volunteer contributors maintained our websites. We immediately faced a dilemma that's common in many free and open source projects: Should that tiny group disband or disappear, we were at risk of not being able to maintain our websites and applications. Also, we didn't want the volunteer contributors to get burnt out under the constant stress of maintaining these projects. We needed more hands on deck, and we needed them quickly.\n\nSo our former Fedora Community Architect (the position was then called Fedora Community Action and Impact Coordinator, or FCAIC), [Marie Nordin](https://gitlab.com/riecatnor), helped us kickstart a community initiative that inspired us to not only refresh Fedora Project websites and applications but also establish more reliable processes and workflows around them, too.\n\nThat second part is incredibly important. We focused on enhancing the visual appeal and user experience of our websites — diligently adhering to the best accessibility practices, implementing a native dark mode that aligns with the user's system theme, and effectively advocating for our offerings to the best of our abilities (among other things). But we needed to solve the problem of maintainability, too. That would involve addressing some underlying issues that, although they looked deceptively simple on the surface, profoundly influenced the long-term sustainability of the team's work. Our goal was to ensure that even when *we* were not around, contributors who would do this work *after* us would be able to set things up and maintain them in the long run without issue.\n\nTo recruit more contributors, we needed to align the way our team worked with current industry practices. Adopting GitLab helped us do that.\n\n## How GitLab helped simplify, unify, and standardize\nHistorically, the website development team employed a range of tools as part of our workflows. Some we developed internally; others we acquired externally and integrated into our infrastructure. But these tools weren't always compatible with one another, meaning extra effort on our part (establishing a standardized business language for effective communication of work plans, progress obstacles, task updates, etc.). That not only impacted our operational efficiency but also drained our resources (for example, we were dedicating meetings solely to the purpose of ensuring everyone was aligned and understood the processes).\n\nAdopting GitLab helped alleviate that burden, because it's [a single, comprehensive platform](https://about.gitlab.com/stages-devops-lifecycle/). Our team got acclimated to capabilities like creating and tagging issues and epics to organize work, building Kanban boards and Gantt charts to map work-in-progress and construct functional timelines, and incorporating merge requests as progress indicators in a comprehensive project overview. We then understood how the cohesive nature of GitLab's approach to most aspects (if not all) of the software development lifecycle significantly enhanced our distributed team's overall efficiency.\n\nBut we use GitLab for more than just planning and implementation. We completely rewrote the technology stack using industry-standard static site-generating libraries like [NuxtJS](https://v2.nuxt.com/). GitLab's ability to create and deploy static sites helps us automate our deployment workflow. Then we coupled the revamped frontend with the [NetlifyCMS](https://v1.netlifycms.org/) content management system that relies on GitLab as its core. We also simplified the translation pipeline for localizing and internationalizing our website content. By employing continuous integration tools, we were able to generate dynamic test deployments to evaluate our websites before deploying them to the production environment. That success also prompted us to utilize GitLab for storing meeting logs and documentation, streamlining our project management processes even further.\n\nHere's an example.\n\nIn the past, when our websites were based on [Frozen Flask](https://pypi.org/project/Frozen-Flask/), we used various shell scripts to maintain it. These scripts would create an [OCI](https://opencontainers.org/) container using [Podman](https://podman.io/), build static files, perform translations, and serve the website. You can still find the [deprecated](https://pagure.io/fedora-websites) [repositories](https://pagure.io/fedora-web/websites/) where this was the standard development, testing, and deployment method. Although this process was automated using Ansible in our community infrastructure, it seemed complex for less experienced contributors.\n\nAfter transitioning to GitLab, we could deploy to our fast-changing staging environments directly from [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) while the slow-changing production environment remained on the community infrastructure. We also utilized GitLab's CI/CD features to test merge requests with ephemeral deployment environments. Since the automation is integrated into the project itself, any push to the primary branch or merge request triggers a deployment workflow. This consolidation of automation into a single unit has further streamlined our processes.\n\n## Better workflow, healthier community\nChanges like these were critical to the Fedora Project's overall [mission to foster an inviting environment](https://docs.fedoraproject.org/en-US/project/#_our_community) for contributors. Our new GitLab-centric workflow improved the experience for team members who wanted to contribute to documenting and translating content without having to navigate the technical intricacies of using Git. By lowering the entry barrier, we aimed to attract prospective newcomers and promote a more inclusive team dynamic.\n\nAs a result, we saw content contributions from other teams. And then, gradually, more folks joined us in our revamp efforts, helping to [make this community initiative a success](https://communityblog.fedoraproject.org/tag/websites-and-apps-initiative-wrapup/).\n\n*The [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).*\n\nPhoto by [Hannah Busing](https://unsplash.com/@hannahbusing?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash.\n{: .note}\n\n\n",[1187,266,9],{"slug":1335,"featured":6,"template":683},"building-new-fedora-project-website-with-gitlab","content:en-us:blog:building-new-fedora-project-website-with-gitlab.yml","Building New Fedora Project Website With Gitlab","en-us/blog/building-new-fedora-project-website-with-gitlab.yml","en-us/blog/building-new-fedora-project-website-with-gitlab",{"_path":1341,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1342,"content":1348,"config":1356,"_id":1358,"_type":13,"title":1359,"_source":15,"_file":1360,"_stem":1361,"_extension":18},"/en-us/blog/ceo-shadow-impressions-takeaways",{"title":1343,"description":1344,"ogTitle":1343,"ogDescription":1344,"noIndex":6,"ogImage":1345,"ogUrl":1346,"ogSiteName":670,"ogType":671,"canonicalUrls":1346,"schema":1347},"CEO Shadow program impressions and takeaways","What is the GitLab CEO shadow program? Why should a GitLab team member apply to participate? How did I see the GitLab values in action?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681405/Blog/Hero%20Images/ceo-shadow-unfiltered-whaber.jpg","https://about.gitlab.com/blog/ceo-shadow-impressions-takeaways","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CEO Shadow program impressions and takeaways\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Wayne Haber\"}],\n        \"datePublished\": \"2020-07-08\",\n      }",{"title":1343,"description":1344,"authors":1349,"heroImage":1345,"date":1351,"body":1352,"category":1353,"tags":1354},[1350],"Wayne Haber","2020-07-08","\n\n[I participated](https://gitlab.com/whaber) in the CEO Shadow program in July of 2020.  It was quite an exhilarating experience.\n\nYou will find below:\n\n* What I did during the program\n* Why someone should apply to be in the program\n* What I learned about Gitlab values in action and effective communication\n\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/JVaPRtY6wMQ\" frameborder=\"0\" allowfullscreen=\"false\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## What did I do during the GitLab CEO shadow program?\n\n* There were 10+ meetings to attend per day over two weeks.  Meetings included one on one discussions with [Sid's direct reports AKA the E-Group](/company/team/structure/#e-group), [group conversations](/handbook/group-conversations/), [Key Reviews](https://about.gitlab.com/handbook/key-review/), customers, investors, and media interviews.\n* I authored [16 merge requests](https://bit.ly/2AgXilS) for the handbook and collaborated with my co-shadows on another ~10.  I also created two tasks to track items that were not handbook updates.  Approximately half were requests from [Sid](/handbook/ceo/) for the CEO shadows during meetings, and half were ideas that the co-shadows had to improve the handbook based on what we were learning and experiencing.  Some merge requests were [quite small in effort (5 minutes)](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/54276), and [some took a significant amount of time (8 hours to do the analysis)](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/54017).\n* Sid asked for feedback a couple of times each week for feedback on how he did, and to ask for ideas from the CEO shadows on the topics that were covered.\n* During an investor meeting, an investor asked the attendees a question in one of my areas of expertise: security.  I smiled widely on video, which Sid picked up on.  He asked me to cover the subject (and follow-on questions) from the investor.  It was an excellent opportunity to contribute.\n* I joined meetings a minute or two early when possible. Doing so allowed me to network with other meeting attendees who also joined early briefly. Often this was with GitLab team members in which it is uncommon for me to have this opportunity (other than in [coffee chats](https://about.gitlab.com/company/culture/all-remote/informal-communication/#coffee-chats)).\n\n## Why should a GitLab team member apply to participate?\n\n* You can observe and learn from seeing the [GitLab values](https://handbook.gitlab.com/handbook/values/) in action by Sid and the E-Group.\n* It is a great way to understand \"the why\" on how decisions are made.\n* The handbook is quite extensive.  You can get a sense as to which portions or more or less important based on how often each page is referenced.\n* You can better understand the [GTM (go to market)](/handbook/sales/) strategy and how it guides decisions that impact you and your team.\n\n## What are the key things I learned?\n\nIn one of the meetings, to paraphrase what someone learning about GitLab's culture said:\n`You can't train people on a culture.  You have to live it to learn it.`\n\nOur values guide our actions.  Below are each of our values and what actions I observed that reinforced them.\n\n### Results\n\n* Our high merge request rate is a competitive differentiator.  Our competitors can't release new features nearly as fast as we can.\n* Inter-team meetings should be about high impact cross-functional items, not \"status on what is being worked on.\"\n\n### Efficiency\n\n* Read presentations and related merge requests/documents/issues in advance of a meeting.  Document questions and feedback in the associated notes document *before* the meeting.\n* If necessary, at the beginning of a meeting, go over the highlights of the presentation at the beginning of the meeting.  Better yet, record a short video of the highlights and publish before the meeting so that the meeting time can be even more effective.\n* When a meeting is planned with those outside of GitLab, document the \"Who, What, Why, When, and Where\" in advance so everyone can be well prepared and informed in advance of the meeting.\n* When you view a multi-page Google document during a meeting and want to see where the speaker is in the document, double-click on their face (or initials) in the top right part of the page.  Your cursor will jump to wherever their cursor is in the document.\n* Don't be overly regimented about having weekly 1-1 meetings with your manager and direct reports.  If you need an additional one because there are important things to discuss that shouldn't wait another week, schedule it!\n* In some meetings, there were significantly more items to cover than time available.  The team decided to cover the topics in \"descending most controversial\" order.\n\n### Diversity, Inclusion, & Belonging\n\n* An interview with a candidate was nearing the end of the scheduled meeting time, and Sid asked the candidate if they had time to continue. The candidate said they could, but would prefer not to due to having kids at home.  Sid decided that the candidate was potentially deferring too much due to being interviewed, so they decided to schedule a follow-up meeting for the next week.  Deciding to meet the week after was a great example of \"friends and family first, work second.\n* Use [Zoom in gallery mode](https://support.zoom.us/hc/en-us/articles/201362323-How-Do-I-Change-The-Video-Layout-), which allows you to see all other participants.  Using gallery mode enables you to interpret the expressions and other non-verbal communication (excited, bored, concerned, etc.) of meeting participants.\n\n### Collaboration\n\n* Enthusiasm is contagious.  For example, there were many instances where people were very excited about topics, including the merge request rate, [new features recently released](/releases/2020/06/22/gitlab-13-1-released/), and plans for future releases.\n* The handbook is a guidebook, not a rulebook.  Take our values into account when you apply the handbook ([and improve it!](/company/mission/#contribute-to-gitlab-company)).\n\n### Effective communication\n\nSeveral topics were discussed asynchronously, especially in merge request threads and Google documents. \nObserving Sid in action employing [effective communication](/handbook/communication/#effective-communication-competency) reminded me of these principles:\n\n* Prefer a merge request over an issue.  Prefer an issue over a Google document or a Slack conversation.\n* It is a judgment call as to when asynchronous communication has become less effective than a synchronous Zoom call.\n* Keep in mind that GitLab team members work on many different things.  They may have little context on the historical background and your perspective.  Provide background and about \"the why\" to reduce miscommunication.\n* Thank people for taking the time to give feedback (especially in merge requests and issue comments).\n\n### Responding to feedback\n\n* Be sure to put yourself in the other person's shoes to understand their perspective.  Focus not only on what you don't agree on but also about what you do agree on.\n* Thank people for giving feedback (especially in merge request and issue comments).\n* Be genuine in your response.  Don't overpromise how you will address their feedback with the intention of underdelivering.\n\nWant to see some great examples?  Look at Sid's responses in [GitLab merge request comments](https://gitlab.com/users/sytses/activity), [Hacker News threads](https://news.ycombinator.com/threads?id=sytse), and [Twitter replies](https://twitter.com/sytses/with_replies).\n\nCover image by [Chris Montgomery](https://unsplash.com/photos/smgTvepind4) on [Unsplash](https://www.unsplash.com)\n{: .note}\n\n{::options parse_block_html=\"true\" /}\n\n\n","unfiltered",[1355,9],"research",{"slug":1357,"featured":6,"template":683},"ceo-shadow-impressions-takeaways","content:en-us:blog:ceo-shadow-impressions-takeaways.yml","Ceo Shadow Impressions Takeaways","en-us/blog/ceo-shadow-impressions-takeaways.yml","en-us/blog/ceo-shadow-impressions-takeaways",{"_path":1363,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1364,"content":1370,"config":1376,"_id":1378,"_type":13,"title":1379,"_source":15,"_file":1380,"_stem":1381,"_extension":18},"/en-us/blog/changes-coming-to-url-structure-follow-deprecations-redirects",{"title":1365,"description":1366,"ogTitle":1365,"ogDescription":1366,"noIndex":6,"ogImage":1367,"ogUrl":1368,"ogSiteName":670,"ogType":671,"canonicalUrls":1368,"schema":1369},"Bookmark these changes: URL structure updates coming in GitLab 17.0","An overview of project and user settings URL changes, including deprecations and redirects, that will happen in 17.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/changes-coming-to-url-structure-follow-deprecations-redirects","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bookmark these changes: URL structure updates coming in GitLab 17.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christen Dybenko\"}],\n        \"datePublished\": \"2023-08-30\",\n      }",{"title":1365,"description":1366,"authors":1371,"heroImage":1367,"date":1373,"body":1374,"category":678,"tags":1375},[1372],"Christen Dybenko","2023-08-30","\nOver the next few releases GitLab will be making some changes to our URL structure. They mainly affect settings pages, but we're cleaning up a few other URLs as well. The URL structure represents the site map, and it should be both predictable and consistent.\nOver the years, page titles have begun to deviate from their original designation and these changes aim to rectify that.\nYou can see the full effect of these changes in the tables below.\n\nWe will be adding these as 301 redirects over the next few months, with a plan to remove the old routes entirely in our 17.0 release in May 2024. If you have any of these pages bookmarked, or rely on these URLs, they will continue to work up until the removal in 17.0.\n\nPlease share your feedback on this change in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420675).\n\n## Page URL updates\nHere are the page URL updates for projects and user settings.\n\n### Project\n\n| Sidebar | Current Path | New Path |\n|---------|------|-------------|\n| Analyze / **Contributor statistics** | /-/\u003Cspan style=\"background: #fdd4cd;\">graphs\u003C/span>/{default branch name} | /-/\u003Cspan style=\"background: #c3e6cd;\">contributor_statistics\u003C/span>/{default branch name} |\n| Code / **Repository graph** | /-/\u003Cspan style=\"background: #fdd4cd;\">network\u003C/span>/{default branch name} | /-/\u003Cspan style=\"background: #c3e6cd;\">repository_graph\u003C/span>/{default branch name} |\n| Code / **Locked files** | /\u003Cspan style=\"background: #fdd4cd;\">path_locks\u003C/span> | \u003Cspan style=\"background: #c3e6cd;\">/-/locked_files\u003C/span> |\n| Monitor / **Alerts** | /-/\u003Cspan style=\"background: #fdd4cd;\">alert_management\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">alerts\u003C/span> | \n| Settings / **Webhooks** | /-/\u003Cspan style=\"background: #fdd4cd;\">hooks\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">settings/webhooks\u003C/span> | \n| Settings / **Monitor** | /-/settings/\u003Cspan style=\"background: #fdd4cd;\">operations\u003C/span> | /-/settings/\u003Cspan style=\"background: #c3e6cd;\">monitor\u003C/span> | \n\n### User settings\n\n| Sidebar | Current Path | New Path |\n|---------|------|---------|\n| User settings \u003Cbr>↳ Profile | /-/profile | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/profile | \n| User settings \u003Cbr>↳ Account | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/account | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/account |\n| User settings \u003Cbr>↳ Applications | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/applications | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/applications | \n| User settings \u003Cbr>↳ Chat | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/chat\u003Cspan style=\"background: #fdd4cd;\">\\_names\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/chat | \n| User settings \u003Cbr>↳ Personal access tokens | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/personal_access_tokens | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/personal_access_tokens | \n| User settings \u003Cbr>↳ Emails | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/emails | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/emails | \n| User settings \u003Cbr>↳ Password | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/password/edit | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/password/edit | \n| User settings \u003Cbr>↳ Notifications | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/notifications | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/notifications | \n| User settings \u003Cbr>↳ SSH keys | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/keys | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/\u003Cspan style=\"background: #c3e6cd;\">ssh\u003C/span>\\_keys | \n| User settings \u003Cbr>↳ GPG keys | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/gpg_keys | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/gpg_keys | \n| User settings \u003Cbr>↳ Preferences | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/preferences | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/preferences | \n| User settings \u003Cbr>↳ Active sessions | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/active_sessions | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/active_sessions | \n| User settings \u003Cbr>↳ Authentication log | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/\u003Cspan style=\"background: #fdd4cd;\">audit_log\u003C/span> | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/\u003Cspan style=\"background: #c3e6cd;\">authentication_log\u003C/span> | \n| User settings \u003Cbr>↳ Usage quotas | /-/\u003Cspan style=\"background: #fdd4cd;\">profile\u003C/span>/usage_quotas | /-/\u003Cspan style=\"background: #c3e6cd;\">user_settings\u003C/span>/usage_quotas |\n",[678,9,893,478],{"slug":1377,"featured":6,"template":683},"changes-coming-to-url-structure-follow-deprecations-redirects","content:en-us:blog:changes-coming-to-url-structure-follow-deprecations-redirects.yml","Changes Coming To Url Structure Follow Deprecations Redirects","en-us/blog/changes-coming-to-url-structure-follow-deprecations-redirects.yml","en-us/blog/changes-coming-to-url-structure-follow-deprecations-redirects",{"_path":1383,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1384,"content":1390,"config":1398,"_id":1400,"_type":13,"title":1401,"_source":15,"_file":1402,"_stem":1403,"_extension":18},"/en-us/blog/changes-to-the-preclonescript",{"title":1385,"description":1386,"ogTitle":1385,"ogDescription":1386,"noIndex":6,"ogImage":1387,"ogUrl":1388,"ogSiteName":670,"ogType":671,"canonicalUrls":1388,"schema":1389},"Guide to pre_clone_script changes on GitLab SaaS Linux Runners","Learn about the change from CI_PRE_CLONE_SCRIPT to pre_get_sources_script on GitLab SaaS Linux Runners.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664087/Blog/Hero%20Images/tanukicover.jpg","https://about.gitlab.com/blog/changes-to-the-preclonescript","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide to pre_clone_script changes on GitLab SaaS Linux Runners\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Eastman\"}],\n        \"datePublished\": \"2023-03-27\",\n      }",{"title":1385,"description":1386,"authors":1391,"heroImage":1387,"date":1393,"body":1394,"category":678,"tags":1395},[1392],"Darren Eastman","2023-03-27","\n\nIn GitLab 16.0, on GitLab SaaS Runners on Linux, we are removing the `CI_PRE_CLONE_SCRIPT` variable support in CI/CD workflows. If you use the `CI_PRE_CLONE_SCRIPT` variable in your GitLab SaaS CI pipelines, you must change to the new method to ensure your workflows run as expected.\n\n## What is the pre_clone_script?\n\nThe [`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) configuration option is a powerful pre-build script feature that enables you to execute custom logic before a GitLab Runner clones the project repository and runs your CI jobs. For example, you could use this feature in your environment to automate the cleanup of files from the build directory that aren’t useful for subsequent builds. Other use cases include retrieving files needed for the build or running other commands before the git initialization of the build directory.\n\nTo use this feature on GitLab SaaS Runners on Linux, you must first define a project CI/CD variable, `CI_PRE_CLONE_SCRIPT`, and include that variable in the `.gitlab-ci.yml` pipeline file.\n\nWhile this Runner pre-build script hook configuration has proven helpful for our customers, we needed to devise a more straightforward solution, while introducing additional guard rails. Enter the new [`pre_get_sources_script`](https://docs.gitlab.com/ee/ci/yaml/index.html#hookspre_get_sources_script) keyword in the `.gilab-ci.yml` file syntax.\n\n## What is the pre_get_sources_script hook?\n\nThe `pre_get_sources_script` hook is a simple-to-use method that enables you to have your script executed by the GitLab Runner before the git clone, init, and CI build scripts. Using the new `pre_get_sources_script` script is as simple as entering the following syntax in your `.gitlab-ci.yml` pipeline file.\n\n``` yaml\ntest_job:\n   stage: test\n   hooks:\n      pre_get_sources_script:\n      - echo 'hello run commands here before fetching the project repository'\n   script:\n     - echo 'this is the start of my CI build job script\n\n```\n\nSince the hook now is visible as code in your pipeline, you have immediate visibility into the script the Runner will execute before running the build job.\n\n## How to prepare for `pre_get_sources_script`?\n\nTo prepare for the change to `pre_get_sources_script` in GitLab 16.0, follow these steps: \n\n1. Check your CI jobs on GitLab SaaS to confirm if the `CI_PRE_CLONE_SCRIPT` variable is used.\n1. If the `CI_PRE_CLONE_SCRIPT` is used, then replace the script definition with a `pre_get_sources_script` hook in your `.gitlab-ci.yml` file.\n1. If you have any issues during testing of your pipelines with `pre_get_sources_script`, connect with us by leaving a comment below.\n\n## What's next: Support for `post_get_source`\n\nOn self-managed GitLab Runners, the `pre_get_sources_script` hook is only one of many hooks you can use to run code in various CI/CD pipeline stages. Those hooks include `post_get_sources`, `pre_build`, and `post_build` hooks, configurable only on the Runner host. More details are available in the [`[[runners]]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) section in the advanced configuration documentation.\n\nIn the future, we plan to add support for `post_get_sources` in the YAML syntax of the `gitlab-ci.yml` pipeline.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n\n",[1396,1397,9],"CI","CD",{"slug":1399,"featured":6,"template":683},"changes-to-the-preclonescript","content:en-us:blog:changes-to-the-preclonescript.yml","Changes To The Preclonescript","en-us/blog/changes-to-the-preclonescript.yml","en-us/blog/changes-to-the-preclonescript",{"_path":1405,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1406,"content":1412,"config":1418,"_id":1420,"_type":13,"title":1421,"_source":15,"_file":1422,"_stem":1423,"_extension":18},"/en-us/blog/chat-about-your-merge-request-with-gitlab-duo",{"title":1407,"description":1408,"ogTitle":1407,"ogDescription":1408,"noIndex":6,"ogImage":1409,"ogUrl":1410,"ogSiteName":670,"ogType":671,"canonicalUrls":1410,"schema":1411},"Chat about your merge request with GitLab Duo","Learn how to use AI-powered Chat to quickly understand complex merge requests by asking about implementation choices, potential risks, and architectural decisions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675536/Blog/Hero%20Images/blog-image-template-1800x945__2_.png","https://about.gitlab.com/blog/chat-about-your-merge-request-with-gitlab-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Chat about your merge request with GitLab Duo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Torsten Linz\"}],\n        \"datePublished\": \"2024-11-22\",\n      }",{"title":1407,"description":1408,"authors":1413,"heroImage":1409,"date":1415,"body":1416,"category":806,"tags":1417},[1414],"Torsten Linz","2024-11-22","Managing a merge request (MR) is an integral part of collaborative development, involving navigating through code changes, discussions, and dependencies to ensure high-quality outcomes. Whether you’re reviewing someone else’s code or trying to make your own changes clearer, the new [GitLab Duo Chat](https://about.gitlab.com/gitlab-duo/) capability, available in GitLab Duo Enterprise, can help simplify your workflow. Now, you can have a conversation with GitLab Duo Chat about an MR, directly inside GitLab.\n\n## What GitLab Duo Chat brings to an MR workflow\n\nImagine jumping into a merge request titled \"Add logging to order processing.\" Your goal is to onboard yourself to the MR as quickly as possible and to review it. You can use GitLab Duo Chat to onboard yourself faster and understand critical questions to accelerate your review:\n\n* \"Do the logs cover all failure scenarios, or are there any gaps where an issue might not be traceable?\"  \n* “Are there any potential privacy concerns with the logged data?\"  \n* \"Why was logging added at these specific points in the order processing workflow, and how does it help with debugging or monitoring?\"\n\n![MR context example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675670/Blog/Content%20Images/MR_Context_example.png)\n\nThese are the kinds of questions that GitLab Duo Chat is ready to answer – questions that let you quickly understand the intentions behind the changes and uncover any potential risks before diving into the details. Instead of spending a lot of time trying to follow code paths or waiting on the author to reply to your questions, you can start getting answers right away, saving valuable time.\n\n## In-depth conversations about MRs\n\nThe magic of this new chat capability isn’t just in summarizing code – it’s in its ability to support in-depth conversations about the MR at hand. Let's assume the logging MR also includes notifications and refactoring. You can ask specific, insightful questions, such as:\n\n* “What are the potential network failure points introduced by refactoring the payment service into a microservice?”  \n* \"Were there any trade-offs made in terms of consistency or accuracy for better performance?\"  \n* \"How are failures in sending notifications handled? Are retries implemented?\"\n\nInstead of simply telling you what changes have been made, GitLab Duo Chat helps you understand *why* those changes were made, what risks are involved, and how to mitigate them. It lets you dig deep and explore the context behind every line of code, every architectural decision, and every change in behavior within the specific MR you are working on.\n\nAnd it doesn't end with that one answer. You can engage in a follow-up conversation to dig deeper or to explore. \n\n## An evolving conversation tool\n\nWe’re really excited about how GitLab Duo Chat is evolving to become a true conversational partner for MR authors and reviewers alike. GitLab Duo Chat is [aware of the MR description, discussions, the code diff, and metadata of a single MR](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html#the-context-chat-is-aware-of). It’s like having an assistant who is well-versed in your MR and ready to explain any part of it – or even rewrite parts, if that’s what you need.\n\nWith GitLab Duo Chat, onboarding yourself to a complex MR or understanding a change in-depth is faster and more intuitive than ever before.\n\n## We need your feedback\n\nWe’re eager to hear how GitLab Duo Chat works for you. All feedback helps us refine this feature and make it even more useful. Please share your experiences by commenting on our [issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues/464587). Please include the questions you asked, the response you got, and whether it helped you move forward. Together, we can make GitLab Duo Chat an indispensable tool for every merge request!\n\nFor a deeper dive into how to use GitLab Duo Chat, check out our [documentation](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples#ask-about-a-specific-merge-request) or watch our introductory video below. Start your first conversation today and let us know what you think!\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4muvSFuWWL4?si=7W4mHWw2iUOzoTUz\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->  \n\n> Sample this new capability with [a free 60-day trial of GitLab Ultimate and GitLab Duo Enterprise](https://gitlab.com/-/trials/new).\n\n## Learn more about GitLab Duo Chat\n\n- [GitLab Duo Chat: Get to know productivity-boosting AI enhancements](https://about.gitlab.com/blog/gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements/)\n- [GitLab Duo Chat, your at-the-ready AI assistant, is now generally available](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/)\n- [GitLab Duo Chat 101: Get more done on GitLab with our AI assistant](https://about.gitlab.com/blog/gitlab-duo-chat-101-get-more-done-on-gitlab-with-our-ai-assistant/)",[786,478,9,746,701,894],{"slug":1419,"featured":6,"template":683},"chat-about-your-merge-request-with-gitlab-duo","content:en-us:blog:chat-about-your-merge-request-with-gitlab-duo.yml","Chat About Your Merge Request With Gitlab Duo","en-us/blog/chat-about-your-merge-request-with-gitlab-duo.yml","en-us/blog/chat-about-your-merge-request-with-gitlab-duo",{"_path":1425,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1426,"content":1432,"config":1438,"_id":1440,"_type":13,"title":1441,"_source":15,"_file":1442,"_stem":1443,"_extension":18},"/en-us/blog/choosing-a-compliance-framework",{"title":1427,"description":1428,"ogTitle":1427,"ogDescription":1428,"noIndex":6,"ogImage":1429,"ogUrl":1430,"ogSiteName":670,"ogType":671,"canonicalUrls":1430,"schema":1431},"How GitLab went about choosing the right compliance framework","Independent vs aggregate? Determining the most effective security controls approach for any organization has many considerations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680591/Blog/Hero%20Images/compliance-frameworks.jpg","https://about.gitlab.com/blog/choosing-a-compliance-framework","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab went about choosing the right compliance framework\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeff Burrows\"}],\n        \"datePublished\": \"2019-05-07\",\n      }",{"title":1427,"description":1428,"authors":1433,"heroImage":1429,"date":1435,"body":1436,"category":704,"tags":1437},[1434],"Jeff Burrows","2019-05-07","\n\nIn most cases, information security compliance is a notoriously difficult area for smaller companies to get started with. Generally, when a company is large enough to have compliance needs, that company has already established a lot of its operating processes and configured the infrastructure.\n\nIn GitLab's case, we started our formalized compliance program towards the end of our [Series C funding round](/blog/gitlab-raises-20-million-to-complete-devops/), which is actually earlier than a lot of companies our size. This timing afforded GitLab a terrific opportunity to build out our compliance program. We were able to take a step back and consider the most efficient use of our personnel without an immediate need for external compliance certifications.\n\n## Defining security controls: Independent or aggregate?\n\nWhen it was time to identify security controls that would match up with processes and structure, we were faced with the decision a lot of small companies encounter: Do we treat each information security framework we have an interest in – or need for – independently, or do we try and aggregate these controls in a way that gives us natural alignment to underlying frameworks?\n\nBy interacting with industry frameworks (e.g. [ISO](https://www.iso.org/home.html), [SOC](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/sorhome.html), [PCI](https://www.pcisecuritystandards.org/), etc.) individually we would have clarity with each individual control in terms of scope and applicability. But we would have been reaching out to our internal teams with hundreds of individual controls, many of which overlap. An example of this overlap is that PCI DSS V3.2.1, SOC2 Common Controls, and ISO 27001 all require business continuity plans. With an individualized approach to security frameworks, we would be treating each business continuity plan separately and would run the risk of making multiple requests to GitLab teams in order to satisfy all requirements.\n\nBy adopting an “umbrella framework” approach and leveraging an open source option (i.e. [Adobe’s CCF](https://blogs.adobe.com/security/2017/05/open-source-ccf.html)), we’ve been able to build in efficiency and ensure that when we interact with our internal teams, we are not requesting the same information in multiple formats. In the above PCI DSS V3.2.1, SOC2 Common Controls, and ISO 27001 example, choosing an umbrella framework means evaluating all the individual requirements collectively and creating a control statement that fulfills the needs of each of the controls simultaneously. This creates an overarching security control that allows us to make a single request for business continuity information to each GitLab team and eliminates having to collect slightly different information depending on the framework we are working with at any given time. By being thoughtful about what is asked for, the compliance group gains internal credibility. The more agile and efficient we can enable our teams to be, the more productive GitLab becomes.\n\n## The GitLab approach\n\nWe’ve already begun adapting Adobe's framework to satisfy our own needs. This unified framework approach has allowed us to quickly create security controls and start building out the supporting guidance and policy information. And we’ve been able to stand up a comprehensive compliance program – in months, not years.\n\nAs we spend more time customizing the Adobe CCF open source framework and aligning the compliance process to the GitLab product workflow, we plan to share what we’ve created and what we’ve learned along the way through a series of blog posts. We’ll also make some of these resources available to our customers in the hopes that it can help other organizations jump start their own compliance journeys.\n\nDo you have thoughts on the approach GitLab is taking with our compliance framework adoption?  Or maybe you have feedback on particular compliance needs you’d like to see GitLab address going forward? Share your thoughts with us below; we’d love to hear from you!\n\nCover image by [Erik Witsoe](https://unsplash.com/@ewitsoe) on [Unsplash](https://unsplash.com/photos/mODxn7mOzms)\n{: .note}\n",[9,680,704],{"slug":1439,"featured":6,"template":683},"choosing-a-compliance-framework","content:en-us:blog:choosing-a-compliance-framework.yml","Choosing A Compliance Framework","en-us/blog/choosing-a-compliance-framework.yml","en-us/blog/choosing-a-compliance-framework",{"_path":1445,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1446,"content":1452,"config":1458,"_id":1460,"_type":13,"title":1461,"_source":15,"_file":1462,"_stem":1463,"_extension":18},"/en-us/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch",{"title":1447,"description":1448,"ogTitle":1447,"ogDescription":1448,"noIndex":6,"ogImage":1449,"ogUrl":1450,"ogSiteName":670,"ogType":671,"canonicalUrls":1450,"schema":1451},"CI/CD Catalog goes GA: No more building pipelines from scratch","The CI/CD Catalog becomes generally available in GitLab 17.0. Get to know the capabilities for discovering and sharing pipeline building blocks to help standardize and scale pipelines.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098794/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%289%29_DoeBNJVrhv9FpF3WCsHNc_1750098793762.png","https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CD Catalog goes GA: No more building pipelines from scratch\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2024-05-08\",\n      }",{"title":1447,"description":1448,"authors":1453,"heroImage":1449,"date":1455,"body":1456,"category":701,"tags":1457},[1454],"Dov Hershkovitch","2024-05-08","GitLab's [CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/#cicd-catalog) becomes generally available in 17.0 (May 16, 2024), enabling all GitLab users to discover, reuse, and contribute CI/CD components easily. The CI/CD Catalog boosts collaboration and efficiency when creating pipeline configurations by allowing access to a treasure trove of pre-built components, ready to seamlessly integrate into DevSecOps workflows. Enterprises can use the CI/CD Catalog's centralized platform to standardize workflows across the whole organization.\n\nWith the CI/CD Catalog, GitLab is introducing several key capabilities that are also generally available.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n## Components and inputs\nThe [CI/CD Catalog](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/) draws its strength from two fundamental features: components and inputs. These capabilities form the backbone of the catalog, enabling developers and DevSecOps teams to streamline their pipeline development. Let’s dive into each of these features:\n\n### Components\n\n#### What are components?\nComponents are reusable, single-purpose building blocks that abstract away the complexity of pipeline configuration. Think of them as Lego pieces for your CI/CD workflows. By using components, you can assemble pipelines more efficiently without starting from scratch each time.\n\n#### Types of components\n- Template-type components: These components resemble CI templates and come with predefined input definitions. They are organized within a specific directory structure, which you can easily plug into your pipelines.\n- CI Steps (upcoming): This new type of component, which is available as an [experimental feature](https://docs.gitlab.com/ee/ci/steps/), will become a first-class object in the CI/CD Catalog, so stay tuned for this exciting addition.\n\n### Inputs\n\n#### What is Inputs Interpolation?\n\nInputs Interpolation is a powerful feature that allows you to define input parameters for includable configuration files. By using the [spec: inputs keyword](https://docs.gitlab.com/ee/ci/yaml/#specinputs) within your component configuration, you can dynamically replace almost any keywords within components with parameters. This flexibility extends to adjusting stages, scripts, or job names, supporting various data types making the component fully flexible to your needs.\n\n##### Scoped and effective\nImportantly, inputs are scoped exclusively to the included configuration. This prevents unintended effects on the rest of your pipeline. With Inputs Interpolation, you can declare and enforce constraints seamlessly, ensuring smooth integration of components.\n\nWhether you’re a seasoned DevOps pro or just starting out, the CI/CD Catalog, components, and Inputs Interpolation will transform your pipeline development experience.\n\n## How to access CI/CD Catalog components\nThe CI/CD Catalog is a powerful resource for developers and DevOps teams. It allows you to share and discover pre-built components, streamlining your pipeline development. Here’s how it works:\n\n1. Components are standalone building blocks that simplify pipeline configuration. You can create custom components tailored to your needs. But how do you make them available to others? That’s where the CI/CD Catalog comes in.\n\n2. How to publish to the CI/CD Catalog\n    - To share your components with the community, follow these steps:\n      - Use a simple CI job to publish your component and make it discoverable in the CI/CD Catalog.\n      - Whether it’s a reusable script, a deployment template, or any other pipeline element, the CI/CD Catalog is the perfect place to contribute.\nComponents released to the CI/CD Catalog should be tagged with a [semantic version](https://docs.gitlab.com/ee/ci/components/#semantic-versioning) using three digits.\n    - By sharing your components, you contribute to a growing library of resources that benefit the entire community.\n3. Catalog index page\n    - The main page of the CI/CD Catalog (also known as the index page) provides an overview of available projects with published components. Anyone can access the catalog and search for a component that suits their needs.\n    - The index page features two tabs:\n      - All: Displays all component projects that have been published and visible to you.\n      - Your groups: Shows components published within a namespace you’re part of.\n\n![CI/CD Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098805/Blog/Content%20Images/Blog/Content%20Images/catalog_index_aHR0cHM6_1750098804807.png)\n\n4.  Catalog details page\n\n- Upon clicking on one of the projects in the CI/CD Catalog, you will be redirected to the details page where you can view the available components in that project. \n    - Note that there could be multiple components in a single project.\n\n- The details page features two tabs:\n\u003Ccenter>\u003Ci>Readme: Displays the readme.md of the project that was previously configured by the user.\u003C/i>\u003C/center>\n\n![readme tab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098805/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098804808.png)\n\n\u003Ccenter>\u003Ci>Components: Displays the detailed information for each component such as inputs table syntax to use and more. This information is generated and displayed automatically to help keep it up to date.\u003C/i>\u003C/center>\n\n![components tab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098805/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098804809.png)\n\n## Using a component\n\nTo use a component from the CI/CD Catalog, simply copy the suggested snippet to your pipeline configuration. For example: \n\n```yaml\n\ninclude: \n  - component:   gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@0.1.0\n\n```\n\nNote that the snippet contains the fully qualified domain name of the component, so if you moved or clone the component to a different location, you should make sure the FQDN is accurate. You can use the $CI_SERVER_FQDN variable instead of hardcoding the FQDN in your pipeline configuration.\n\nA component can be referenced using the following:\n\n- a commit SHA, for example, e3262fdd0914fa823210cdb79a8c421e2cef79d. We highly recommend using this with $CI_COMMIT_SHA variable in your `.gitlab.ci.yml` file to test a component before publishing it to the CI/CD Catalog.\n- a branch name, for example, main\n- a tag, for example 1.0.0\n- shorthand abbreviation 1.0, which will provide you the latest patched 1.0.x version or 1, which will provide you the latest 1.x.x minor version. This is why it is recommended to use the best practices of semantic versioning and always reference a specific version (minor, major, or a specific patch).\n- ~latest, which always points to the latest semantic version published in the CI/CD Catalog. Use ~latest only if you want to use the absolute latest version at all times, which could include breaking changes., so please use it with caution.\n\n## Understanding the CI/CD Catalog across GitLab deployments\nThe CI/CD Catalog and components offer different flavors to cater to various needs and use cases.\n\n### Private and public components\n\n#### Public components\n\n- Public components are hosted in public repositories and are accessible to everyone.\n- When a public component is published from GitLab.com to the main catalog, it becomes discoverable and available for consumption by all users.\n- We encourage users to contribute their best components to the public catalog, helping us build a thriving community.\n\n#### Private components\n\n- Private components are hosted in private repositories.\n- Visibility based on permissions: Users who access the catalog can also see and search for private components if they have permission to view the repository where the component is hosted.\n    - Private catalog option: In GitLab.com, organizations can publish private components to the main catalog in GitLab.com, thereby creating a “private catalog” with content accessible only to authorized users. \n\n### GitLab.com vs. Self-managed\n- The “public” catalog in GitLab.com: The main catalog is the one that is hosted on GitLab.com and can be accessible to anyone by going to [gitlab.com/explore/catalog](http://gitlab.com/explore/catalog). The CI/CD Catalog is:\n    - Open access: The catalog hosted on GitLab.com is available for anyone to view.\n    - Contribute and grow: By sharing components, users around the world contribute to a growing library of resources that benefits the entire community.\n\n- Self-managed customers: The CI/CD Catalog is also available for self-managed customers however it has several differences: \n    - Empty catalog: For self-managed customers, the catalog initially appears empty since it doesn't contain any available components.\n    - Organizational catalog: Each organization is responsible for its own catalog, where it can create and maintain its own library of components within this flavor.\n    - Using a component from GitLab.com: If you want to use a component from the main catalog in GitLab.com, clone the project locally and publish it to your organizational catalog. Keep in mind that upstream updates will require mirroring to receive the latest changes. You can learn more about how to do that in our [CI/CD Components documentation](https://docs.gitlab.com/ee/ci/components/#use-a-gitlabcom-component-in-a-self-managed-instance).\n\n## What’s next?\n\nThe CI/CD Catalog is only the first step in revolutionizing the way you build and display your available pipelines. Here is a glimpse of what we plan to offer to our users in the upcoming milestones.\n\n### CI Steps\n\nSteps are reusable and composable pieces of a job that can be referenced in your pipeline configuration. Each step defines structured inputs and outputs that can be consumed by other steps. Steps can come from local files, GitLab.com repositories, or any other Git source.\n\nIn GitLab, we think of steps as another type of component. We are going to make sure CI Steps will become a first-class object in the CI/CD Catalog, where users can publish, unpublish, search, and consume steps in the same way as they are using components today.\n\n### Securing your catalog workflows\n\nWe aim to empower central administrators to manage component creation, usage, and publication within their organizational catalog. We are committed to ensuring the publishing process seamlessly integrates with the organization's standards and existing workflow. We want to enable the platform administrators with the capabilities to secure and govern the CI/CD Catalog and component workflows. More information can be found in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/12713).\n\n### Analytics\n\nOur goal is to empower users with seamless control over component management across pipelines, ensuring optimal version control and project alignment. This addresses the challenge of users currently lacking visibility into component usage across various project pipelines. Our objective is to provide users with the capability to swiftly identify outdated versions and take prompt corrective actions as needed. This enhancement will foster an environment where users can efficiently manage and update components, promoting both version control precision and project alignment. Read more in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/393326).\n\n## Get started with the CI/CD Catalog\n\nThe introduction of the CI/CD Catalog revolutionizes pipeline development by offering a vast array of pre-built components. Users don't have to start building pipelines from scratch because the CI/CD Catalog provides an access point to search components and pipeline configurations. The CI/CD Catalog's availability makes accessing and sharing components effortless, fostering collaboration and community growth. Whether utilizing public or private repositories, users can leverage these resources to enhance their pipeline development experience. Moreover, while GitLab.com users benefit from an open-access catalog, self-managed customers can establish organizational catalogs tailored to their needs.\n\n> [Get to know the CI/CD Catalog](https://about.gitlab.com/free-trial/devsecops/) with a free 30-day trial of GitLab Ultimate.\n\n> Learn more about the CI/CD Catalog and components:\n> \n> - [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n>\n> - [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n>\n> - [Documentation: CI/CD components and CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/)\n> \n> - [Introducing CI/CD components and how to use them in GitLab](https://about.gitlab.com/blog/introducing-ci-components/)\n> \n",[108,703,478,9],{"slug":1459,"featured":90,"template":683},"ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch","content:en-us:blog:ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch.yml","Ci Cd Catalog Goes Ga No More Building Pipelines From Scratch","en-us/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch.yml","en-us/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch",{"_path":1465,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1466,"content":1471,"config":1476,"_id":1478,"_type":13,"title":1479,"_source":15,"_file":1480,"_stem":1481,"_extension":18},"/en-us/blog/code-suggestions-for-all-during-beta",{"title":1467,"description":1468,"ogTitle":1467,"ogDescription":1468,"noIndex":6,"ogImage":906,"ogUrl":1469,"ogSiteName":670,"ogType":671,"canonicalUrls":1469,"schema":1470},"Code Suggestions available to all GitLab tiers while in Beta","All users can acess Code Suggestions AI-assisted feature while it is in Beta.","https://about.gitlab.com/blog/code-suggestions-for-all-during-beta","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Code Suggestions available to all GitLab tiers while in Beta\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Neha Khalwadekar\"}],\n        \"datePublished\": \"2023-05-16\",\n      }",{"title":1467,"description":1468,"authors":1472,"heroImage":906,"date":1473,"body":1474,"category":806,"tags":1475},[911],"2023-05-16","\n\n\u003Ci>This blog is the latest post in an ongoing series about GitLab’s journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we’ll feature blogs from our product, engineering, and UX teams to showcase how we’re infusing AI/ML into GitLab.\u003C/i>\n\nCode Suggestions is now available on GitLab.com for all users for free while the feature is in Beta. Teams can boost efficiency with the help of generative AI that suggests code while you're developing. We've extended language support from our initial six languages to now include 13 languages: C/C++, C#, Go, Java, JavaScript, Python, PHP, Ruby, Rust, Scala, Kotlin, and TypeScript. \n\nWe are making improvements to the Code Suggestions underlying AI model weekly to improve the quality of suggestions. Please remember that AI is non-deterministic, so you may not get the same suggestion week to week.\n\n## Privacy first\nCode Suggestions is built with privacy as a critical foundation. It keeps your proprietary source code secure within GitLab's enterprise cloud infrastructure, and this code isn't used as training data. Source code inference against the Code Suggestions model is not used to re-train the model. Learn about [data usage when using Code Suggestions](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#code-suggestions-data-usage). \n\n## IDE support\nCode Suggestions is available in VS Code via the [GitLab Workflow extension](https://docs.gitlab.com/ee/user/project/repository/vscode.html#gitlab-workflow-extension-for-vs-code). We will soon support the GitLab WebIDE with GitLab 16.0. We are also working on adding [additional IDE support](https://gitlab.com/groups/gitlab-org/-/epics/10542) based on customer feedback, including JetBrains IntelliJ-based IDEs and Visual Studio support for code suggestions. We are also working to improve the user experience for how suggestions are presented and accepted within the IDEs to give developers more control over how the feature works. Additionally we're working to make it easier to setup Code Suggestions the first time and authenticate with GitLab.com \n\n## Self-managed support\nWe are also working to bring Code Suggestions to self-managed instances [via a secure connection to GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/10528). If you have unique requirements for your self-managed instances, we welcome you to express your interest in our [self-managed support issue](https://gitlab.com/gitlab-org/gitlab/-/issues/409183). Commenting on that issue will give you notifications as we post updates. \n\n## Enable Code Suggestions\nOur documentation details how to [enable Code Suggestions in VS Code](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#enable-code-suggestions-in-vs-code). Below is a quickstart video walkthrough:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/WnxBYxN2-p4\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Beta feature\nThis feature is in [Beta](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#beta). Code Suggestions uses generative AI to suggest code while you're developing. Due to high demand, this feature will have unscheduled downtime and code suggestions in VS Code may be delayed. Code Suggestions may produce [low-quality or incomplete suggestions](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#model-accuracy-and-quality). We look forward to hearing your feedback. Beta users should read about the [known limitations](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#known-limitations). \n\nWe would love to hear about your experience and report issues in the [feedback issues](https://gitlab.com/gitlab-org/gitlab/-/issues/405152). \n\nCode Suggestions is just one of the ways we’re infusing GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-powered features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](https://about.gitlab.com/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information about upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":1477,"featured":6,"template":683},"code-suggestions-for-all-during-beta","content:en-us:blog:code-suggestions-for-all-during-beta.yml","Code Suggestions For All During Beta","en-us/blog/code-suggestions-for-all-during-beta.yml","en-us/blog/code-suggestions-for-all-during-beta",{"_path":1483,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1484,"content":1489,"config":1494,"_id":1496,"_type":13,"title":1497,"_source":15,"_file":1498,"_stem":1499,"_extension":18},"/en-us/blog/code-suggestions-improves-developer-productivity",{"title":1485,"description":1486,"ogTitle":1485,"ogDescription":1486,"noIndex":6,"ogImage":906,"ogUrl":1487,"ogSiteName":670,"ogType":671,"canonicalUrls":1487,"schema":1488},"How Code Suggestions can supercharge developers' daily productivity","Learn how you can use GitLab Code Suggestions to accelerate your development.","https://about.gitlab.com/blog/code-suggestions-improves-developer-productivity","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Code Suggestions can supercharge developers' daily productivity\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Neha Khalwadekar\"}],\n        \"datePublished\": \"2023-05-25\",\n      }",{"title":1485,"description":1486,"authors":1490,"heroImage":906,"date":1491,"body":1492,"category":806,"tags":1493},[911],"2023-05-25","\n\n\u003Ci>This blog is the latest post in an ongoing series about GitLab’s journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we’ll feature blogs from our product, engineering, and UX teams to showcase how we’re infusing AI/ML into GitLab.\u003C/i>\n\nIn the fast-paced world of software development, time is a precious resource. Developers constantly strive for ways to improve the productivity and efficiency of their workflows. Enter Code Suggestions, a large language model (LLM)-based technology that can transform the everyday developer experience. Let’s delve into the novel use cases of Code Suggestions, including: \n\n* simplifying operations\n* assisting new developers in language explorations\n* eliminating the need for frequent web searches by experienced developers\n\nAll of these are examples of how Code Suggestions can accelerate the daily developer experience. Let’s explore some specific examples of these use cases.\n\n## Import packages\nWith Code Suggestions, developers can quickly complete mundane tasks like importing Python packages. \n![Example](https://about.gitlab.com/images/blogimages/2023-05-25-Blog-code-suggestions-improves-developer-productivity/python_packages.gif)\n\n\n## Complete functions\nCode Suggestions can help developers complete functions and use those functions to write code. In the example below, we are defining the first and last name and then defining a full name. Now we can take this a step forward and use those defined functions in a user form. \n![Example](https://about.gitlab.com/images/blogimages/2023-05-25-Blog-code-suggestions-improves-developer-productivity/sample_functions.gif)\n\n\n## Fill in boilerplate\nDevelopers can use Code Suggestions to recommend boilerplate code such as connecting to a mySQL database.\n![Example](https://about.gitlab.com/images/blogimages/2023-05-25-Blog-code-suggestions-improves-developer-productivity/mysql-boiler.gif)\n\n\n## Building data frames\nData manipulation is a fundamental task for developers working with structured data. Code Suggestions can simplify the process of offering intelligent recommendations for DataFrame operations. Code Suggestions can assist in saving developers the time and effort of searching through documentation or experimenting with trial and error.\n![Example](https://about.gitlab.com/images/blogimages/2023-05-25-Blog-code-suggestions-improves-developer-productivity/dataframe.gif)\n\n\n## Generate unit tests\nWith Code Suggestions, developers can quickly write unit tests for the supported programming languages.\n![Example](https://about.gitlab.com/images/blogimages/2023-05-25-Blog-code-suggestions-improves-developer-productivity/unit-test.gif)\n\n\n## Try Code Suggestions today\nCode Suggestions is now available for free on GitLab.com for all users while the feature is in Beta. Teams can boost efficiency with the help of generative AI that suggests code while they're developing. We are improving the underlying AI model weekly to improve the [quality of suggestions](https://gitlab.com/groups/gitlab-org/-/epics/10562). Please remember that AI is non-deterministic, so you may not get the same suggestion from week to week. Also remember that any time you are using AI-generated code you should be automatically analyzing it with [code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) and [security scanning](https://docs.gitlab.com/ee/user/application_security/), both of which are available natively in the GitLab platform. \n\nWe’ve extended [language support](https://gitlab.com/groups/gitlab-org/-/epics/10561) from our initial six languages to now include 13 languages: C/C++, C#, Go, Java, JavaScript, Python, PHP, Ruby, Rust, Scala, Kotlin, and TypeScript.\n\nRead more about these [improvements and what’s next.](https://about.gitlab.com/blog/code-suggestions-for-all-during-beta/)\n\nInterested in using these AI-powered features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](https://about.gitlab.com/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information about upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":1495,"featured":6,"template":683},"code-suggestions-improves-developer-productivity","content:en-us:blog:code-suggestions-improves-developer-productivity.yml","Code Suggestions Improves Developer Productivity","en-us/blog/code-suggestions-improves-developer-productivity.yml","en-us/blog/code-suggestions-improves-developer-productivity",{"_path":1501,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1502,"content":1508,"config":1515,"_id":1517,"_type":13,"title":1518,"_source":15,"_file":1519,"_stem":1520,"_extension":18},"/en-us/blog/combine-gitlab-webhooks-and-twilio-for-sms-alerts-on-devsecops-platform",{"title":1503,"description":1504,"ogTitle":1503,"ogDescription":1504,"noIndex":6,"ogImage":1505,"ogUrl":1506,"ogSiteName":670,"ogType":671,"canonicalUrls":1506,"schema":1507},"Combine GitLab webhooks and Twilio for SMS alerts on DevSecOps platform","Configure GitLab webhooks with SMS alerts to instantly get feedback on new and existing issues within a project and enable teams to react quickly to project- and group-level changes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099013/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2814%29_6VTUA8mUhOZNDaRVNPeKwl_1750099012960.png","https://about.gitlab.com/blog/combine-gitlab-webhooks-and-twilio-for-sms-alerts-on-devsecops-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Combine GitLab webhooks and Twilio for SMS alerts on DevSecOps platform\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ted Gieschen\"}],\n        \"datePublished\": \"2024-06-10\",\n      }",{"title":1503,"description":1504,"authors":1509,"heroImage":1505,"date":1511,"body":1512,"category":1513,"tags":1514},[1510],"Ted Gieschen","2024-06-10","We all strive to create the most robust and secure DevSecOps environments where everyone can collaborate to deliver amazing products for our customers. But no matter how robust and secure we design our environments we cannot exclude the possibility that something might go wrong. When an issue does occur we want to make sure we can remediate it quickly. To do that it's not only important to document the details of the issue but also get the right people notified immediately. In this article, we will set up GitLab [webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) together with [Twilio's functionality](https://www.twilio.com/en-us) to [send SMS alerts](https://www.twilio.com/docs/messaging) to the right people, getting them up to date so they can mitigate problems quickly.\n\n## Prerequisites\n\n1. A GitLab account: Webhooks aren't restricted by tier, which means this feature can be used with a [Free, Premium or Ultimate license](https://about.gitlab.com/pricing/) for either [GitLab's SaaS or self-managed offering](https://docs.gitlab.com/ee/subscriptions/choosing_subscription.html). If you don't have an account yet, you can create one on [our sign-up page]( https://gitlab.com/users/sign_up).\n\n2. A Twilio account: To handle the incoming webhook and send an SMS, you will need a Twilio account. If you don't already have one, you can create one on [Twilio's sign-up page](https://www.twilio.com/try-twilio).\n\n3. (Optional) An SMS-capable phone to test the functionality: We will be testing the functionality at the end of this article. If you want to follow along, you will need access to a phone that can receive SMS texts.\n\n4. (Optional) A basic understanding of Node.js: We will be handling the webhooks using a serverless function provided by Twilio Functions. This will be written in [Node.js](https://nodejs.org/en/about). Although you can simply copy-paste the functionality, it would be beneficial to understand the basics of Node.js so you can expand functionality in the future.\n\n## Building automated SMS notifications\n\nNow, let's get hands-on with building real-time SMS notifications.\n\nAt a high level, the workflow looks as follows:\n\n![SMS workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099023261.png)\n\n1. An event is triggered within GitLab. This event is then picked up by GitLab's webhook functionality.\n2. The information of the event is then sent as a webhook to a [Twilio Function](https://www.twilio.com/docs/serverless/functions-assets/functions).\n3. Twilio Functions processes the event data sent by GitLab and creates the SMS body with relevant information.\n4. When complete, Twilio Functions triggers [Twilio Programmable Messaging](https://www.twilio.com/docs/messaging) with the SMS body and recipient information.\n5. Twilio Programmable Messaging then sends the SMS with the generated body to the recipient.\n\n### Set up Twilio SMS\n\nWe need to set up our Twilio environment to be able to send SMS. To do this, log in to your Twilio account. If you don't have one just follow the link provided in the prerequisites section above.\n\nOnce logged in you will see the Twilio Console, which will look something like this:\n\n![Twilio console](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099023261.png)\n\nFrom here, we will head to the left sidebar menu and select __United States (US1) > Phone Numbers > Manage > Active numbers__ and then click the \"Buy a number\" button.\n\n![Buy a number screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750099023263.png)\n\nYou can select a phone number, which will be the number that notifications are sent from. There are some [guidelines](https://www.twilio.com/docs/messaging/guides/sending-international-sms-guide) specific to which countries you can send SMS based on the Twilio phone number you purchase, so please keep that in mind. In this example, I will be using my personal U.S. phone number for this article as the recipient phone number, so, in this case, I will purchase a U.S. Twilio number. Just make sure your phone number has the SMS capability. Once selected, simply click the \"Buy \u003Cphone number>\"  button.\n\n![twilio webhooks - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099023265.png)\n\nNext, we just need to make sure Twilio can send SMS to our recipient phone number by allowing Twilio Programmable Messaging to send SMS to the country our recipient phone number is associated with. To do so, head to __[United States (US1) > Messaging > Settings > Geo permissions__ and make sure that the country associated with the recipient's phone number is selected (for example, as I am using my U.S. phone number as the recipient phone number in this blog, I will select United States).\n\n![twilio webhooks - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750099023267.png)\n\nClick \"Save geo permissions.\" With that we're all set up to send SMS.\n\nNext, let's handle the processing of the webhook and the creation of our SMS alerts with Twilio Functions.\n\n### Set up Twilio Functions\n\nTo process the webhook we will be sending to Twilio, we need to define a Twilio Function. To do this, select **United States (US1) > Functions and Assets > Functions (Classic) > List** and click \"Create a Function.\" Select the \"Hello SMS\" option in the pop-up and click \"Create.\"\n\n![Create a Twilio function](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099023269.png)\n\nNow, let's go ahead and configure our Twilio Function.\n\n1. Extend the path for example `/handle-event-webhook`. In my case this would result in the following path: `https://daff-mac-7354.twil.io/handle-event-webhook`.\n\n2. Disable the option `Check for valid Twilio signature`.\n\n3. Adjust the code to the following, making sure to update the values for `\u003Cyour personal phone number>` and `\u003Cyour Twilio Phone number>`:\n\n``` javascript\nexports.handler = function (context, event, callback) {\n  const twilioClient = context.getTwilioClient();\n\n  twilioClient.messages\n    .create({\n      body: `Hi there! There was an update to issue (${event[\"object_attributes\"][\"id\"]}) with title \"${event[\"object_attributes\"][\"title\"]}\" in project ${event[\"repository\"][\"name\"]}. It was just ${event[\"object_attributes\"][\"action\"]}.`,\n      to: \"\u003Cyour personal phone number>\",\n      from: \"\u003Cyour Twilio Phone number>\",\n    })\n    .then((message) => {\n      console.log(\"SMS successfully sent\");\n      console.log(message.sid);\n      return callback(null, `Success! Message SID: ${message.sid}`);\n    })\n    .catch((error) => {\n      console.error(error);\n      return callback(error);\n    });\n};\n\n```\n\nIt should end up looking like the following:\n\n  ![Configuration for Twilio function](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099023271.jpg)\n\nNow, whenever our endpoint is hit, it should trigger an SMS with a custom message indicating a change to an existing issue which will represent an example of the various [webhook events](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html) we can configure.\n\nNext, let's set our webhooks within GitLab to trigger this endpoint whenever a change to an issue is made.\n\n### Set up GitLab webhooks\n\nLog in to your GitLab instance and go to the project you would like to configure event webhooks in.\n\nOnce in the Project, go to **Settings > Webhooks** and click on \"Add new webhook.\"\n\n![Screen to add a new webhook](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099023273.png)\n\nYou will only need to configure the following fields:\n\n1. URL: This should be the endpoint we defined in the previous section. In the previous example that would be `https://daff-mac-7354.twil.io/handle-event-webhook`.\n\n2. Trigger: In our case, we will be reacting to [issues events](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#issue-events), so check \"Issues events.\"\n\n![Configuring URL and trigger fields](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099023274.png)\n\nWe're all set to test our setup!\n\n### Testing\n\nWhile in the project that was just configured to react to issues events, head to \"Plan > Issues\" and click on \"New issue.\"\n\n![New issue screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099023276.png)\n\nAdd a title and click on \"Create Issue.\"\n\n  ![Create issue screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099023/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750099023278.png)\n\nIf everything is configured correctly, you should get an SMS looking something like:\n\n`Sent from your Twilio trial account - Hi there! There was an update to issue (146735617) with title \"GitLab webhook example\" in project Webhooks Example. It was just opened.`\n\n## Expanding the use case\n\nWe've leveraged Twilio's SMS functionality in combination with GitLab webhooks to instantly get feedback on new and existing issues within our project, allowing us to react quickly to any changes that might occur. This simple use case showed how one person could instantly get informed about a single type of event. However, often we want to inform more people about various events or be able to react to more than just one type of event (like issue creation and updates).\n\nThis functionality can be expanded by:\n\n1. Sending SMS alerts to multiple people: This can be achieved by extending the Twilio Function to loop through a given array of phone numbers. [Twilio's Messaging Service](https://www.twilio.com/docs/messaging/services) can be leveraged to potentially simplify the process of sending SMS to various phone numbers.\n\n2. Handling different event types: Select more types of webhook events in the Project settings to react to other things like [comments](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#comment-events), [deployments](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#deployment-events), or [releases](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#release-events).\n\n3. Configure on a group level: In this example, we’ve only configured webhooks on a project level. However, if it is relevant to react to events across projects on a group level, this can also be configured, removing the need to change webhook settings for each project.\n\n4. Self-host message generation functionality: Leverage [Twilio Server Side SDKs](https://www.twilio.com/docs/libraries) instead of Twilio Functions to host the code yourself. This could benefit you if you have restrictions on where you can host code as well as allow you to more easily connect with the rest of your code base likecfetching information from your database to get phone numbers for relevant people.\n\n> Start [a free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial) today to test-drive more DevSecOps features.","devsecops",[9,746,701,704,478],{"slug":1516,"featured":90,"template":683},"combine-gitlab-webhooks-and-twilio-for-sms-alerts-on-devsecops-platform","content:en-us:blog:combine-gitlab-webhooks-and-twilio-for-sms-alerts-on-devsecops-platform.yml","Combine Gitlab Webhooks And Twilio For Sms Alerts On Devsecops Platform","en-us/blog/combine-gitlab-webhooks-and-twilio-for-sms-alerts-on-devsecops-platform.yml","en-us/blog/combine-gitlab-webhooks-and-twilio-for-sms-alerts-on-devsecops-platform",{"_path":1522,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1523,"content":1529,"config":1534,"_id":1536,"_type":13,"title":1537,"_source":15,"_file":1538,"_stem":1539,"_extension":18},"/en-us/blog/coming-soon-gitlab-dependency-firewall",{"title":1524,"description":1525,"ogTitle":1524,"ogDescription":1525,"noIndex":6,"ogImage":1526,"ogUrl":1527,"ogSiteName":670,"ogType":671,"canonicalUrls":1527,"schema":1528},"Coming soon: GitLab dependency firewall","Learn how this new feature will help organizations avoid supply chain software attacks by warning them or blocking the download based on a project's policy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665667/Blog/Hero%20Images/built-in-security.jpg","https://about.gitlab.com/blog/coming-soon-gitlab-dependency-firewall","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Coming soon: GitLab dependency firewall\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-03-26\",\n      }",{"title":1524,"description":1525,"authors":1530,"heroImage":1526,"date":1531,"body":1532,"category":704,"tags":1533},[1040],"2024-03-26","The [Maven dependency proxy](https://about.gitlab.com/blog/gitlabs-maven-dependency-proxy-is-available-in-beta/) was released in GitLab 16.8. This new feature allows organizations to proxy and cache packages from one upstream repository to a GitLab project, which can help reduce reliance on external sources.\n\nHowever, with this added efficiency there is an added security risk of software supply chain attacks like [typosquatting](https://www.mcafee.com/learn/what-is-typosquatting) and other dependency confusion attacks. Supply chain attacks are when attackers try to get developers and CI/CD pipelines to include malicious packages to increase the surface area of the attack.\n\nThe [dependency firewall](https://gitlab.com/groups/gitlab-org/-/epics/5133), planned for the second half of 2024, will help organizations avoid these attacks by warning them or blocking the download based on their project's policy.\n\n## What is the dependency firewall?\n\nThe dependency firewall is the first line of defense when downloading packages from the internet.\n\nAt a high level, GitLab wants to build the following capabilities into the dependency firewall:\n\n* prevent malicious packages from entering the software supply chain\n* check each new package against GitLab [policy](https://docs.gitlab.com/ee/user/application_security/policies/)\n* quarantine packages for review before they are available\n* manage quarantined packages\n* report package usage\n\n### What does a dependency firewall policy do?\n\nThe planned dependency firewall policy will do two things: `warn` and `fail`. You will be able to create a **dependency firewall policy** that warns your organization when certain conditions are met or quarantines the package. For example, you can create a policy that prevents the package from being downloaded if it has any known critical vulnerabilities. Or you can simply add a warning for packages with known, but less severe, vulnerabilities. \n\n**Note:** The warnings can be limited to the log files for the minimal viable change (MVC).\n\nThe first rule we'll support will be as follows:\n```\n1. When `Security scan`\n2. Select \"Scanners\" (dependency scanning)\n3. With `No exceptions` that finds `Any` vulnerabilities matching\n4. `Critical` severity\n```\n\nFor the MVC, we will focus on adding a warning when a package downloaded through the dependency proxy has any known critical vulnerabilities. \n\nBeyond the MVC, we will add support for the following:\n- lower severity vulnerabilities\n- warnings in the package registry UI list view\n- rules to quarantine packages\n- the ability to review and update the quarantine\n- the ability to add a warning to the security vulnerability report\n\n## More about rules\n\n1. Rules that are `warn` only can leverage a background job. Rules that `fail` need to be handled by the web request.\n1. Rules handled by a background job can have an extended scope. For example, we can inspect the package information and open the archive to get the metadata, inspect it, and provide more robust rules and conditions.\n1. Rules handled within the web request must be fast and scalable. This will limit what we can do in these cases.\n\n## Next steps\n\nTo learn more or contribute to the dependency firewall, please [visit our dependency firewall epic](https://gitlab.com/groups/gitlab-org/-/epics/5133).\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[704,678,9,108],{"slug":1535,"featured":6,"template":683},"coming-soon-gitlab-dependency-firewall","content:en-us:blog:coming-soon-gitlab-dependency-firewall.yml","Coming Soon Gitlab Dependency Firewall","en-us/blog/coming-soon-gitlab-dependency-firewall.yml","en-us/blog/coming-soon-gitlab-dependency-firewall",{"_path":1541,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1542,"content":1548,"config":1554,"_id":1556,"_type":13,"title":1557,"_source":15,"_file":1558,"_stem":1559,"_extension":18},"/en-us/blog/comment-on-commits-feature-tutorial",{"title":1543,"description":1544,"ogTitle":1543,"ogDescription":1544,"noIndex":6,"ogImage":1545,"ogUrl":1546,"ogSiteName":670,"ogType":671,"canonicalUrls":1546,"schema":1547},"Demo: How to use Merge Request Commit Discussions","You can now hold discussions on specific commits within a merge request – check out how it works in this video.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680285/Blog/Hero%20Images/merge-request-commit-discussions.jpg","https://about.gitlab.com/blog/comment-on-commits-feature-tutorial","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Demo: How to use Merge Request Commit Discussions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n        \"datePublished\": \"2018-01-04\",\n      }",{"title":1543,"description":1544,"authors":1549,"heroImage":1545,"date":1551,"body":1552,"category":849,"tags":1553},[1550],"Victor Wu","2018-01-04","\n\nIn [GitLab 10.3](/releases/2017/12/22/gitlab-10-3-released/) we released a new feature: [Merge Request Commit Discussions](/releases/2017/12/22/gitlab-10-3-released/#merge-request-commit-discussions). This is great news for teams who work at the individual commit level, who want to be able to discuss and collaborate on different commits within one merge request. Watch the video below to see this new workflow in action.\n\n\u003C!-- more -->\n\nIn short: this feature (available in both GitLab [Community and Enterprise Editions](/stages-devops-lifecycle/)) allows you to add comments to [commits within a merge request](/solutions/continuous-integration/). Before you could only add comments to a particular version of a merge request. In the video, you'll see how now when you navigate to a specific commit, you're taken to the \"Changes\" tab, but instead of viewing the latest version, you see the diff associated with that commit.\n\nYou can then leave a comment inline as you would usually, the difference being that your comment now starts a conversation relating specifically to that commit.\n\nIf you leave a comment on another commit, that begins a separate discussion as well. All are accessible from the \"Commits\" tab or the Discussions\" tab. You can resolve discussions as usual, with resolved discussions being collapsed by default, similar to before.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/TviJH6oRboo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWe hope teams who need a more granular approach to approving merge requests will find this useful! As usual, we welcome your feedback – be it on the [release blog post](/releases/2017/12/22/gitlab-10-3-released/) or by opening an issue.\n\n[Cover image](https://unsplash.com/photos/qm3nnbaBl_4) by [Matthew Brodeur](https://unsplash.com/@mrbrodeur) on Unsplash\n{: .note}\n",[9,829],{"slug":1555,"featured":6,"template":683},"comment-on-commits-feature-tutorial","content:en-us:blog:comment-on-commits-feature-tutorial.yml","Comment On Commits Feature Tutorial","en-us/blog/comment-on-commits-feature-tutorial.yml","en-us/blog/comment-on-commits-feature-tutorial",{"_path":1561,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1562,"content":1568,"config":1574,"_id":1576,"_type":13,"title":1577,"_source":15,"_file":1578,"_stem":1579,"_extension":18},"/en-us/blog/compliance-made-easy",{"title":1563,"description":1564,"ogTitle":1563,"ogDescription":1564,"noIndex":6,"ogImage":1565,"ogUrl":1566,"ogSiteName":670,"ogType":671,"canonicalUrls":1566,"schema":1567},"How to build a compliance program with ease","Compliance audits should not cause headaches. Learn how building compliance programs and carrying compliance audits effectively using GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667086/Blog/Hero%20Images/blog-compliance.jpg","https://about.gitlab.com/blog/compliance-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to build a compliance program with ease\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Saumya Upadhyaya\"},{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-07-02\",\n      }",{"title":1563,"description":1564,"authors":1569,"heroImage":1565,"date":1571,"body":1572,"category":1249,"tags":1573},[1570,1454],"Saumya Upadhyaya","2020-07-02","The implimentation of a compliance program requires organizations to adopt processes that help comply with regulatory and legal requirements. GitLab makes it easy to wrestle the \"compliance beast\" but to understand what that really means it helps to take a look at this very complex and challenging area.\n\n## An effective compliance program: lots of moving parts\n\nCompliance processes are often costly, manual and cumbersome to implement and maintain. Even organizations that are advanced in compliance maturity still maintain compliance processes within spreadsheets, file storage systems (such as Google Drives or Dropbox) and emails, making wading through the documentation required to prove compliance extremely painful.\n\nFurther compounding this pain is the number of third party applications an organization uses to operate its business. The use of these tools and services add complexity because they’re all subject to the underlying policies and procedures the company has established. This means auditing not just your own organization’s processes, but those of your vendors.\n\nHowever, compliance is essential. With regulatory scrutiny being high, increasing cyber security breaches and the high costs of non compliance manifesting in the form of revenue loss, business disruptions, fines, damage to brand image, impacted stock prices and so on - the need for compliance is not lost on organizations. In fact, non compliance penalties [can be much lower](https://www.justice.gov/opa/pr/antitrust-division-announces-new-policy-incentivize-corporate-compliance) when an organization can demonstrate the presence of an effective compliance program.\n\n## Why is achieving an effective compliance program so difficult?\n\nIn spite of organizations acknowledging the importance of compliance, achieving an effective compliance program seems elusive.\n\nCurrently, there is a lot of administrative overhead associated with compliance. The task that gives most compliance professionals a headache is finding the documentation or evidence they need. With most organizations still using a combination of spreadsheets, drives and emails to manage their compliance programs and the added complexity of demonstrating compliance within their third-party tools or services, it is increasingly difficult for compliance teams to scale.\n\nIt can be even more daunting trying to keep track of the growing regulatory compliance requirements and internal controls to manage these requirements. In the cases where organizations have introduced additional Governance, Risk and Compliance (GRC) tools within their organizations, these tools are not integrated into their development and operational tools - thereby creating yet another compliance silo.\n\nDevelopment and operations teams perceive compliance-related activities as slowing down their velocity, creating an inherent friction with the compliance teams, thereby making compliance processes even slower and less effective.\n\n## Building your compliance program\n\nAny well defined compliance program requires internal controls that allow:\n\n1. Defining rules and policies aligned with your organizational or regulatory/legal requirements\n1. Generating and maintaining the evidence of policy adherence\n1. Enforcing the defined rules and policies\n1. Demonstrating compliance with easy-to-access and readable reports and evidence artifacts\n1. Ongoing risk assessments to detect and mitigate gaps in compliance\n\nAny compliance program that does not bring together all of these controls incurs the administrative overhead of maintenance. Organizations often run the risk of overspending on a disparate set of tools, creating data silos resulting in them being no better than when they started their compliance process.\n\n## GitLab makes compliance easy\n\nBeing a single application where developers, security and operations professionals congregate, GitLab is well positioned to automate your compliance processes to answer questions that may arise from your auditors or leadership teams.\n\n1. With [granular user roles and permissions](https://docs.gitlab.com/ee/user/permissions.html), GitLab allows you to enforce segregation of duties. You can easily define your organization’s policies regarding credentials, security scanning, and rules for approvers. Granular permission control also allows you to enforce approvers for determining what goes into production\n1. With [application security](/solutions/security-compliance/) being part of the pipeline, GitLab helps you to automate your information security compliance requirements\n1. GitLab helps you define [custom projects](https://docs.gitlab.com/ee/user/project/working_with_projects.html#project-templates) (such as HIPAA, SOX etc) to track adherence to various different compliance frameworks in a single place. Within the projects, GitLab issues and merge requests are also the central places to collaborate, maintain documents, track chain of custody and overrides, without maintaining these on disparate tools. Additionally, you can define a common set of policies to be applied to a set of projects labeled with a specific compliance framework (such as HIPAA, SOX etc)\n1. You can meet the traceability requirements for audits - such as user actions, permission changes, approval changes, logins, password changes and so on via [Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html)\n1. GitLab also provides a consolidated view of various compliance signals such as merge request approvals in the [compliance dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html). Going forward, this compliance dashboard aims to provide compliance insights in a consolidated view with all relevant signals such as segregation of duties, framework compliance, license compliance, pipeline and MR results. The compliance dashboard will continue to evolve to include more data to save compliance professionals time when managing their GitLab compliance posture.\n\nLearn more about our Compliance Solution [here](/solutions/compliance/).\n\n## What’s next\n\nOur [vision for Compliance Management](/direction/dev/#manage-1) is strong. Watch Matt Gonzales, Senior Product Manager for the compliance group, talk about our vision.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XFilPpXwVzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nConsider joining the [Compliance Special Interest Group](https://gitlab.com/gitlab-org/ux-research/-/issues/532) to help shape our direction for compliance management within GitLab.\n\n*Read more about compliance and GitLab:*\n\n[Compliance-as-code explained](/blog/get-started-compliance-as-code/)\n\n[How we chose our compliance framework](/blog/choosing-a-compliance-framework/)\n\n[Tracking agreements in GitLab just got easier](/blog/make-tracking-agreements-simple-compliance-dashboard/)\n\nCover image by joaosilas on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[851,9],{"slug":1575,"featured":6,"template":683},"compliance-made-easy","content:en-us:blog:compliance-made-easy.yml","Compliance Made Easy","en-us/blog/compliance-made-easy.yml","en-us/blog/compliance-made-easy",{"_path":1581,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1582,"content":1587,"config":1593,"_id":1595,"_type":13,"title":1596,"_source":15,"_file":1597,"_stem":1598,"_extension":18},"/en-us/blog/composition-analysis-14-deprecations-and-removals",{"title":1583,"description":1584,"ogTitle":1583,"ogDescription":1584,"noIndex":6,"ogImage":1055,"ogUrl":1585,"ogSiteName":670,"ogType":671,"canonicalUrls":1585,"schema":1586},"Secure Composition Analysis 14.0 deprecations and removals","A review of the deprecations and removals in 14.0 for the Secure Composition Analysis group.","https://about.gitlab.com/blog/composition-analysis-14-deprecations-and-removals","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure Composition Analysis 14.0 deprecations and removals\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n        \"datePublished\": \"2021-02-08\",\n      }",{"title":1583,"description":1584,"authors":1588,"heroImage":1055,"date":1590,"body":1591,"category":1353,"tags":1592},[1589],"Nicole Schwartz","2021-02-08","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nDuring the 14.0 release there will be both deprecations and removals by the [Composition Analysis group](https://about.gitlab.com/handbook/product/categories/#composition-analysis-group), a member of the [Secure stage](https://about.gitlab.com/direction/secure/), which is responsible for both the [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) and [License Compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html) features. Please check if you're impacted by these changes and take appropriate action.\n\n## Removals for License Compliance\n\nIn 13.0 we deprecated the License-Management CI template, and renamed it License-Scanning. We have been providing backwards compatibility by warning users of the old template to switch. In 14.0 we will remove the License-Management CI template. You can read more about this change in [issue #216261](https://gitlab.com/gitlab-org/gitlab/-/issues/216261).\n\n## Deprecations for Dependency Scanning\n\nIf you only use a subset of our [Dependency Scanning analyzers](/blog/try-dependency-scanning/), you will need to change to using `DS_EXCLUDED_ANALYZERS` in 14.0 when it becomes available and stop using `DS_DEFAULT_ANALYZERS`. `DS_EXCLUDED_ANALYZERS` specifically asks what analyzers you wish to skip, rather than the current CI/CD variable `DS_DEFAULT_ANALYZERS` which you must list every analyzer you want to run. `DS_DEFAULT_ANALYZERS` did not automatically receive new analyzers added to GitLab, and required users to take action each time an analyzer was made available. You can read more about this change in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/287691).\n\n",[9,704],{"slug":1594,"featured":6,"template":683},"composition-analysis-14-deprecations-and-removals","content:en-us:blog:composition-analysis-14-deprecations-and-removals.yml","Composition Analysis 14 Deprecations And Removals","en-us/blog/composition-analysis-14-deprecations-and-removals.yml","en-us/blog/composition-analysis-14-deprecations-and-removals",{"_path":1600,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1601,"content":1606,"config":1611,"_id":1613,"_type":13,"title":1614,"_source":15,"_file":1615,"_stem":1616,"_extension":18},"/en-us/blog/composition-analysis-group-deprecations",{"title":1602,"description":1603,"ogTitle":1602,"ogDescription":1603,"noIndex":6,"ogImage":1055,"ogUrl":1604,"ogSiteName":670,"ogType":671,"canonicalUrls":1604,"schema":1605},"Announcing 14.6 Composition Analysis deprecations and behavior changes","Upcoming deprecations and behavior changes for the Dependency Scanning and License Compliance features.","https://about.gitlab.com/blog/composition-analysis-group-deprecations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Announcing 14.6 Composition Analysis deprecations and behavior changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n        \"datePublished\": \"2021-12-13\",\n      }",{"title":1602,"description":1603,"authors":1607,"heroImage":1055,"date":1608,"body":1609,"category":678,"tags":1610},[1589],"2021-12-13","\n\nThe Composition Analysis group would like to announce two deprecations and one change in a variable's behavior with the 14.6 and December 22, 2021, release.\n\n- Variable DS_EXCLUDED_PATHS behavior changed so that it now pre-filters.\n- Dependency Scanning is deprecating bundler-audit.\n- License Compliance is deprecating “approved” and “blacklisted” from the `managed_licenses` API.\n\n## Variable DS_EXCLUDED_PATHS behavior now pre-filters\n\nFor users of the Dependency Scanning variable DS_EXCLUDED_PATHS, it will now pre-filter. Dependency Scanning now considers DS_EXCLUDED_PATHS when searching for supported projects and will pre-filter out those that match. Pre-filtering prevents the analyzer from logging warnings or failing when processing dependency files that have been explicitly excluded using DS_EXCLUDED_PATHS. This enables users to skip dependency files and build files if desired, and can lead to a performance increase in some cases. \n\nThis change was made December 2, 2021, for Gemnasium; December 6, 2021, for gemnasium-python; and December 7, 2021, for gemnasium-maven. This change applies to all versions as the change is backported. \n\nYou should not need to take any action. However, if you were expecting this post-filtering behavior, and wrote custom tooling to handle that, you will need to adjust your custom tools. For example, before this change, you may have needed to manually, or using a script, delete specific files to avoid a warning or error occurring.\n\nThe previous behavior was causing failures and unexpected errors for users and, after discussions, we found that this, pre-filter as opposed to post filter, was the more expected and desired behavior.\n\n[Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/292457)\n\n[Configuration Documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-dependency-scanning) \n\n## Deprecation of bundler-audit Dependency Scanning tool\n\nAs of 14.6, bundler-audit is being deprecated from Dependency Scanning. It will continue to be in our CI/CD template while deprecated. We are removing bundler-audit from Dependency Scanning on May 22, 2022, in 15.0. After this removal Ruby scanning functionality will not be affected as it is still being covered by Gemnasium.\n\nIf you have explicitly excluded bundler-audit using DS_EXCLUDED_ANALYZERS, you will need to clean up (remove the reference) in 15.0. If you have customized your pipeline's Dependency Scanning configuration – for example, to edit the `bundler-audit-dependency_scanning` job – you will want to switch to gemnasium-dependency_scanning before removal in 15.0, to prevent your pipeline from failing. If you have not used the DS_EXCLUDED_ANALYZERS to reference bundler-audit, or customized your template specifically for bundler-audit, you will not need to take action.\n\n[Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/289832) \n\nSee all upcoming deprecations on our [Deprecation Page](https://docs.gitlab.com/ee/update/deprecations) \n\n## Deprecate legacy approval status names from the License Compliance API\n\nWe deprecated legacy names for approval status of license policy (blacklisted, approved) in the `managed_licenses` API but they are still used in our API queries and responses. They will be removed in 15.0. \n\nIf you are using our License Compliance API, you should stop using the “approved” and “blacklisted” query parameters. They are now “allowed” and “denied\". In 15.0, the responses will also stop using “approved” and “blacklisted”. You will want to adjust any of your custom tools to be able to use the old and new values so they do not break with the 15.0 release. \n\n[Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/335707) \n\nSee all upcoming deprecations on our [Deprecation Page](https://docs.gitlab.com/ee/update/deprecations)\n",[9,893],{"slug":1612,"featured":6,"template":683},"composition-analysis-group-deprecations","content:en-us:blog:composition-analysis-group-deprecations.yml","Composition Analysis Group Deprecations","en-us/blog/composition-analysis-group-deprecations.yml","en-us/blog/composition-analysis-group-deprecations",{"_path":1618,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1619,"content":1625,"config":1631,"_id":1633,"_type":13,"title":1634,"_source":15,"_file":1635,"_stem":1636,"_extension":18},"/en-us/blog/conan-c-cpp-package-management-integration",{"title":1620,"description":1621,"ogTitle":1620,"ogDescription":1621,"noIndex":6,"ogImage":1622,"ogUrl":1623,"ogSiteName":670,"ogType":671,"canonicalUrls":1623,"schema":1624},"Modern C and C++: How Conan integration works in GitLab","Conan is a leading C and C++ package manager and it is now available in GitLab. Store and share packages easily with your teams or publicly.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/conan-c-cpp-package-management-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Modern C and C++: How Conan integration works in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jordi Mon\"}],\n        \"datePublished\": \"2020-03-31\",\n      }",{"title":1620,"description":1621,"authors":1626,"heroImage":1622,"date":1628,"body":1629,"category":849,"tags":1630},[1627],"Jordi Mon","2020-03-31","\n\nAs a single application for all the software development and delivery lifecycle, GitLab strives to support all the different software workflows and pipelines. Regardless of how complex this cycle might be (I’m looking at you C++), what we want to do is soothe these pains for C and C++ GitLab users. Following up on this metaphor, as doctors we would like to listen to the patient first: It all started with our community explaining their symptoms and chipping in the first ideas [here](https://gitlab.com/gitlab-org/gitlab-foss/issues/54747). This became even more relevant for GitLab when clients in C++ reliant industries like finance, robotics or embedded software added their interest to supporting package management for C++.\n\n### Conan is now available on GitLab\n\nThe C and C++ ecosystems have a ton of legacy tooling. It is what it is: they’ve been around for a long time and the community is, in a way, very DIY-driven. For example, many C++ libraries are advertised as “Zero deps inside.” This badge is intended as a sign of quality, and is even a bit of a status symbol for the devs and maintainers. That's fine for C/C++ developer but what about the users of such libs? Regardless of the actual quality of the lib’s code, if you wanted to use any of them, you’d better have a local, updated copy of them in a Git submodule. This is especially relevant for head-only monsters like Boost, the most popular set of libs in C++. In other words, in order to make use of them (that’s why they were created in the first place, I guess), you basically have to download the [source code](/solutions/source-code-management/), build it yourself (good luck with that), compile it and include the resulting binary in your project. This process can be time consuming and, if build processes are not well documented or supported, it can be exasperating. All of this can become a real nightmare if transitive dependencies are present, or if different [version control systems](/topics/version-control/) have been used. It's also tricky when deciding upon static or dynamic binaries, static or dynamic linking, single or multi-threaded, 32-bit or 64-bit…\n\n### How to build C and C++ packages in GitLab the Conan way\n\nThe GitLab Conan integration allows Conan users to set GitLab as the remote registry for their packages. Users will be able to set the remote and upload and install packages from GitLab’s registry. Think of it this way: you still use the same CLI to work with your Conan packages, but GitLab is on the receiving end. In doing so, GitLab creates the unique opportunity to have the code and package generated from the code living in the same place, freeing users from having to manage multiple services to store packages and code separately and still have them working together. This allows users to share private packages within an organization that is already using GitLab, publish public packages for general or open source use, and will open up many possibilities in utilizing GitLab’s CI pipelines to build and consume these packages automatically.\n\nCheck out a full demo:\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/2VVmrKNpC_0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n or a speedrun of Conan performed by the team in charge of the integration:\n\n \u003C!-- blank line -->\n \u003Cfigure class=\"video_container\">\n   \u003Ciframe src=\"https://www.youtube.com/embed/7NYgJWg-w5w\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n \u003C/figure>\n \u003C!-- blank line -->\n\nIf you need more help you can always refer to the [Conan docs](https://docs.conan.io/en/latest/).\n\n### The future of C and C++ in GitLab: Game development workflows!\n\nWhat’s coming next? In tradition with GitLab’s value of iteration, the initial release of Conan is a bare-bones API that allows you to publish and consume packages within GitLab. Next up will be a UI that displays much of the commonly referenced metadata for a given package, pre-written CI templates for automatic package publishing and consuming, less strict package naming conventions with remotes scoped to the group and project level within GitLab, and the list goes on.\n\n* [Conan Repository User Interface](https://gitlab.com/gitlab-org/gitlab/issues/33892)\n* [Project and Group level support for Conan Repository](https://gitlab.com/gitlab-org/gitlab/issues/11679)\n\nIf you are interested in package management at large, find a list of publicly available issues about the topic [here](https://gitlab.com/gitlab-org/gitlab/issues?label_name=Package+Repositories). Also, please note that if game development is your interest, large file support, partial clone and many other features that make game development possible with Git, will soon be available in GitLab. All the heavy lifting required for those massive binaries, engines, and animations will feel like feathers when we release those features. Stay tuned to know more about it in our newsletter.\n\n",[9,230,1187,894],{"slug":1632,"featured":6,"template":683},"conan-c-cpp-package-management-integration","content:en-us:blog:conan-c-cpp-package-management-integration.yml","Conan C Cpp Package Management Integration","en-us/blog/conan-c-cpp-package-management-integration.yml","en-us/blog/conan-c-cpp-package-management-integration",{"_path":1638,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1639,"content":1645,"config":1652,"_id":1654,"_type":13,"title":1655,"_source":15,"_file":1656,"_stem":1657,"_extension":18},"/en-us/blog/configure-post",{"title":1640,"description":1641,"ogTitle":1640,"ogDescription":1641,"noIndex":6,"ogImage":1642,"ogUrl":1643,"ogSiteName":670,"ogType":671,"canonicalUrls":1643,"schema":1644},"GitLab restructures to boost cross-functional collaboration","Implementing a new structure sounds like a big change, but our Configure group is here to give you the scoop.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678839/Blog/Hero%20Images/inside-look-at-new-cross-functional-teams-at-gitlab.jpg","https://about.gitlab.com/blog/configure-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We restructured to allow better cross-functional collaboration — here's how it's going.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2018-12-13\",\n      }",{"title":1646,"description":1641,"authors":1647,"heroImage":1642,"date":1649,"body":1650,"category":849,"tags":1651},"We restructured to allow better cross-functional collaboration — here's how it's going.",[1648],"Emily von Hoffmann","2018-12-13","\nHello world, meet the GitLab Configure group! They’re the folks hard at work improving [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), the [Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/), and all the related applications on GitLab. They, like the rest of the GitLab engineering function, recently changed how they work together when we split up into devops stage groups according to [product area](/handbook/product/categories/). Each group contains a product manager, UX designer, several engineers, and other contributors. They still belong to [teams](/company/team/structure/#team-and-team-members) with others usually in their same role, but they work together as a [group dedicated to a stage](/company/team/structure/#stage-groups) of the product lifecycle. \n\n![meet the configure group](https://about.gitlab.com/images/blogimages/configure-team.jpg){: .shadow.medium.center}\n\nSo far, Configure group members say this has helped them stay focused and connected. Staff UX Designer Taurie Davis explains that while she used to have to switch gears and spend time getting caught up on different product areas, she can now hone in on finding solutions to familiar problems. Having a stable group of collaborators also promotes shared learning, because they’re working together on the same issues at the same time. Product Manager Daniel Gruesso also sees benefits in having a dedicated set of people for each product area; they enjoy more latitude and no longer face as much competition for getting their work prioritized. These are all benefits of [stable counterparts](/handbook/leadership/#stable-counterparts), or people in different functions, departments, or teams who routinely work together, easing communication to avoid conflict and the [downsides of a matrix organization](/handbook/leadership/#no-matrix-organization).\n\nSome of the challenges that drove this change have been echoed in our user research, with cross-group communication a common and recurring roadblock. In our [2018 Global Developer Report](/developer-survey/previous/2018/), a quarter of engineers indicated that they feel siloed, and lack visibility into what their colleagues in operations, product, and security are working on. \n\nThis was reinforced in recent interviews by our UX research team, where many [developers](https://drive.google.com/file/d/1EVrjVcgIBbuNf4Gwenajsiy6Wv9HsTJw/view) we spoke with said that they’re frustrated by changing requirements and scope creep, and pinpointed poor communication with and empathy for other teams as the cause. Their colleagues in [operations roles](https://drive.google.com/file/d/1A5mSNoPJydjcWKE4rdO2287sjnABxGDA/view) face a similar challenge in convincing others to invest cycles in proactive work that can save them time and stress in the future. Although implementing stable groups may seem like a big change, we’ve seen positive results and hope that sharing our experience may help others take the plunge. \n\nI recently caught up with a few members of the Configure group, read on for their perspectives on how it’s been going.\n\n### Can you each introduce yourself and explain your role?\n\n**Dylan:** Hi I'm [Dylan](/company/team/#DylanGriffith). I'm the [Backend Engineering Manager](https://handbook.gitlab.com/job-families/engineering/backend-engineer/#engineering-manager/) for the [Configure](/handbook/product/categories/) group.\n\n**Thong:** I’m new here! I’m [Thong](/company/team/#thongkuah) and I'm a senior [backend engineer](https://handbook.gitlab.com/job-families/engineering/backend-engineer/). \n\n**Mayra:** I'm [Mayra](/company/team/#may_cabrera) and I'm a [backend engineer](https://handbook.gitlab.com/job-families/engineering/backend-engineer/) for the Configure group.\n\n**Taurie:** I'm [Taurie](/company/team/#tauried), the UX designer for the Configure group. I work closely with product and engineering to help shape the overall user experience of our products.\n\n**Daniel:** I'm [Daniel](/company/team/#danielgruesso), the [Product Manager](https://handbook.gitlab.com/job-families/product/product-manager/) for the Configure group. In short I have to make sure that the features we ship are aligned to our vision; this involves interacting with everyone from customers to the CEO. Working together with engineering, UX, and leadership we make our vision a reality.\n\n### In general, how do you think it's going so far?\n\n**Dylan:** So far the stable devops stage group is working well. I believe that backend teams already were well focused on specific product areas, but I think the addition of focused UX and frontend engineers on our product area helps in a few ways. First, we know who to talk to about UX decisions, and the UX designer and frontend engineers have good context across the feature set and often have good insights based on this context. Backend engineers also get to collaborate and form better working relationships with UX and frontend, and as a consequence we communicate more effectively in general.\n\n### What are some of the big differences that arise from working with people in different roles, versus working more with people who share your background? \n\n**Thong:** Key for me is the different strengths and perspectives that we all bring into the group. I'm pleasantly surprised how well our strengths overlap and support the group. Because we come from different perspectives, I feel we can often challenge each other constructively and check that we are heading in the right direction with respect to achieving the best value for the product.\nThe challenges I have seen in the past would be establishing a common understanding of the group's goals, which sometimes might not be exactly aligned with each department's goals.\n\n**Mayra:** Thong’s answer is a really good one. I'm also quite impressed by how our strengths bolster the group productivity.\n\n**Taurie:** We bring different perspectives to the table which can only improve the product in the end. It also greatly improves communication and allows us to work together instead of in progression. I, personally, have also learned a ton by working so closely with both product and engineering on a daily basis.\n\n**Daniel:** I greatly benefit from learning the technical aspects of our work; if I only interacted with other product folks I would surely not learn as much. This is by far the job where I've learned the most in the shortest amount of time. I love that.\n\n### How has the new structure impacted your day to day? \n\n**Mayra:** For me, it has had a positive impact because now I'm focused on developing particular features for certain areas of GitLab, like the Kubernetes integration and Auto DevOps.\n\n**Dylan:** We have deeper conversations with UX designers and frontend engineers as they understand our product set well. Ownership from the UX designer means that as an engineer I feel less stressed about resolving UX decisions or making issues for UX issues, as I can see that Taurie will often take responsibility for seeing this through.\n\n### How have you tried to bond as a new group? \n\n**Dylan:** We are bonding quite well. We started with daily standups and worked our way down to twice weekly. The daily standup really accelerated the bonding between group members and has resulted in fairly healthy collaboration and high levels of trust between group members. We've also done 1 retro as a full group, which I believe was a more comfortable and open environment as a consequence of us bonding for some time before hand.\n\n**Mayra:** At the last GitLab [Summit](/events/gitlab-contribute/), we had our first on site dinner; sadly, Thong was not able to join us, so we'll need to update this picture on the next summit!\n\n![team dinner](https://about.gitlab.com/images/blogimages/configure-team-dinner.png){: .shadow.medium.center}\n\n**Taurie:** We also have [coffee break calls](/culture/all-remote/#coffee-break-calls) regularly with different group members as a way to discuss things outside of work and continue to strengthen the connection between group members. Our monthly group retrospectives are a great way to discuss what is working well within our group, what has been on our minds, and what we can improve for greater collaborations and results.\n\n**Daniel:** I always try to start calls with a personal touch, no matter how small, I've found it sets people at ease. We plan synchronously and clear up any doubts on the work before starting. Once we're aligned we mostly catch up asynchronously.\n\n### Are there any previous problems, delays, or frustrations that have been resolved or prevented in the new structure?\n\n**Dylan:** Difficult to say, but at a high level we had many discussions before forming this group along the lines of engineers waiting for issues to be labeled \"UX Ready\" before starting work on any feature. But now as a group we've come to realize that we're all involved from the beginning to the end, and engineers are responsible for ensuring the UX makes sense and the UX designer is also responsible for ensuring the final product makes sense. We also regularly have UI contributions from Taurie which saves the round trip of commenting on the MR and waiting for the engineer to make the changes.\n\n**Taurie:** Shifting between multiple different product areas made it much more difficult to learn and keep up to date with the more technical areas of our product such as Kubernetes, and Auto DevOps. Being integrated into a group who is constantly working on these features means I have more domain knowledge and can more confidently answer questions related to the user experience of our area.\n\n### What are you most excited to tackle together, and what can we look forward to seeing from the group?\n\n**Dylan:** \nWe're focusing on making Auto DevOps clearer to users; making more decisions based on research rather than relying on industry trends; building a large and engaged user base for Auto DevOps that helps guide us to make better decisions by collaborating on issues; and improving the code architecture so that frontend engineers are more empowered to build better UX without the need to involve backend engineers (eg. more user experience handled in pure frontend Javascript code).\n\n**Taurie:** I am excited to see the group continue to grow and tackle issues that improve the Auto DevOps experience so that it is widely used among GitLab users.\n\n**Daniel:** I am definitely excited to participate in some of our big initiatives like [serverless](/topics/serverless/) and PaaS. In the near future you can look forward to group-level Kubernetes clusters as well as some great Auto DevOps improvements like the ability to initialize and migrate databases.\n\n### Anything else you want to share?\n\n**Daniel:** We're always looking for [engineers](/jobs/). Familiarity with Kubernetes and expertise with ruby will help you land an interview.\n\n**Dylan:** Try out [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) and don't be afraid to create issues for us if you run into trouble. We love hearing from our users!\n\nCover image by [rawpixel](https://unsplash.com/@rawpixel) on [Unsplash](https://unsplash.com/).\n{: .note}\n",[9,829],{"slug":1653,"featured":6,"template":683},"configure-post","content:en-us:blog:configure-post.yml","Configure Post","en-us/blog/configure-post.yml","en-us/blog/configure-post",{"_path":1659,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1660,"content":1666,"config":1673,"_id":1675,"_type":13,"title":1676,"_source":15,"_file":1677,"_stem":1678,"_extension":18},"/en-us/blog/continuously-improving-ci-lovability",{"title":1661,"description":1662,"ogTitle":1661,"ogDescription":1662,"noIndex":6,"ogImage":1663,"ogUrl":1664,"ogSiteName":670,"ogType":671,"canonicalUrls":1664,"schema":1665},"Continuously Improving CI to Lovable...again!","A transparent commentary on our Verify:Continuous Integration offering, covering how the landscape has changed and the product strategy that will carry us to Lovable.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681907/Blog/Hero%20Images/CI-lovable.jpg","https://about.gitlab.com/blog/continuously-improving-ci-lovability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Continuously Improving CI to Lovable...again!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jackie Porter\"}],\n        \"datePublished\": \"2021-02-22\",\n      }",{"title":1661,"description":1662,"authors":1667,"heroImage":1663,"date":1669,"body":1670,"category":1353,"tags":1671},[1668],"Jackie Porter","2021-02-22","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n## What is it to be loved?\n\nAt GitLab, we use a [maturity](https://about.gitlab.com/direction/maturity/) rating to signal the readiness of a product category's capabilities for use by customers. The rating is evaluated by a scoring methodology called [Category Maturity Scorecard](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/). In 2017, GitLab declared Continuous Integration \"Lovable\" after delivering significant feature functionality and becoming a [CI leader](https://about.gitlab.com/blog/gitlab-leader-continuous-integration-forrester-wave/). \n\nIn the [Verify Stage](/direction/ops/#verify), we have been able to maintain a lead against our competition by adding advanced feature functionality, relying on our [Single DevOps Platform](/solutions/devops-platform/), and executing on a strong vision. As the tides have been changing and as a practitioner of transparency, we [articulate when we change our mind](https://handbook.gitlab.com/handbook/values/#articulate-when-you-change-your-mind), especially when we learn new facts. \n\nIn a recent [opportunity canvas](https://about.gitlab.com/handbook/product/product-processes/#opportunity-canvas), we explored the adoption hurdles that prevent Source Code Management Enterprise users from adopting Verify functionality. We explored all potential features as candidates for adoption across Verify categories - CI, Testing, Pipeline Authoring, and Runner. \n\nIn this blog we will dive into they key takeways that help answer the question of what is it to be loved and how the expectations have shifted over time, and what the path to Lovable maturity looks like for Verify:Continuous Integration! \n\n## Key learnings from the research \n\nWe spent 6 weeks interviewing and collecting insights from across our customers to learn about their adoption journey with GitLab. These were the main learnings informing our approach. \n\n### GitLab is loved by developers \n\nAcross each organization, we learned that the experience for the developer was resoundingly positive and the leaders at these organizations appreciated this. The happiness of their engineering teams was and will continue to be extremely important to them, but the fact that GitLab was a significant contributing factor in developer job satisfaction was a reward on its own. \n\n### GitLab has some challenges with performance of minimal viable changes that are expected to work at a higher finish\n\nEnterprises are often larger, mature organizations shipping their own enterprise class solution. When faced with serving their needs, we learned they have a low tolerance for experimentation and a high expectation for polished features. This means a Premium or Ultimate tier offering needs to completely solve the problem and delight the user, not partially solve the problem. With our MVC and iterative methodology, we have historically shipped first and second iterations of features that may have solved the needs for individuals or small teams in small or medium-sized businesses. Although, with the expanding budgets as well as focus on developer productivity, organizations are looking for tools that will solve problems the best way possible, as comprehensively as possible. \n\n### GitLab's visibility into jobs at scale is painful, which also makes the management of diagnosing problems even more challenging \n\nWe learned a common question that organizations are unable to answer is around trends for passed and failed jobs. This is particularly relevant for projects that have over 100,000 pipelines and 300 jobs in single pipeline. Today in GitLab, there is no view where they can answer a question like how many times a particular job has failed; is it failing more often lately; does it fail at the same time each day; and other job behaviors of interest. Even filtering the job view is not possible today. So, for an organization that is looking to use GitLab at scale, it could be really challenging to easily triage and diagnose problems with their pipelines. \n\n## Path to Lovable \n\nIn the [Verify 1H Direction](/direction/ops/#verify), we identify a key piece of our strategy is to future-proof ourselves by investing in the core areas driving CI today. These top focuses include: \n\n1. [Artifacts](https://gitlab.com/groups/gitlab-org/-/epics/5125) - these are essential assets for your jobs and pipelines, getting these performant will help users take advantage of features like parent-child pipelines. \n1. [Variables](https://gitlab.com/groups/gitlab-org/-/epics/5124) - permissions and behaviors in pipelines are controlled by variables. Enabling these to work as designed will unlock the flexibility users have been looking for in their pipelines. \n\nBe sure to stay up to date on the [What's Next & Why Section](https://about.gitlab.com/direction/verify/continuous_integration/#whats-next--why) of Continuous Integration's Direction page, which will link to specific scheduled issues. \n\nBeyond this push for usability, in the 2H, we plan to tackle the challenges of visibility in diagnosing jobs via [gitlab&5022](https://gitlab.com/groups/gitlab-org/-/epics/5022) and piplelines activities in [gitlab&5071](https://gitlab.com/groups/gitlab-org/-/epics/5071), which you can see more information about in the [Maturity Plan](https://about.gitlab.com/direction/verify/continuous_integration/#maturity-plan) for Continuous Integration.\n",[1396,1672,9],"UX",{"slug":1674,"featured":6,"template":683},"continuously-improving-ci-lovability","content:en-us:blog:continuously-improving-ci-lovability.yml","Continuously Improving Ci Lovability","en-us/blog/continuously-improving-ci-lovability.yml","en-us/blog/continuously-improving-ci-lovability",{"_path":1680,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1681,"content":1687,"config":1692,"_id":1694,"_type":13,"title":1695,"_source":15,"_file":1696,"_stem":1697,"_extension":18},"/en-us/blog/contribute-wrap-up",{"title":1682,"description":1683,"ogTitle":1682,"ogDescription":1683,"noIndex":6,"ogImage":1684,"ogUrl":1685,"ogSiteName":670,"ogType":671,"canonicalUrls":1685,"schema":1686},"What we learned at Contribute 2019","Community is everything, all remote makes contribution possible, CMO Todd Barr plays a mean trumpet, and more takeaways from Contribute 2019.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670139/Blog/Hero%20Images/gitlab-contribute-team-photo.png","https://about.gitlab.com/blog/contribute-wrap-up","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we learned at Contribute 2019\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-06-04\",\n      }",{"title":1682,"description":1683,"authors":1688,"heroImage":1684,"date":1689,"body":1690,"category":996,"tags":1691},[1246,675],"2019-06-04","\n\n“Community is the best part of GitLab.”\n\nThat message, from the [keynote presentation](https://youtu.be/kDfHy7cv96M) during [Contribute 2019 in New Orleans](/events/gitlab-contribute/), sums up the spirit of GitLab’s seventh all-company gathering. Sure CMO (and MC) [Todd Barr](/company/team/#tbarr) added his trumpet to a NOLA classic, \"When the Saints Go Marching In,\" while others shared potentially embarrassing photos and anecdotes from the past. Contribute newbies, who represented more than half of the over 500 attendees, got advice on how to make the most of the unique event, and CEO [Sid Sijbrandij](/company/team/#sytses) made a clear and compelling case for remote work.\n\nBut what stood out most were the ways “community” plays such a vital role at GitLab. “This is our first Contribute,” Sid said. “We changed the name to remind everyone of our mission, that [everyone can contribute](/company/mission/#mission).” In fact, in the product release before Contribute, contributions from the community to GitLab reached an all-time high of 195, Sid said. Because the company is all remote, “everyone can contribute to GitLab on equal footing.”\n\nIn the spirit of community contributions, we asked GitLabbers to share their top takeaways, advice, and feel-good moments from Contribute.\n\n## Your best self\n\n“I’m so pumped for where GitLab is heading,” said strategic account leader [Adam Olson](/company/team/#adamsolson). “Contribute has inspired me to be better GitLabber. (I want to) win more customers while learning more from others.”\n\n## Network like it matters\n\n[Heather Simpson](/company/team/#Heatherswall), senior external communications analyst, got more out of Contribute than expected. “I think because the main focus of Contribute was to spend time getting to know our team members and having fun, the quantity and **quality** of connections I made far exceeded any I'd made at networking or \"team building\" conferences I'd attended with companies in the past.”\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Our \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> CEO put forth a challenge to make our product better while we’re down in \u003Ca href=\"https://twitter.com/hashtag/NOLA?src=hash&ref_src=twsrc%5Etfw\">#NOLA\u003C/a> at \u003Ca href=\"https://twitter.com/hashtag/GitLabContribute?src=hash&ref_src=twsrc%5Etfw\">#GitLabContribute\u003C/a> and teams got to work and made several iterative improvements, so \u003Ca href=\"https://twitter.com/sytses?ref_src=twsrc%5Etfw\">@sytses\u003C/a> made good on his word and donned this amazing costume (his wife too!) So good. \u003Ca href=\"https://t.co/8nfQCt0NV0\">pic.twitter.com/8nfQCt0NV0\u003C/a>\u003C/p>— Heather Simpson 🌈🍃 (@heatherswall) \u003Ca href=\"https://twitter.com/heatherswall/status/1128129734934704129?ref_src=twsrc%5Etfw\">May 14, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Spread the wealth\n\n“This was most definitely the best Contribute ever,” said GitLab's unofficial bacon ambassador [Richard “Reb” Baum](/company/team/#therebbie) (who is also a solutions architect). “Focusing on building relationships allowed us to spread the culture and feel of the company to the large number of new people who have joined since the previous event. As an all-remote company, this is critical to our ongoing success.”\n\n## Continued inspiration\n\n“As an early employee here at GitLab and my sixth [Summit](/company/culture/contribute/previous/), I have never felt more inspired after this week in New Orleans,” said [Philip Camillo](/company/team/#pmanjr311), enterprise account executive. “Working remotely, it’s hard to contextualize hiring 10-12 people a week, and it only hit home when I first walked into the opening keynote. Seeing over 500 people in the main room simply left me speechless.\n\n“Leaving Contribute, I’m inspired by all the team members who received awards and all the people who have helped build the product over the years, as well as new team members making an impact immediately by just jumping in.\n\n“Imagine what we will create if we all work towards generating as much value as possible and making everyone around us inspired. Meeting everyone this last week also made me realize that people see you, and the hard work doesn’t go unnoticed. Working remotely, it can be a bit more difficult to see the direct impact you’re making, and the personal brand you’re building with your colleagues.”\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">A full house of GitLabbers celebrating and gathering around the notion that Everyone Can Contribute \u003Ca href=\"https://twitter.com/hashtag/GitLabContribute?src=hash&ref_src=twsrc%5Etfw\">#GitLabContribute\u003C/a> \u003Ca href=\"https://t.co/dWHiSPZGtV\">pic.twitter.com/dWHiSPZGtV\u003C/a>\u003C/p>— John Northrup (@northrup) \u003Ca href=\"https://twitter.com/northrup/status/1126498724518268929?ref_src=twsrc%5Etfw\">May 9, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n## Decisions at the speed of light\n\n“I took a lot of notes about the keynote but the thing that really stuck out to me was how Sid emphasized speed of decision making,” said [Emilie Schario](https://gitlab.com/emilie), data engineer, analytics. “That was really a lightbulb moment for me.”\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">My awesome teammate \u003Ca href=\"https://twitter.com/rspaik?ref_src=twsrc%5Etfw\">@rspaik\u003C/a> kicking off day two. Amazing stat he shared: 13.5% of merged MRs to \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> come from our community. \u003Ca href=\"https://twitter.com/hashtag/GitLabContribute?src=hash&ref_src=twsrc%5Etfw\">#GitLabContribute\u003C/a> \u003Ca href=\"https://t.co/1CUcyFF70y\">pic.twitter.com/1CUcyFF70y\u003C/a>\u003C/p>— John Coghlan (@john_cogs) \u003Ca href=\"https://twitter.com/john_cogs/status/1126853746754039809?ref_src=twsrc%5Etfw\">May 10, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nYou can check out the rest of the highlights from Contribute below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xdtPNXtkBhE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n",[266,9,680,998],{"slug":1693,"featured":6,"template":683},"contribute-wrap-up","content:en-us:blog:contribute-wrap-up.yml","Contribute Wrap Up","en-us/blog/contribute-wrap-up.yml","en-us/blog/contribute-wrap-up",{"_path":1699,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1700,"content":1706,"config":1713,"_id":1715,"_type":13,"title":1716,"_source":15,"_file":1717,"_stem":1718,"_extension":18},"/en-us/blog/coordinating-documentation-projects-gitlab",{"title":1701,"description":1702,"ogTitle":1701,"ogDescription":1702,"noIndex":6,"ogImage":1703,"ogUrl":1704,"ogSiteName":670,"ogType":671,"canonicalUrls":1704,"schema":1705},"Coordinating major documentation projects with GitLab","Members of The Good Docs Project explain how to plan, coordinate, and release major documentation projects using GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669791/Blog/Hero%20Images/abstractprocess.png","https://about.gitlab.com/blog/coordinating-documentation-projects-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Coordinating major documentation projects with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alyssa Rock\"},{\"@type\":\"Person\",\"name\":\"Aaron Peters, Member, Good Docs Project\"}],\n        \"datePublished\": \"2023-08-24\",\n      }",{"title":1701,"description":1702,"authors":1707,"heroImage":1703,"date":1710,"body":1711,"category":827,"tags":1712},[1708,1709],"Alyssa Rock","Aaron Peters, Member, Good Docs Project","2023-08-24","\n[The Good Docs Project](https://thegooddocsproject.dev/) recently achieved a significant milestone: releasing [version v1.0.0 of our project](https://gitlab.com/tgdp/templates/-/releases/v1.0.0). It was an exciting moment for [our community of contributors](https://go.gitlab.com/16yEa3) dedicated to improving the quality of software documentation by sharing best practices — the first time we felt confident putting our production-ready documentation templates into the world for other software projects to review, use, and help us improve.\n\nOrganizing and executing a release of this magnitude requires extensive planning and sophisticated project management tools. Luckily, our community uses GitLab, so we had everything we needed at our disposal. \n\nIn this article, we'll explain how we used GitLab to meet our goal of bringing Version 1.0 (codenamed \"Capilano\") to the world. Our release process consists of four general phases:\n* [Scheduling](#scheduling-a-release)\n* [Planning](#planning-a-release)\n* [Tracking](#tracking-a-release)\n* [Releasing](#release-day)\n\nWe'll share how we use GitLab in each of those phases to achieve a successful project release.\n\n## Scheduling a release\n[The Good Docs Project](https://about.gitlab.com/blog/meet-partner-the-good-docs-project/) releases template updates twice a year: on June 15 and December 15. Each of our releases receives both a number and a codename in honor of a famous bridge (because we're \"bridging the documentation gap for our users\"). Last December, for example, we issued [Version 0.3.0, codenamed \"Brooklyn Bridge\"](https://thegooddocsproject.dev/blog/template-release-0.3.0-using-our-own-templates/) release. In June, we finished [Version 1.0.0, which was codenamed \"Capilano\"](https://gitlab.com/tgdp/templates/-/releases/v1.0.0) for [a bridge in Canada](https://en.wikipedia.org/wiki/Capilano_Suspension_Bridge)). And now we're starting work on the [Dragon](https://gitlab.com/groups/tgdp/-/milestones/4) release, which gets its name from [a bridge on the River Han in Vietnam](https://en.wikipedia.org/wiki/Dragon_Bridge_(Da_Nang)).\n\n![The Good Docs Project Release Process](https://about.gitlab.com/images/blogimages/tgdp-release-cycle.jpg){: .shadow}\n\nOur release schedule prioritizes *work time* over *work scope*. We set goals we wish to accomplish with every release, then use the release deadline as a motivational tool to get projects done. However, we [don't delay releases](https://handbook.gitlab.com/teamops/measurement-clarity/#prioritize-due-dates-over-scope) for a particular release initiative per se. Instead, we try to accurately scope and track our release initiatives to ensure they complete in time for their desired release.\n\n## Planning a release\nFor the first month of our six-month release cycle, each of The Good Docs Project's working groups or teams determines initiatives for the cycle. They usually hold an initial brainstorming session, which involves using a synchronous collaboration tool (like Miro) to determine which ideas to include as official goals for the release. But after confirming and committing what we want to do with each release, we migrate all those objectives to GitLab, where we communicate them to the rest of the community. That process generally looks like this:\n* Open an issue in a release's respective repository and we tag it with the milestone for that release\n* Attach [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to indicate which working group is assigned to that task\n* Assign an initial [health status](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#health-status) of \"On track\"\n* Assign the issue [a weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) to indicate its importance\n\nThen, in a general community meeting where we end the release planning process, everyone identifies what they'll commit to, and we begin using the milestone to track progress and [a global project board to track the health status](https://gitlab.com/groups/tgdp/-/boards/5867329?milestone_title=Dragon%20release) when we do stand-ups to [report on progress](https://gitlab.com/groups/tgdp/-/milestones/4). \n\nTo prioritize effectively, we draw on guidance from our team of template product managers, who [perform extensive user research](https://tinyurl.com/template-brainstorming-report) into the templates our users or potential users think we should add to the roadmap. We attend conferences and engage with both technical writers and developers to hear what they want from our product. This team of product managers then distills this information into a long-term product roadmap that informs which template issues are strategically important to our project. We then translate that roadmap into issues in [our project backlog](https://gitlab.com/tgdp/templates/-/issues/?sort=updated_desc&state=opened&first_page_size=100).\n\n## Tracking a release\nGaining access to [GitLab's project management features](/features/?stage=plan) was one of our primary motivations for adopting the platform in the first place. These features allow us to track and monitor our progress toward a release. We love that with GitLab we can manage multiple sub-projects and repositories under our organization, but still view all the issues on a \"single pane of glass.\" This allows working groups and teams to work in their individual repositories, but gives us a high-level overview of their work at the organizational level, using features like milestones and scoped labels.\n\nTo track our releases, we configure a project milestone that runs for the full release time period. The milestone shows all the initiatives we're working on, as well as our progress toward each on [an organization-wide burndown chart](https://gitlab.com/groups/tgdp/-/milestones/3#tab-issues). We use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) (labels that can only be assigned to one value at a time) on each issue to track which working group is working on that initiative. We also use GitLab's [health status feature](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#health-status) to track whether the initiative is on track or at risk of falling behind schedule. On top of that, we create a project board that helps us visualize all the project's active issues and initiatives, filtered by each working group. Our project board provides insights into the work each group is doing and gives us a sense of the release's overall progress toward our release goals.\n\nThese boards are a focal point of our weekly general meetings. We review the milestone and project board, then check in with working group and team leads to make sure their work toward the release is going well. These meetings are opportunities to identify potential blockers preventing (or threatening to prevent) the work from getting done — or to communicate if any of our earlier estimates need to be adjusted. We build some flexibility into our release planning and tracking processes in case we need to make mid-release changes or course corrections. For example, we determine which individual template projects we'll add them to a release *during the release process itself, rather than during the release planning stage we descibed earlier. Since those projects are dependent on volunteer work that can't always be controlled by the project leads, we wait to officially add them to a release until we can be certain a template project will be ready for release day.\n\n## Release day\nWhen release day finally arrives, our [Tech Team](https://thegooddocsproject.dev/who-we-are/#tech-team) meets to tag the release in the templates repository and build our artifacts, including all our zip files and tarballs for our templates. To do that, the team:\n* Verifies that all merge requests are complete\n* Creates a tag for the templates repository for the main branch and adds a tag message indicating it is for a release\nAdds a release title, tags it with our milestone for that release, confirms the date, and adds the release notes (using [our community's own release notes template](https://gitlab.com/tgdp/templates/-/releases/v1.0.0), of course) by using the `Create Release` button on the release screen\n* Creates the release; GitLab generates all the files from our repository, including zips, tarballs, and JSON artifacts\n* Publishes a link to our release and the artifacts on our website\n\nWe try to ensure we've recognized and tagged every project member who contributed directly to the templates release. That includes people who wrote templates, improved existing templates, or created examples for our templates. Then, the Tech Team publishes the artifacts and release notes to our website and publishes an announcement to all our internal and external communication channels.\n\nWe believe it's important to take breaks. For that reason, our project always takes a three-week break after release day. For those three weeks, we encourage all our project members to get some well-deserved rest and relaxation. We don't hold any meetings during this time, and we encourage people to only communicate lightly with other project members.\n\nThen we regroup in July or January — and start the release process all over again!\n\nIt's not too late to join our next release and experience this process firsthand. Just visit [The Good Docs Project community page](https://thegooddocsproject.dev/community/) to learn how to get started.\n\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n{: .note}\n",[1187,266,9],{"slug":1714,"featured":6,"template":683},"coordinating-documentation-projects-gitlab","content:en-us:blog:coordinating-documentation-projects-gitlab.yml","Coordinating Documentation Projects Gitlab","en-us/blog/coordinating-documentation-projects-gitlab.yml","en-us/blog/coordinating-documentation-projects-gitlab",{"_path":1720,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1721,"content":1727,"config":1733,"_id":1735,"_type":13,"title":1736,"_source":15,"_file":1737,"_stem":1738,"_extension":18},"/en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile",{"title":1722,"description":1723,"ogTitle":1722,"ogDescription":1723,"noIndex":6,"ogImage":1724,"ogUrl":1725,"ogSiteName":670,"ogType":671,"canonicalUrls":1725,"schema":1726},"Create a workspace quickly with the GitLab default devfile","The GitLab default devfile makes it easier than ever to try out workspaces for new projects. Learn how to share developer environment configurations effortlessly with this tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097860/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%281%29_2XDPsbkjQ3o6tcdom6IGxI_1750097859914.png","https://about.gitlab.com/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Create a workspace quickly with the GitLab default devfile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Zhaochen Li\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":1722,"description":1723,"authors":1728,"heroImage":1724,"date":1730,"body":1731,"category":701,"tags":1732},[1729],"Zhaochen Li","2025-02-27","Software development environments can be complex to set up and maintain. Developers often spend a significant amount of time configuring their local environments with the right dependencies, tools, and settings. GitLab aims to solve this by providing a default devfile that enables you to create workspaces and to start developing quickly.\n\n## GitLab Workspaces\n\nGitLab Workspaces provide isolated development environments for making changes to your GitLab projects without the complexity of setting up local dependencies. Workspaces ensure reproducible development setups, allowing developers to share their environment configurations effortlessly.\n\nBy default, GitLab Workspaces are configured to use the GitLab VS Code fork and include the GitLab Workflow extension. To learn more, visit [the GitLab Workspaces documentation](https://docs.gitlab.com/ee/user/workspace/).\n\n## Understand devfiles\n\nA [**devfile**](https://devfile.io/docs/2.2.0/devfile-ecosystem) is a YAML-based declarative configuration file that defines a project's development environment. It specifies the necessary tools, languages, runtimes, and other components required for development.\n\nPreviously, [setting up a workspace](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) required a custom devfile at the root of the repository. For example, a `.devfile.yaml` file. A typical devfile looked like this:\n\n![typical default devfile](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-26_at_8.15.58_AM_aHR0cHM6_1750097868229.png)\n\n## GitLab default devfile\n\nStarting in GitLab 17.9, a GitLab default devfile is available for all projects when creating a workspace. This eliminates the need to manually create a devfile before starting a workspace.\nHere is the content of the default devfile:\n\n![GitLab default devfile content](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-26_at_8.16.20_AM_aHR0cHM6_1750097868230.png)\n\nWhen creating a workspace with the GitLab UI, the option **Use GitLab default devfile** is always available – regardless of whether custom devfiles exist in the repository. Simply select this option to start exploring GitLab Workspaces with one less setup step.\n\n![Use GitLab default devfile screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097868232.png)\n\n## Create your own custom devfiles\nWhile the GitLab default devfile provides a quick way to start a workspace, you may want to customize your development environment to better fit your project's needs. By creating a custom devfile, you can tailor your development environment with the exact tools, dependencies, and configurations needed for your workflow.\n\nConsider creating a custom devfile if you need to:\n\n- Add project-specific dependencies beyond the base development image.\n- Adjust CPU and memory resource limits.\n- Configure multiple containers for additional services like databases.\n- Define custom, project-specific, environment variables.\n- Set up specific port mappings.\n- Integrate specialized development tools like debuggers or language servers.\n\nFor more details, see the [Workspaces devfile documentation](https://docs.gitlab.com/ee/user/workspace/#devfile).\n\n## Read more\n\n- [Build and run containers in Remote Development workspaces](https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces/)\n- [Use GitLab AI features out-of-the-box in a GitLab Workspace](https://about.gitlab.com/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace/)\n- [Quickstart guide for GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)\n- [Enable secure sudo access for GitLab Remote Development workspaces](https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces/)\n",[829,478,9,746,701],{"slug":1734,"featured":6,"template":683},"create-a-workspace-quickly-with-the-gitlab-default-devfile","content:en-us:blog:create-a-workspace-quickly-with-the-gitlab-default-devfile.yml","Create A Workspace Quickly With The Gitlab Default Devfile","en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile.yml","en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile",{"_path":1740,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1741,"content":1747,"config":1753,"_id":1755,"_type":13,"title":1756,"_source":15,"_file":1757,"_stem":1758,"_extension":18},"/en-us/blog/create-vision",{"title":1742,"description":1743,"ogTitle":1742,"ogDescription":1743,"noIndex":6,"ogImage":1744,"ogUrl":1745,"ogSiteName":670,"ogType":671,"canonicalUrls":1745,"schema":1746},"GitLab's 2019 product vision for DevOps Create","Take an early look at where collaboration, merge requests, and the Web IDE are heading in 2019.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678812/Blog/Hero%20Images/web-ide-cover.jpg","https://about.gitlab.com/blog/create-vision","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's 2019 product vision for DevOps Create\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"James Ramsay\"}],\n        \"datePublished\": \"2018-09-21\",\n      }",{"title":1742,"description":1743,"authors":1748,"heroImage":1744,"date":1750,"body":1751,"category":298,"tags":1752},[1749],"James Ramsay","2018-09-21","\nGitLab is a single application, so for convenience we organize by [DevOps stages](/handbook/product/categories/). The Create stage of the DevOps lifecycle is about creating code, and includes Git repositories, merge requests, code review, the Web IDE, wikis, and snippets.\n\nManaging source code is at the heart of GitLab – it's in our name and it powers your applications. This year we've shipped many important improvements to make it easier to go from idea to production. The [Web IDE](/releases/2018/06/22/gitlab-11-0-released/#cicd-pipeline-status-and-job-traces-in-the-web-ide) makes it easy for anyone to contribute, and faster to work with merge requests. [Squash and Merge](/releases/2018/06/22/gitlab-11-0-released/#squash-and-merge-in-gitlab-core-and-gitlabcom-free), and [Rebase and Fast-forward Merge](/releases/2018/01/22/gitlab-10-4-released/#rebase-and-fast-forward-in-ce) are available in GitLab CE. [File locking](/releases/2018/02/22/gitlab-10-5-released/#git-lfs-2-locking-support) is integrated with Git LFS. [Maintainers can push to forks](/releases/2018/03/22/gitlab-10-6-released/#maintainers-can-push-to-mr-from-fork). And there is much more to come this year, like [batch comments](https://gitlab.com/gitlab-org/gitlab-ee/issues/1984) for merge requests, and [suggested approvers](https://gitlab.com/gitlab-org/gitlab-ee/issues/5382) based on code owners.\n\nHere are some of the things we're thinking about for 2019:\n\n- [Collaboration](#collaboration)\n- [Code review and approvals](#code-review-and-approvals)\n- [Web IDE](#web-ide)\n- [Summary](#summing-up)\n\nAs our plans are always in draft, we'd love to hear your thoughts, and any suggestions.\n\n### Collaboration\n\nGit's distributed design made new collaborative workflows possible, and forking has made collaboration even easier. Forking is the workflow of choice for open source, and for the same reasons it is also great for private organizations. We want to remove the barriers to collaboration and [inner sourcing](/topics/version-control/what-is-innersource/), but also make it easier to collaborate with external open source projects too.\n\nThe distributed capabilities of Git aren't limited to a single server. Open source software is used extensively in commercial applications of all kinds, but collaboration between open source projects and commercial is difficult. Features and bug fixes to open source projects can sit in stale forks in private Git repositories for lack of tools and process. [Distributed merge requests](https://gitlab.com/groups/gitlab-org/-/epics/260) will make it easy publish a patch from a private GitLab instance to a public upstream server, be it GitLab, GitHub or Bitbucket. Teams will be able to work on a patch privately following internal processes, but instead of merging the reviewed and tested change privately, it can be published to a new public merge request upstream. Contributing fixes and features upstream isn't only good for the community, but it also makes commercial sense by eliminating the costly task of keeping a stale, private fork up to date. We want to make it easy for everyone to contribute to open source software, as individuals and as companies!\n\n![Mockup of distributed merge request widget](https://about.gitlab.com/images/blogimages/merge-request-distributed.png){: .medium.center.shadow}\n\nWe'll also be improving simpler forking workflows too with important quality-of-life improvements. To make it easy to see how far behind or diverged your fork is, we will make it possible to [compare branches](https://gitlab.com/gitlab-org/gitlab-ce/issues/19788) across forks and [cherry pick](https://gitlab.com/gitlab-org/gitlab-ce/issues/43568) changes directly from the upstream project into your fork. Forks of private projects will also [inherit permissions](https://gitlab.com/gitlab-org/gitlab-ce/issues/8935) from the upstream project, making it possible for upstream maintainers to rebase stale merge requests and help contributors. This will allow teams to adopt forking workflows without needing to make every project public to the world or to the organization.\n\n### Code review and approvals\n\nMerge requests are key to the workflows that allow teams to iterate rapidly and ship amazing products quickly, by bringing together all the important information in a single place. Critical to this workflow is the code review, and we want GitLab to be the best tool for doing code reviews.\n\nAutomatic code quality and linting tools can prevent code reviews becoming simple code style reviews, but without the inline feedback a reviewer can't be sure which problems have been automatically detected. A new [API for line by line code quality feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/50299) will allow output from tools to be rendered natively in GitLab in the merge request diff. Merge request authors will have a single source of truth, and code reviewers can confidently focus on important structural feedback.\n\nCode review feedback cannot truly be resolved and the merge request approved until the reviewer checks the feedback was correctly addressed. This step prevents feedback from being misunderstood or overlooked, but it is currently difficult and time consuming. We are going to streamline this important step by allowing you to [review changes since code review](https://gitlab.com/groups/gitlab-org/-/epics/314) and making [merge request diffs smarter](https://gitlab.com/groups/gitlab-org/-/epics/340). When the change is straightforward, we're going to make it possible to simply [propose a change](https://gitlab.com/gitlab-org/gitlab-ce/issues/18008) as easily as leaving a comment that can be applied with a single click – no more copying and pasting `sed` one liners! And we're going to make it easier to [view and add comments to commits](https://gitlab.com/gitlab-org/gitlab-ee/issues/1769) at any time.\n\nIn the real world, complex features often require large, complex merge requests. We will support these situations better with [commit by commit code review](https://gitlab.com/groups/gitlab-org/-/epics/285), autosquashing [`fixup!`](https://gitlab.com/gitlab-org/gitlab-ee/issues/212) and [`squash!`](https://gitlab.com/gitlab-org/gitlab-ce/issues/50400) commits, and allowing you to [preview](https://gitlab.com/gitlab-org/gitlab-ee/issues/7259) the resultant squashed commits.\n\nComplex real-world changes also need good commit messages, but commit messages are too easily neglected. Without good commit messages, debugging a regression, or modifying an important existing function is painful and error prone. To help teams adopt best practice [commit hygiene](/blog/keeping-git-commit-history-clean/), we will make [commit messages part of code review](https://gitlab.com/groups/gitlab-org/-/epics/286) by allowing comments on commit messages, improving the [visibility of commit messages](https://gitlab.com/gitlab-org/gitlab-ce/issues/49803), and making [squash and merge smarter](https://gitlab.com/gitlab-org/gitlab-ce/issues/47149). GitLab should celebrate great commit messages and amplify their benefits to make it easier for teams to adopt best practices.\n\n### Web IDE\n\nIn 2018 we're building a strong foundation for a cloud development environment with [client side evaluation](https://gitlab.com/gitlab-org/gitlab-ce/issues/47268) and [server side evaluation](https://gitlab.com/gitlab-org/gitlab-ee/issues/4013) powered live previews, and server side evaluation will also enable a [web terminal](https://gitlab.com/gitlab-org/gitlab-ee/issues/5426) to test your changes in real time. IDEs are also very personal and should support customization, to make it easy to move between your local IDE and GitLab IDE. Please share your feedback, and consider contributing – I'd love to see support for [dark syntax themes](https://gitlab.com/gitlab-org/gitlab-ce/issues/46334) and [vim keybindings](https://gitlab.com/gitlab-org/gitlab-ce/issues/47930)!\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/sSWu6TyubTE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThe Web IDE makes it easier than ever to resolve code review feedback, reducing the need to switch context in your local development environment, but we can make it even better. Addressing a comprehensive code review still requires switching backwards and forwards between the merge request and the Web IDE. [Line by line code quality feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/50299) available in the merge request diff will also be available in the Web IDE as will [live linting feedback](https://gitlab.com/groups/gitlab-org/-/epics/70) powered by server side evaluation so to help prevent new code styling problems being created while resolving feedback.\n\nWe are also considering integrating [merge request discussions](https://gitlab.com/groups/gitlab-org/-/epics/72) so that code review comments can be addressed without needing to continually switch between tabs. We don't think the Web IDE should replace the merge request, nor should every feature be duplicated into it, but do think the Web IDE can further simplify the process for resolving code review feedback so teams can iterate faster.\n\n### Summing up\n\nWriting, reviewing, and merging code is where the rubber hits the road when taking your app from idea to production, and in 2019 we want it to be better than ever before!\n\nThe [GitLab product vision](/direction/) is public so you can read up on what we're thinking about at any time, about every part of the product. Please join the conversation and share your feedback on these ideas, and offer ideas of your own! Your contributions – idea or code – are welcomed and appreciated so that we can all work together to make GitLab the best application to build and ship your next great idea.\n",[680,9,829,894,851],{"slug":1754,"featured":6,"template":683},"create-vision","content:en-us:blog:create-vision.yml","Create Vision","en-us/blog/create-vision.yml","en-us/blog/create-vision",{"_path":1760,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1761,"content":1767,"config":1773,"_id":1775,"_type":13,"title":1776,"_source":15,"_file":1777,"_stem":1778,"_extension":18},"/en-us/blog/cross-project-pipeline",{"title":1762,"description":1763,"ogTitle":1762,"ogDescription":1763,"noIndex":6,"ogImage":1764,"ogUrl":1765,"ogSiteName":670,"ogType":671,"canonicalUrls":1765,"schema":1766},"How to trigger multiple pipelines using GitLab CI/CD","Discover how to trigger and visualize pipelines when you set up GitLab CI/CD across multiple projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666903/Blog/Hero%20Images/pipeline.jpg","https://about.gitlab.com/blog/cross-project-pipeline","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to trigger multiple pipelines using GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2019-07-24\",\n      }",{"title":1762,"description":1763,"authors":1768,"heroImage":1764,"date":1770,"body":1771,"category":849,"tags":1772},[1769],"Itzik Gan Baruch","2019-07-24","\n[Continuous integration (CI)](/solutions/continuous-integration/) is the practice of [automating code building and testing](/topics/ci-cd/) before it is\nmerged into the master or default branch. This allows developers to merge code early and frequently, while\nmitigating the risk of introducing new bugs into the master source code repository.\n\nWhile CI verifies that new code won't break when integrated with other code in the same repo, having\nall tests pass on that repo is only the first step. After running CI on the code, it is important to\ndeploy and run tests in a live environment. Moving from [CI to continuous delivery and deployment (CD)](/solutions/continuous-integration/)\nis [the next step of DevOps maturity](/topics/devops/). Deploying and then testing again allows code in one project\nto be tested together with other components and services which may be managed in other projects.\n\n## Why do I need to verify that my code works with other components?\n\nA good example could be a\nmicroservices architecture. Usually, different [microservices](/topics/microservices/) are managed in\ndifferent [projects](https://docs.gitlab.com/ee/user/project/) – each microservice has its own\nrepository and own pipeline. It's also very common for different teams to be\nresponsible for different microservices and their pipeline configurations. As a developer you will\nwant to confirm that your code changes don't break functionality of the dependent microservices.\nTherefore, you will want to execute tests on those microservices in addition to your project tests.\n\n## The cross-project pipeline\n\nWhen running your [project pipeline](/topics/ci-cd/cicd-pipeline/), you also want to trigger cross-project or multi-project pipelines,\nwhich will eventually deploy and test the latest version of all dependent microservices. To\nachieve this goal you need an easy, flexible and convenient way to trigger other\npipelines as part of your project CI. GitLab CI/CD offers an easy way to run a cross-project\npipeline by simply adding a pipeline trigger job in the CI configuration file.\n\n## GitLab CI/CD configuration file\n\nIn GitLab CI/CD, pipelines, and their component jobs and stages, are defined in\nthe [`.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/) file for each project. The\nfile is part of the project repository. It is fully versioned and developers can edit it with any\ncommon IDE of their choice. They do not have to ask the system admin or DevOps team to make\nchanges in the pipeline configuration as it is self-service. The `.gitlab-ci.yml` file defines the structure\nand order of the pipelines and determines what to execute\nusing [GitLab Runner](https://docs.gitlab.com/runner/) (the agent that runs the jobs), and what\ndecisions to make when specific conditions are encountered, like when a process succeeds or fails.\n\n## Add a cross-project pipeline triggering job\n\nSince GitLab 11.8, GitLab provides a new CI/CD configuration syntax for triggering cross-project\npipelines found in the [pipeline configuration file](https://docs.gitlab.com/ee/ci/yaml/).\nThe following code illustrates configuring a bridge job to trigger a downstream pipeline:\n\n```\n//job1 is a job in the upstream project\ndeploy:\n\tstage: Deploy\n\tscript: this is my script\n\n//job2 is a bridge job in the upstream project which triggers cross-project pipeline\nAndroid:\n\tstage: Trigger-cross-projects\n            trigger: mobile/android\n```\n\nIn the example above, as soon as the deploy job succeeds in the deploy stage, the Android\nbridge job is going to be started. The initial status of this job will be pending. GitLab will\ncreate a downstream pipeline in the mobile/android project and, as soon as the pipeline gets created,\nthe Android job will succeed. In this case mobile/android is a full path to that project.\n\nThe user who created the upstream pipeline needs to have access rights to the downstream\nproject (mobile/android in this case). If a downstream project cannot be found, or a user does not\nhave access rights to create a pipeline there, the Android job will be marked as failed.\n\n## Browse from upstream pipeline graphs to downstream\n\nGitLab CI/CD makes it possible to visualize the pipeline configuration. In the below illustration, the\nbuild, test, and deploy stages are parts of the upstream project. Once the deploy job succeeds, four\ncross-projects will be triggered in parallel and you will be able to browse to them by clicking on\none of the downstream jobs.\n\n![Build, test and deploy stages](https://about.gitlab.com/images/blogimages/Cross-proj-img1.png){: .shadow.medium.center}\n\nIn the below illustration the Service – Finance downstream pipeline is visible. We can now scroll\nleft to the upstream pipeline, scroll right back to the downstream pipeline or select another\ndownstream pipeline.\n\n![Service – Finance pipeline](https://about.gitlab.com/images/blogimages/Cross-proj-img2.png){: .shadow.medium.center}\n\n## Specifying a downstream pipeline branch\n\nIt is possible to specify a branch name that a downstream pipeline will use:\n\n```\ntrigger:\n     project: mobile/android\n     branch: stable-11-2\n```\n\nUse a project keyword to specify the full path to a downstream project. Use a branch keyword to\nspecify a branch name. GitLab will use a commit that is currently on the HEAD of the branch\nwhen creating a downstream pipeline.\n\n## Passing variables to a downstream pipeline\n\nSometimes you might want to pass variables to a downstream pipeline. You can do that using\nthe variables keyword, just like you would when defining a regular job.\n\n```\nAndroid:\n           variable:\n\t     ENVIRONMENT: ‘This is the variable value for the downstream pipeline’\n           stage: Trigger-cross-projects\n           trigger: mobile/android\n```\nThe ENVIRONMENT variable will be passed to every job defined in a downstream pipeline. It will be\navailable as an environment variable when GitLab Runner picks a job.\n\n## Cross-project pipeline summary\n\nThe `.gitlab-ci.yml` file defines the order of the CI/CD stages, which jobs to execute, and at which\nconditions to run or skip a job's execution. Adding a 'bridge job' with the `trigger` keyword to\nthis file can be used to trigger cross-project pipelines. We can pass parameters to jobs in\ndownstream pipelines, and even define a branch that a downstream pipeline will use.\n\nPipelines can be complex structures with many sequential and parallel jobs, and as we just\nlearned, sometimes they can trigger downstream pipelines. To make it easier to understand the\nflow of a pipeline, including its downstream pipelines, GitLab has pipeline graphs for viewing\npipelines and each pipeline's status.\n\n![Service – Finance pipeline](https://about.gitlab.com/images/blogimages/Cross-proj-img4.png){: .shadow.medium.center}\n\nHey community, what else would you like me to explain in a blog post? Let me know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\nCover image by [Tian Kuan](https://unsplash.com/@realaxer) on [Unsplash](https://unsplash.com)\n{: .note}\n",[108,851,9,1124,894],{"slug":1774,"featured":6,"template":683},"cross-project-pipeline","content:en-us:blog:cross-project-pipeline.yml","Cross Project Pipeline","en-us/blog/cross-project-pipeline.yml","en-us/blog/cross-project-pipeline",{"_path":1780,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1781,"content":1787,"config":1793,"_id":1795,"_type":13,"title":1796,"_source":15,"_file":1797,"_stem":1798,"_extension":18},"/en-us/blog/dast-release-first-gitlab-active-check",{"title":1782,"description":1783,"ogTitle":1782,"ogDescription":1783,"noIndex":6,"ogImage":1784,"ogUrl":1785,"ogSiteName":670,"ogType":671,"canonicalUrls":1785,"schema":1786},"Introducing GitLab browser-based active checks in DAST","As of GitLab 16.4, or DAST 4.0.9, browser-based DAST active scans will search for path traversal vulnerabilities using the GitLab check 22.1 instead of the ZAP alert 6.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664638/Blog/Hero%20Images/applicationsecurity.png","https://about.gitlab.com/blog/dast-release-first-gitlab-active-check","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab browser-based active checks in DAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cameron Swords\"}],\n        \"datePublished\": \"2023-10-10\",\n      }",{"title":1782,"description":1783,"authors":1788,"heroImage":1784,"date":1790,"body":1791,"category":704,"tags":1792},[1789],"Cameron Swords","2023-10-10","\nGitLab's [DAST](/direction/secure/dynamic-analysis/dast/) and [Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/) teams released the first GitLab active check in browser-based dynamic application security testing. This continues our work to integrate passive checks into browser-based DAST. As of GitLab 16.4, or DAST 4.0.9, browser-based DAST active scans will search for path traversal vulnerabilities using the GitLab check [22.1](https://docs.gitlab.com/ee/user/application_security/dast/checks/22.1.html) instead of the ZAP alert [6](https://www.zaproxy.org/docs/alerts/6/).\n\nReplacing ZAP alerts with GitLab active checks enables developers and security teams to detect vulnerabilities in modern-day web applications more effectively. Going forward, we anticipate replacing more ZAP alerts with GitLab active checks. If you are interested in using the browser-based DAST analyzer, please see: [How to configure a browser-based DAST scan documentation](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html).\n\nBelow is an explanation of how active checks work, different types of attacks, and worked examples of browser-based attacks.\n\n## How to use GitLab active checks\nCustomers who run active scans (full scans) will automatically run GitLab active checks as they are tested and released by the DAST team. Each corresponding ZAP alert will be turned off at this time.\n\nCustomers can opt out of these changes, disabling the GitLab active checks and re-enabling the ZAP alerts by adding the CI/CD variable `DAST_FF_BROWSER_BASED_ACTIVE_ATTACK: \"false\"`.\n\n## What is an active check?\nAn active check defines a series of attacks that, when run against the target web application, identify susceptibility to specific kinds of weakness ([CWE](https://cwe.mitre.org/)). Active checks are run during the [active scan](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html#active-scans) (full scan) phase of a DAST scan.\n\n## What does an active check attack do?\n[In-scope](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html#managing-scope) HTTP requests recorded during the crawl phase of the DAST scan are searched for injection locations, places in the request where an attack payload can be injected. Example injection locations include cookie values, request paths, query parameters, headers, JSON string values, XML, and inputs submitted with a form.\n\nEach attack defines payloads, which are text or binary content to inject into an HTTP request. Payloads can have prefixes (e.g. `c:\\`) or affixes (e.g. `.exe`). Payloads can be an extension of the value originally submitted with the HTTP request.\n\nEvery active check attack will be run against every crawled HTTP request's injection locations. Each injection location may have multiple attack payloads injected into it by each attack. Each unique payload injected into an injection location becomes a new HTTP request to send to the target web application. HTTP responses to these requests are used to determine if the attack succeeded.\n\n## Types of attacks\nDifferent types of attacks are necessary to detect different kinds of weaknesses.\n\n### Match response attacks\nMatch response attacks send an attack payload with the HTTP request and search the HTTP response body for unintentionally exposed content. For example, a path traversal attack that uses a payload of `/etc/passwd` might look for evidence of that file in the HTTP response body.\n\nMost attacks are match response attacks.\n\n### Timing attacks\nTiming attacks are useful for blind injection payloads where the success of the attack is determined by how long the target web application took to return the HTTP response. For example, a SQL injection attack might use a payload containing `sleep(15)` to ask the database to pause for 15 seconds and determine attack success if the target web application took longer than 15 seconds to return the HTTP response.\n\nNaive timing attacks are prone to false positives due to unpredictable timing delays introduced by factors such as variable internet speeds and cached content. To mitigate this, each DAST timing attack uses multiple payloads with individual success conditions, and each timing attack must succeed three times in a row to register as a weakness. Timing attacks run one at a time to prevent one attack from skewing the results of other attacks.\n\n### Callback attacks\nCallback attacks are useful to determine if the target web application unintentionally allows data to be exposed to an external entity. For example, a URL in a website query parameter could be injected with the callback server `https://site.com/login?redirect-to=https://callback-server.dast/123456789`. DAST determines if the target web application unintentionally made an HTTP request to an untrusted source by asking the callback server if it received a request with ID `123456789`.\n\nThe initial priority for DAST browser-based attacks is on match response and timing attacks. For callback attacks, see [Breach and Attack Simulation](https://docs.gitlab.com/ee/user/application_security/).\n\n## How are attacks defined?\nThe [Vulnerability Research team](/handbook/engineering/development/sec/secure/vulnerability-research/) writes active checks in YAML to minimize the time required to update or add new checks. A simplified example of the 22.1 path traversal attack looks as follows:\n\n```yaml\nactive_check:\n  attacks:\n    - id: 2\n      type: \"match_response\"\n      description: \"Inject /etc/passwd, report as vulnerable if the response body matches /etc/passwd file contents.\"\n      target_tech: [\"os:unix\"]\n      injection_locations_policy:\n        default:\n          locations:\n            - \"cookie_value\"\n            - \"request_parameter_value\"\n            - \"request_body_parameter_value\"\n            - \"json_value\"\n            - \"xml_value\"\n            - \"multipart_form_data_filename\"\n            - \"multipart_form_data_value\"\n      match_response_attack:\n        payloads: [\"/etc/passwd\"]\n        injections:\n          - template: \"{payload}\"\n          - template: \"{prefix}{payload}{suffix}\"\n            affixes:           \n              - prefix: \"/../../../../../../../../../../../..\"\n                suffix: \"\"\n        matchers:\n          - description: \"Check the HTTP response body to see if it contains the /etc/passwd file contents\"\n            severity: \"High\"\n            match:\n              location: \"response_body\"\n              expression: \"root:.:0:0:\"\n```\n\n## Worked example\nDuring the DAST crawl phase, DAST submits a form with an input field named `file_name` (headers simplified for brevity).\n\n```\nPOST /read-file HTTP/1.1\nAccept: text/html\nContent-Length: 20\nContent-Type: application/x-www-form-urlencoded\nHost: site.com\n\nfile_name=browserker\n```\n\nDuring the active scan phase, DAST creates attacks from crawled HTTP requests. From the above request, injection locations are found for each of the four header values, the request path `/read-file` and the form input value `browserker`. For a path traversal attack with payload `/etc/passwd`, six attack HTTP requests will be made to the target web application, each with the payload injected into the according injection location.\n\nThe attack on the form input value injection location HTTP would be:\n\n```\nPOST /read-file HTTP/1.1\nAccept: text/html\nContent-Length: 20\nContent-Type: application/x-www-form-urlencoded\nHost: site.com\n\nfile_name=/etc/passwd\n```\n\nAssuming the target web application is vulnerable to a path traversal in the form input, it might read the contents of `/etc/passwd` and return it in the HTTP response, such as:\n\n```\nHTTP/1.1 200 OK\nCache-Control: no-store, no-cache, must-revalidate, proxy-revalidate\nContent-Length: 229\nContent-Type: text/html; charset=utf-8\nDate: Mon, 25 Sep 2023 14:55:20 GMT\n\n\u003Chtml>\n\u003Cbody>\n  \u003Cdiv id=\"content\">\n    root:x:0:0:root:/root:/bin/bash\n    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n    bin:x:2:2:bin:/bin:/usr/sbin/nologin\n    sys:x:3:3:sys:/dev:/usr/sbin/nologin\n  \u003C/div>\n\u003C/body>\n\u003C/html>\n```\n\nThe DAST path traversal attack regular expression `root:.:0:0:` matches against the HTTP response body, so the attack is successful and a new finding is created.\n\n[Try GitLab's browser-based DAST scanning](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html).\n",[703,701,1124,9,704],{"slug":1794,"featured":6,"template":683},"dast-release-first-gitlab-active-check","content:en-us:blog:dast-release-first-gitlab-active-check.yml","Dast Release First Gitlab Active Check","en-us/blog/dast-release-first-gitlab-active-check.yml","en-us/blog/dast-release-first-gitlab-active-check",{"_path":1800,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1801,"content":1807,"config":1814,"_id":1816,"_type":13,"title":1817,"_source":15,"_file":1818,"_stem":1819,"_extension":18},"/en-us/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":1802,"description":1803,"ogTitle":1802,"ogDescription":1803,"noIndex":6,"ogImage":1804,"ogUrl":1805,"ogSiteName":670,"ogType":671,"canonicalUrls":1805,"schema":1806},"Data-driven DevSecOps: Exploring GitLab Insights Dashboards","Learn how to leverage GitLab Insights Dashboards to visualize key metrics, track project progress, and boost team productivity with customizable, data-driven views.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Data-driven DevSecOps: Exploring GitLab Insights Dashboards\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }",{"title":1802,"description":1803,"authors":1808,"heroImage":1804,"date":1810,"body":1811,"category":701,"tags":1812},[1809],"Ricardo Amarilla Villalba","2024-11-20","Metrics and analytics play a crucial role in driving productivity, quality, and success. GitLab, as a comprehensive DevSecOps platform, offers powerful tools for tracking and visualizing these vital metrics through its Insights Dashboards. In this article, you'll learn how to use the Insights Dashboards in your environment.\n\n## Introduction to GitLab metrics and analytics \n\nGitLab provides an array of metrics and analytics tools that cover various aspects of the DevSecOps lifecycle:\n\n1. [Productivity Analytics](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html): Track team velocity, cycle time, and lead time.  \n2. [Code Review Analytics](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html): Measure code quality, test coverage, and review efficiency.  \n3. [CI/CD Analytics](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html): Monitor pipeline performance and deployment frequency.  \n4. [Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/): Visualize the flow of work from idea to production.  \n5. [Insights](https://docs.gitlab.com/ee/user/project/insights/): Explore and visualize data about your projects and groups.\n\nThese metrics offer invaluable insights into your development process, helping teams identify bottlenecks, optimize workflows, and make data-driven decisions.\n\n## Leveraging labels for specific metrics\n\nOne of GitLab's most powerful, yet understated features, is Labels, which allows you to filter and focus on specific metrics with pinpoint accuracy. By strategically applying labels to issues, merge requests, and epics, you can create custom views that provide targeted insights into your project's performance and progress.\n\nLabels in GitLab act as versatile identifiers, allowing you to categorize and organize your work items with great flexibility. Whether you're tracking feature development, bug fixes, or team-specific tasks, labels enable you to slice and dice your project data in ways that reveal meaningful patterns and trends. This concept parallels the use of tags in cloud deployments, where resources are labeled for easier management, cost allocation, and operational insights.\n\nBy thoughtfully labeling your work items, you're essentially creating a sophisticated labeling system that can be leveraged to generate custom dashboards and reports. This approach empowers you to zoom in on the metrics that matter most to your team or stakeholders, providing a clear and focused view of your project's health and momentum.\n\n## How to configure GitLab Insights\n\nGitLab Insights allow you to explore and visualize data about your projects and groups. They provide valuable analytics on various aspects such as issues created and closed during a specified period, average time for merge requests to be merged, and triage hygiene. Insights can be configured for both projects and groups.\n\nTo configure Insights:\n\n1. For project insights:  \n   * Create a file named `.gitlab/insights.yml` in the root directory of your project.  \n2. For group insights:  \n   * Create a `.gitlab/insights.yml` file in a project that belongs to your group.  \n   * Go to your group's **Settings > General**.  \n   * Expand the **Analytics section** and find the **Insights section**.  \n   * Select the project containing the configuration file and save changes.\n\nThe `.gitlab/insights.yml` file is a YAML file where you define the structure and order of charts in a report, as well as the style of charts to be displayed. Each chart definition includes parameters such as title, description, type, and query to specify the data source and filtering conditions.\n\nTo view insights, navigate to **Analyze > Insights** in your project or group.\n\n![View default Insights Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n## Customize merge request insights\n\nWhile the default view provides valuable raw information, we can customize the Insights Dashboard to uncover additional layers of information, such as which team was responsible for each merge request and what type of problem each one solved.\n\n## Merge request insights for each squad and requirement type\n\nMeasuring squad productivity in GitLab can be challenging, especially when the GitLab group and subgroup structure doesn't align perfectly with your squad organization. Here's how to overcome these challenges and effectively track squad productivity:\n\n### **Setting up squad-based metrics**\n\n1. **Label creation:** Create unique scope labels for each squad (e.g., `squad::alpha`, `squad::beta`) and each requirement type (e.g., `type::bug`, `type::feature`, `type::maintenance`).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n2. **Label application:** Consistently apply these squad labels to all issues and merge requests handled by each squad, regardless of the project or group they're in.  \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Hints:**  \n   * Use GitLab API to apply labels massively to existing open, merged, and closed MRs.  \n   * Add/remove/update labels as part of your GitLab CI pipeline.  \n   * Leverage the GitLab Triage Bot to automate the labeling process.  \n\n3. Dashboard setup: Create a `.gitlab/insights.yml` file in your project repository with custom charts for team-specific and type-specific merge request insights.\n\n```\n\n## Default Merge Requests insights.yml \nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\nBy implementing these customizations, you can create insightful dashboards that provide a clear view of merge request activity per team and requirement type, allowing you to visualize trends over time, compare performance between squads, and analyze the distribution of different types of work for each squad. \n\n![dashboards with view of MR activity per team and requirement type](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n![dashboard comparing performance between squads](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)\n\n## Get started today\n\nGitLab Insights is just the tip of the iceberg when it comes to metrics and analytics. To explore the full range of GitLab's powerful analytics features, including Value Stream Analytics, CI/CD Analytics, and Code Review metrics, check out our Value Stream Management product tour:\n\n[![Value Stream Management product tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-11-20_at_12.28.08_PM_aHR0cHM6_1750097217976.png)](https://gitlab.navattic.com/vsm)\n\n> Ready to start your own metrics journey? Sign up for a [free 60-day trial of GitLab Ultimate today](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F) and unlock the full potential of data-driven DevSecOps.\n\n## Read more\n- [Scheduled Reports Generation tool simplifies value stream management](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Getting started with the new GitLab Value Streams Dashboard](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n- [AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n",[108,478,701,9,746,1813],"solutions architecture",{"slug":1815,"featured":90,"template":683},"data-driven-devsecops-exploring-gitlab-insights-dashboards","content:en-us:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","en-us/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","en-us/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":1821,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1822,"content":1828,"config":1834,"_id":1836,"_type":13,"title":1837,"_source":15,"_file":1838,"_stem":1839,"_extension":18},"/en-us/blog/day-in-the-life-remote-worker",{"title":1823,"description":1824,"ogTitle":1823,"ogDescription":1824,"noIndex":6,"ogImage":1825,"ogUrl":1826,"ogSiteName":670,"ogType":671,"canonicalUrls":1826,"schema":1827},"A day in the life of the \"average\" remote worker","Go on, you know you're curious! Explore a day in the life of GitLab team members from around the world.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670134/Blog/Hero%20Images/remote-life-cover.png","https://about.gitlab.com/blog/day-in-the-life-remote-worker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A day in the life of the \"average\" remote worker\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"},{\"@type\":\"Person\",\"name\":\"Charlie Ablett\"}],\n        \"datePublished\": \"2019-06-18\",\n      }",{"title":1823,"description":1824,"authors":1829,"heroImage":1825,"date":1831,"body":1832,"category":996,"tags":1833},[675,1830],"Charlie Ablett","2019-06-18","\nGitLab is an [all-remote company](/company/culture/all-remote/), meaning we are not based in one location or even one time zone. Instead, our team is distributed in home offices and work spaces [across the globe](/company/team/#countries), everywhere from San Francisco to London to Taipei.\n\nBecause GitLab is not limited to one time zone, we work asynchronously. Our asynchronous workflow gives us a [competitive advantage](/blog/remote-enables-innovation/), because we are contributing 24 hours a day, as opposed to the standard 9am-5pm if we had a brick-and-mortar office headquartered in one location. As an organization, the focus is not on when or how a team member works, but rather on our [results](https://handbook.gitlab.com/handbook/values/#results).\n\nBecause of this emphasis on results rather than regimen, there is a lot of variability in how we structure our workdays. At [Contribute 2019](/events/gitlab-contribute/), a group of us came together to discuss how we use the flexibility GitLab affords us to structure our ideal workdays. Our discussion featured team members working in different capacities, as engineers, writers, and managers, from many different locations.\n\n## Morning\n\nThere are a few morning activities that were universal: A warm cup of coffee or tea to kick off the day; and morning cuddles with a cat or dog if you have the good fortune of having a pet.\n\n\"When my alarm goes off, Milly, my dog, who hates getting out of bed, snuggles closer to me. I get up, make coffee, and log on to begin working. Meanwhile, Milly is usually still in bed until 10:30am, sometimes even 11:30am,\" says [Sara Kassabian](/company/team/#sarakassabian), content editor, from Oakland, California.\n\nFor some of us, sunshine (or other humans) function as the morning wake-up call.\n\n\"I stopped setting an alarm because mornings are quiet in my time zone, and (inevitably) I get woken by my upstairs neighbors getting ready for work anyway! I make a big cup of coffee and try to get all my deep focus work done before my coworkers in the US start to wake up,\" says [Rebecca Dodd](/company/team/#rebecca), managing editor, from London.\n\n\"I also do not set an alarm because I often work until late. Usually my kids wake me up at some point, and then I will have a big cup of tea,\" says [Charlie Ablett](/company/team/#cablett), a senior backend engineer, [Plan](/handbook/engineering/development/dev/plan/), from New Zealand.\n\nMornings can be a particularly hectic time for working parents. Oftentimes, parents who don't work remotely will have to juggle getting their children ready for school, getting ready for work, and making school drop-off in time to get to the office between 8am-9am. Parents working at GitLab have the opportunity to be in the home and available to their children because we're [all remote](/blog/building-an-award-winning-culture-at-gitlab/). Flexible scheduling makes it a little bit easier to balance family with work obligations.\n\n## Midday\n\nWe all structure our afternoons differently. Some of us have children to pick up from school, while others are just starting their workday, or taking a break from the computer to run errands or exercise.\n\n\"I usually take a break to go running or to walk my dog. Then I’ll pick up my kids from school. I usually have one or two more screening calls and some team meetings,\" says [Stephanie Garza](/company/team/#stephaniegarza), diversity sourcing specialist, from Michigan.\n\n\"I start my workday in the afternoon by checking Slack and emails. I may go for a walk. I might work out then start focused work at 3pm or so,\" says [Laura Montemayor](/company/team/#lauraMon), frontend engineer, [Monitor](/handbook/engineering/frontend/monitor/), from New York City.\n\nWeather is also a big determinant about whether work or play is on the agenda for the afternoon.\n\n\"It depends on whether or not the weather is nice or if I have plans in the evening. If it’s sunny in New York City, you have to go outside. If it’s nice I want to go enjoy the weather! Or if I’m going out in the evening I’ll get my work done first,\" says Avielle Wolfe, backend engineer, [Secure](/handbook/engineering/development/sec/secure/), from New York City.\n\n\"If it’s sunny in Oakland, I will take Milly for a longer walk, which gives me some Vitamin D and the boost of energy I’ll need to finish up any remaining tasks for the day,\" added [Sara](/company/team/#sarakassabian).\n\nNot every team member lives in a location as urban as Oakland or New York City. Some live in suburban neighborhoods or more rural locations, all of which can have an impact on how we structure our day. For instance, [Charlie](/company/team/#cablett), who lives in a more rural setting, once had to set aside an hour around 4pm each day to milk her cows.\n\n## Evening\n\nFor those of us with children, the evenings are the ideal time to set work aside and focus on family time.\n\n\"My evening typically begins with practice. My daughter does soccer and my son does karate. My husband works a weird schedule so this is my alone time with the kids. I will make dinner and then get some more work done sometime between 8-10pm,\" says [Stephanie](/company/team/#stephaniegarza).\n\nIf our workday started in the afternoon as opposed to the morning, there are often more tasks to be completed throughout the evening.\n\n\"I am still working by evening,\" says [Laura](/company/team/#lauraMon). \"I’ll have a meal around 8pm. If I have plans, I go out, otherwise I play video games. If I get a second wind I’ll work more after 10pm.\"\n\n\"I try to finish my work by 6pm, but if I work overtime then the next day I will have an excuse to relax a little bit! In the evenings, I’ll cook dinner by putting some chicken and veggies into a steamer pot, and then continue working while that cooks, or I will go out for dinner. Sometimes I’ll attend local meetups, or just relax and watch TV. My bedtime is around midnight,\" says [Mark Chao](/company/team/#lulalala_it), backend engineer, [Create](/handbook/engineering/development/dev/create/), from Taipei.\n\n## Focused versus collaborative work\n\nGitLab gives us the flexibility to build a custom schedule, so early birds and night owls can work when they feel they are most effective. When we choose to work in tandem with teammates and when we do our focus work depends primarily upon two factors: When the overlap happens across teams and time zones, and also when we are most focused and/or creative.\n\n\"Europe and the Americas are chatty overnight so I have lots to catch up on in the morning, including the minutes of meetings that happened at 3am (e.g., daily company call),\" says [Charlie](/company/team/#cablett). \"America is still awake so I collaborate with them if I need to, and I do all my deep focus work later on when not many folks are around.\"\n\nThough GitLab has a globally distributed team across 54 countries and regions, the majority of us are based in the United States and Europe.\n\n\"After lunch, I get maybe one more hour of focused work in until 3pm when America wakes up. Then meetings start, Slack gets busy, and then I'm trying to disentangle myself and switch off for the evening,\" says [Rebecca](/company/team/#rebecca). \"If something doesn’t happen before 3pm, it generally doesn’t happen that day.\"\n\n\"In the afternoon for me, people will start to wake up and log on so I will have more interactions and working on issues,\" says [Mark](/company/team/#lulalala_it).\n\nSometimes team members with children will log on to complete a few more hours of work while the children are sleeping, generally between 8pm-10pm, and sometimes after 10pm.\n\n## Family first at GitLab\n\n\"I love working at GitLab for a variety of reasons, but the flexibility in creating work-life harmony in my life tops my list. I work closely with our executive team here, and they have been so supportive and encouraging when family-related conflicts arise. They are constantly reminding me that \"[family first](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second)\" is our mantra, and give me ease of mind to take time away when needed,\" says [Cheri Holmes](/company/team/#cheriholmes), manager, executive assistant, from Dublin, California, in a previous [blog post](/blog/building-an-award-winning-culture-at-gitlab/).\n\nInc. Magazine recently ranked GitLab as one of the [best places to work](/blog/building-an-award-winning-culture-at-gitlab/), due in large part to a company culture that gives team members the agency to balance our personal and professional obligations. While the \"average\" team member may not share a schedule, we do share a commitment to our [values](https://handbook.gitlab.com/handbook/values/#credit): Collaboration, results, efficiency, diversity, iteration, and transparency. In order to work asynchronously effectively, everyone must embrace and embody the values of our organization.\n",[9,998,829,680],{"slug":1835,"featured":6,"template":683},"day-in-the-life-remote-worker","content:en-us:blog:day-in-the-life-remote-worker.yml","Day In The Life Remote Worker","en-us/blog/day-in-the-life-remote-worker.yml","en-us/blog/day-in-the-life-remote-worker",{"_path":1841,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1842,"content":1847,"config":1853,"_id":1855,"_type":13,"title":1856,"_source":15,"_file":1857,"_stem":1858,"_extension":18},"/en-us/blog/debian-customizes-ci-tooling-with-gitlab",{"title":1843,"description":1844,"ogTitle":1843,"ogDescription":1844,"noIndex":6,"ogImage":1367,"ogUrl":1845,"ogSiteName":670,"ogType":671,"canonicalUrls":1845,"schema":1846},"Debian customizes CI tooling with GitLab","Debian developer Santiago Ruano Rincón explains the Linux distribution's custom solution for improving and expediting the open source software packaging process.","https://about.gitlab.com/blog/debian-customizes-ci-tooling-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Debian customizes CI tooling with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Santiago Ruano Rincón\"}],\n        \"datePublished\": \"2023-09-19\",\n      }",{"title":1843,"description":1844,"authors":1848,"heroImage":1367,"date":1850,"body":1851,"category":827,"tags":1852},[1849],"Santiago Ruano Rincón","2023-09-19","\nI still remember the day I broke a widely used critical tool for open source developers around the world.\nAs part of the [Debian Linux distribution project](https://www.debian.org/), I maintain [grep](https://tracker.debian.org/pkg/grep), the GNU/Linux application used to search for text patterns in files.\nI had just uploaded a new Debian release of grep to the Debian archive, when some hours later, a Debian friend called me to let me know other Debian developers were unable to boot their personal computers.\n\nThat was late in 2005 – ever since then I'd wished for a way to prevent that scenario from happening again.\n\nToday, that solution exists.\nIt's part of Salsa, Debian's GitLab implementation, which powers Debian development for more than 900 developers in the global Debian community.\nThanks to GitLab's robust CI/CD functionality, those developers are able to test their packages *before* releasing them to the public Debian archive — saving them from causing the kind of turmoil I accidentally caused.\n\n> [Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n\nIn this article, I'll explain how that tool, called [Salsa CI](https://salsa.debian.org/salsa-ci-team/pipeline/), helps Debian developers using GitLab streamline software development, accelerate package maintenance, and significantly reduce time-consuming re-work.\n\n## Debian with extra Salsa\nSalsa CI is one of the Debian community's custom-built continuous integration tools.\nIt's part of the Debian GitLab instance ([Salsa](https://wiki.debian.org/Salsa)), and helps Debian maintainers manage roughly [9,000 projects](https://codesearch.debian.net/search?q=pipeline-jobs+path%3Adebian%2F.*.yml&literal=0&perpkg=1).\n\n### How Salsa CI works\nAs a Linux distribution, Debian packages open source software from multiple upstream sources. \nWhen new upstream source code is released, maintainers can test that code to ensure it will build and run reliably for Debian users as part of the Debian release cycle.\n* Packages appear first in [Debian Unstable](https://wiki.debian.org/DebianUnstable).\n* If those packages don't introduce regressions or serious bugs, they can migrate to [Debian Testing](https://wiki.debian.org/DebianTesting).\n* When a new Debian release is published, those packages move to [Debian Stable](https://wiki.debian.org/DebianStable).\n\nSalsa CI helps increase the probability that packages can pass from Unstable to Testing reliably, quickly, and without issue.\nIn effect, it emulates the Debian build process, adding several quality checks to identify errors before they would affect Debian users. \nWhen new source code triggers a Salsa CI pipeline, 17 different jobs run to build and test it automatically.\nSalsa CI checks to see whether the to-be-uploaded packages build on multiple architectures (at the moment, amd64 and i386, and optionally on Arm), runs [autopkgtest test suites](https://wiki.debian.org/ContinuousIntegration/autopkgtest) to try to identify potential regressions, and checks for common errors with our custom linter, [lintian](https://wiki.debian.org/Lintian), among other tests.\nYou can view all the details at Debian's public GitLab instance (I maintain the `grep` package for Debian, so I'll offer that one as [an example of Salsa CI in action](https://salsa.debian.org/debian/grep/-/pipelines/576674)).\n\n![An overview of Salsa CI running on Debian's grep package](https://about.gitlab.com/images/blogimages/debian-grep-salsa-overview.png){: .shadow}\n\n## Life before Salsa CI\nMaintainers have been iterating on the Salsa CI pipeline for more than four years now. \nBut I have not forgotten what life as a package maintainer in the Debian community was like without it.\n\nMost of the work Salsa CI performs today is work that community members would otherwise need to perform manually. \nSo it proceeded slowly and was prone to more errors.\nWhile use of Salsa CI isn't compulsory for Debian maintainers, many choose to use it for their work because it saves them an incredible amount of time and effort — and because it leads to fewer breaking packages.\nMaintainers no longer need to run their own package tests locally; instead, Salsa performs this work remotely.\n\nAnd it works quickly.\nIdentifying issues with [Debian's primary CI system](https://ci.debian.net) when testing packages might require several hours, days, or even a month. \nSalsa CI reduces that time horizon to several *minutes* (or hours, in the worst cases), depending on the complexity of the package. For example:\n* Without Salsa CI, maintainers manually upload their packages and must wait for build results from the Debian build network (and they must do this for each architecture they wish to test). Usually, if a build fails, maintainers test on bespoke \"[porterboxes](https://wiki.debian.org/PorterBoxHowToUse)\" tailored to specific architectures. Using Salsa CI, however, maintainers can test x86 and Arm package builds easily — after a single `git push` command.\n\n* Running `autopkgtest` on [ci.debian.net](https://ci.debian.net/) (the official and central CI infrastructure for Debian) tests only the packages that have been built by the build servers and installed in the archive. `autopkgtest` is run for migration reference monthly. In Salsa CI, however, `autopkgtest` runs immediately after the amd64 build job has finished, decreasing review cycle times.\n\n## Salsa CI in the open source ecosystem\nOverall, the Debian community has been pleased with the progress Salsa CI maintainers have made since the tool's creation four years ago.\nOther open source communities are taking notice, too.\nFor instance, Salsa CI has become the basis for even more complex CI pipelines in projects like [Kali Linux](https://go.gitlab.com/G1XROS).\nWe're delighted to see that something we created to solve our own issues and improve our own work is making a positive impact on the open source ecosystem more broadly.\n\n*Editor's note: Debian developers [Alexander Wirt](https://gitlab.com/formorer) and [Otto Kekäläinen](https://gitlab.com/ottok) contributed to this article.*\n\n[Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n{: .note}\n",[1187,266,9],{"slug":1854,"featured":6,"template":683},"debian-customizes-ci-tooling-with-gitlab","content:en-us:blog:debian-customizes-ci-tooling-with-gitlab.yml","Debian Customizes Ci Tooling With Gitlab","en-us/blog/debian-customizes-ci-tooling-with-gitlab.yml","en-us/blog/debian-customizes-ci-tooling-with-gitlab",{"_path":1860,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1861,"content":1867,"config":1874,"_id":1876,"_type":13,"title":1877,"_source":15,"_file":1878,"_stem":1879,"_extension":18},"/en-us/blog/demystifying-ci-cd-variables",{"title":1862,"description":1863,"ogTitle":1862,"ogDescription":1863,"noIndex":6,"ogImage":1864,"ogUrl":1865,"ogSiteName":670,"ogType":671,"canonicalUrls":1865,"schema":1866},"GitLab environment variables demystified","CI/CD variables are useful (and flexible) tools to control jobs and pipelines. We unpack everything you need to know about GitLab environment variables.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","https://about.gitlab.com/blog/demystifying-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab environment variables demystified\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }",{"title":1862,"description":1863,"authors":1868,"heroImage":1864,"date":1870,"body":1871,"category":849,"tags":1872,"updatedDate":1873},[1869],"Veethika Mishra","2021-04-09","There is a lot of flexibility when it comes to defining and using variables for [CI/CD](https://about.gitlab.com/topics/ci-cd/). Variables are extremely useful for controlling jobs and pipelines, and they help you avoid hard-coding values in your `.gitlab-ci.yml` configuration file. The information in this post should weave a larger picture by bringing together all (or most) of the information around defining and handling variables, making it easier to understand the scope and capabilities. Relevant documentation is linked throughout the post.\n\nIn [GitLab CI/CD](https://docs.gitlab.com/ee/ci/), variables can be used to customize jobs by defining and storing values. When using variables there is no need to hard code values. In GitLab, CI/CD variables can be defined by going to **Settings >> CI/CD >> Variables**, or by simply defining them in the `.gitlab-ci.yml` file.\n\nVariables are useful for configuring third-party services for different deployment environments, such as `testing`, `staging`, `production`, etc. Modify the services attached to those environments by simply changing the variable that points to the API endpoint the services need to use. Also use variables to configure jobs and then make them available as environment variables within the jobs when they run.\n\n![GitLab reads the .gitlab-ci.yml file to scan the referenced variable and sends the information to the GitLab Runner. The variables are exposed on and output by the runner.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n## The relationship between variables and environments\n\nSoftware development as a process includes stages to test a product before rolling it out to users. [Environments](https://docs.gitlab.com/ee/ci/environments/) are used to define what those stages look like and it may differ between teams and organizations.\n\nOn the other hand, variables are data values that are likely to change as a result of user interaction with a product. For example, their age, preference, or any input you could possibly think of that might determine their next step in the product task-flow.\n\nWe often hear the term [environment variable](https://docs.gitlab.com/ee/administration/environment_variables.html). These are variables that are defined in a given environment, but outside the application. GitLab CI/CD variables provide developers with the ability to configure values in their code. Using variables is helpful because it ensures that the code is flexible. GitLab CI/CD variables allow users to modify an application deployed to a certain environment without making any change to code. It is simple to run tests or even integrate third-party services by changing a configuration environment variable outside the application.\n\n## The scope of variables for CI/CD\n\n![Order of precedence for CI/CD variables: 1) Manual pipeline run, trigger and schedule pipeline variables, 2) Project level, group level, instance level protected variables, 3) Inherited CI/CD variables, 4) Job level, global yml defined variables, 5) Deployment variables, 6) Pre-defined CI/CD variables](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n### `.gitlab-ci.yml` defined variables\n\nVariables that need to be available in the job environment can be added to GitLab. These CI/CD variables are meant to store non-sensitive project configuration, like the database URL in the `.gitlab-ci.yml` file. Reuse this variable in multiple jobs or scripts, wherever the value is needed. If the value changes, you only need to update the variable once, and the change is reflected everywhere the variable is used.\n\n### Project CI/CD variables\n\nMoving a step above the repository-specific requirements, you can define CI/CD variables in [project settings](https://docs.gitlab.com/ee/ci/variables/#for-a-project), which makes them available to CI/CD pipelines. These are stored out of the repository (not in the `.gitlab-ci.yml` file), but are still available to use in the CI/CD configuration and scripts. Storing the variables outside the `.gitlab-ci.yml` file keeps these values limited to a project-only scope, and not saved in plain text in the project.\n\n### Group and instance CI/CD variables\n\nSome variables are relevant at the group level, or even instance level, and could be useful to all projects in a group or instance. Define the variables in the [group or instance settings](https://docs.gitlab.com/ee/ci/variables/#for-a-group) so all projects within those scopes can use the variables without actually needing to know the value  or having to create the variables for the lower scope. For example, a common value that needs to be updated in multiple projects can be easily managed if it stays up-to-date in a single place. Alternatively, multiple projects could use a specific password without actually needing to know the value of the password itself.\n\n## Jobs and pipelines as environments\n\nGitLab CI/CD variables, besides being used as environment variables, also work in the scope of the `.gitlab-ci.yml` configuration file to configure pipeline behavior, unrelated to any environment. The variables can be stored in the project/group/instance settings and be made available to jobs in pipelines.\n\nFor example:\n\n```  \njob:  \n  rules:  \n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n  script:  \n  - echo \"This job ran on the $CI_COMMIT_BRANCH branch.\"  \n```\n\nThe variable `($CI_COMMIT_BRANCH)` in the script section runs in the scope of the job in which it was defined. This scope is the \"job environment\" – meaning, when the job starts, the GitLab runner starts up a Docker container and runs the job in that environment. The runner will make that variable (and all other predefined or custom variables) available to the job, and it can display their value in the log output if needed.\n\nBut the variable is **also** used in the `if:` section to determine when the job should run. That in itself is not an environment, which is why we call these CI/CD variables. They can be used to dynamically configure your CI/CD jobs, **as well** as be used as environment variables when the job is running.\n\n## Predefined variables\n\nA number of variables are [predefined](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) when a GitLab CI/CD pipeline starts. A user can immediately access values for things like commit, project, or pipeline details without needing to define the variables themselves.\n\n## Custom CI/CD variables\n\n![Runners can create two kinds of custom CI/CD variables: Type and File.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\nWhen creating a CI/CD variable in the settings, GitLab gives the user more configuration options for the variable. Use these extra configuration options for stricter control over more sensitive variables:\n\n**Environment scope:** If a variable only ever needs to be used in one specific environment, set it to only ever be available in that environment. For example, you can set a deploy token to only be available in the `production` environment.\n\n**Protected variables:** Similar to the environment scope, you can set a variable to be available only when the pipeline runs on a protected branch, like your default branch.\n\n**Variable type:** A few applications require configuration to be passed to it in the form of a file. If a user has an application that requires this configuration, just set the type of variable as a \"File\". Configuring the CI/CD variable this way means that when the runner makes the variable available in the environment, it actually writes it out to a temporary file, and stores the path to the file as the value. Next, a user can pass the path to the file to any applications that need it.\n\nAlong with the listed ways of defining and using variables, GitLab introduced a feature that generates pre-filled variables when there's a need to run a pipeline manually. Prefilled variables reduce the chances of running into an error and makes running the pipeline easier.\n\n**Masked variables:** [Masked variables](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) are CI variables that have been **hidden in job logs** to prevent the variable’s value from being displayed. \n\n**Masked and hidden variables:** Introduced in [GitLab 17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#hide-cicd-variable-values-in-the-ui), [Masked and hidden](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable) variables provide the same masking feature from job logs and **keep the value hidden** **in the Settings UI**. We do not recommend using either of these variables for sensitive data (e.g. secrets) as they can be inadvertently exposed. \n\n## Secrets\n\nA secret is a sensitive credential that should be kept confidential. Examples of a secret include:\n\n* Passwords  \n* SSH keys  \n* Access tokens  \n* Any other types of credentials where exposure would be harmful to an organization\n\nGitLab currently enables its users to [use external secrets in CI](https://docs.gitlab.com/ee/ci/secrets/), by leveraging HashiCorp Vault, Google Cloud Secret Manager, and Azure Key Vault to securely manage keys, tokens, and other secrets at the project level. This allows users to separate these secrets from other CI/CD variables for security reasons.\n\n### GitLab Secrets Manager\n\nBesides providing support for external secrets in CI, GitLab is also working on introducing a [native solution to secrets management](https://gitlab.com/groups/gitlab-org/-/epics/10108) to securely and conveniently store secrets within GitLab. This solution will also help customers use the stored secrets in GitLab specific components and environments, and easily manage access at namespace groups and projects level. \n\n## Read more\n* [GitLab native secrets manager to give software supply chain security a boost](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/)\n\n***Disclaimer:** This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.*\n",[1397,9,680,1396,108,746],"2025-01-13",{"slug":1875,"featured":6,"template":683},"demystifying-ci-cd-variables","content:en-us:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","en-us/blog/demystifying-ci-cd-variables.yml","en-us/blog/demystifying-ci-cd-variables",{"_path":1881,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1882,"content":1888,"config":1894,"_id":1896,"_type":13,"title":1897,"_source":15,"_file":1898,"_stem":1899,"_extension":18},"/en-us/blog/dependency-proxy-updates",{"title":1883,"description":1884,"ogTitle":1883,"ogDescription":1884,"noIndex":6,"ogImage":1885,"ogUrl":1886,"ogSiteName":670,"ogType":671,"canonicalUrls":1886,"schema":1887},"Using the Dependency Proxy to improve your pipelines","The Dependency Proxy helps make pipelines faster and mitigates Docker Hub rate limits.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681815/Blog/Hero%20Images/dependency_proxy_header.jpg","https://about.gitlab.com/blog/dependency-proxy-updates","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Using the Dependency Proxy to improve your pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Steve Abrams\"}],\n        \"datePublished\": \"2020-12-15\",\n      }",{"title":1883,"description":1884,"authors":1889,"heroImage":1885,"date":1891,"body":1892,"category":1353,"tags":1893},[1890],"Steve Abrams","2020-12-15","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nHi! I'm Steve, a backend engineer at GitLab. I work on the Package stage, which includes the Dependency Proxy.\n\nIn versions 13.6 and 13.7, we improved the [Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/) so it's no longer an [MVC feature](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc). Before, the Dependency Proxy was only available to paid users who may have been wary to use it, because they did not want to be forced to use a public group. Now the Dependency Proxy is a robust free feature that can really provide value for free and paid users alike.\n\nIf you haven't tried the feature out before, now is a great time to take a look. If you have previously tried the Dependency Proxy and found it was not quite the solution you were looking for, I invite you to take a look at the new functionality detailed here. The Dependency Proxy is more available, more secure, and easier to use than ever. These updates also come right as Docker Hub has rolled out rate limits on image pulls, which the Dependency Proxy can help alleviate.\n\nYou can also watch a demo of most of these features in this video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Nc4nUo7Pq08\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Move to Core\n\nIn 13.6, we moved the [Dependency Proxy to Core](/releases/2020/11/22/gitlab-13-6-released/#the-dependency-proxy-is-now-open-source). The ability to speed up pipelines and create a safety net behind Docker Hub seemed like functionality that everyone should benefit from.\n\n## Support for private groups\n\nStarting in 13.7, you can now use the Dependency Proxy with all groups. Each group and subgroup can have its own space to cache images.\n\n![Dependency Proxy interface](https://about.gitlab.com/images/blogimages/dependency_proxy_interface.png)\n\n## Authentication\n\n[Authentication](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy) is also new in 13.7. If you had previously used the Dependency Proxy, you will need to update your CI scripts or workflow to make sure that you are now logged in.\n\nAuthentication was not only necessary to enable the ability to support private groups with the Dependency Proxy, but it's also a security upgrade. The Dependency Proxy caches image data in your group's storage, so without authentication, public groups could easily be abused to store images that your group might not even be using.\n\n### How does it work\n\nThe Dependency Proxy is a proxy, so from the perspective of the Docker client, it is just another registry to authenticate with:\n\n```shell\ndocker login --username stanley --password tanuki gitlab.com\n```\n\nWhen Docker makes a request to a registry it first asks:\n\n```shell\nGET gitlab.com/v2 # are you a registry?\n```\n\nTo which GitLab responds:\n\n```shell\n401 Unauthorized\n\nWWW-Authenticate: Bearer realm=https://gitlab.com/auth/jwt, service=dependency_proxy\n# Yes! But you have to get permission to access me.\n# Please request a token from this other URL first.\n```\n\nThen Docker requests a token using the username and password you supplied, and if things check out, GitLab returns a JWT. Docker uses it to make its next request, which in the case of the Dependency Proxy is the image pull. If things don't check out, you'll likely see a `403 Forbidden` error.\n\n## Docker Hub rate limiting\n\nIn November 2020, Docker Hub began rate limiting image pulls. The Dependency Proxy was already caching the image layers (blobs), so it made sense that [the Dependency Proxy should help mitigate this problem for users](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#docker-hub-rate-limits-and-the-dependency-proxy).\n\nIt is not uncommon for a project's pipeline to run every time a user pushes a commit. In an active project or group, this could happen many times in an hour. If your CI script starts with something as simple as:\n\n```yaml\nimage: node:latest\n```\n\nEvery time your pipeline runs, even though you are using the same image every time, Docker will count an additional image pull against your account.\n\nAn image consists of many different files, and a `docker pull` command will make several requests. So what counts as one image pull?\n\nThere are two types of files that make up an image. First is the manifest. You can think of it as a table of contents for an image. It contains information about what layers, or blobs, the image is made of. Once the Docker client has received the manifest, it will make a request for each blob described in the manifest.\n\nDocker uses the [manifest requests to count the image pulls](https://docs.docker.com/docker-hub/download-rate-limit/). This means that if the Dependency Proxy is going to help mitigate the rate limiting, it needs to store the manifest in addition to the blobs. This presents a small problem: a manifest is usually requested by tag name, which is a mutable reference. If I request `node:latest` this week, it might be different than the `node:latest` I requested last week. Each manifest contains a digest, or hash signature, that can be used to tell if it has changed. You can see this digest when you pull the image:\n\n```shell\n$ docker pull alpine:latest\n\nlatest: Pulling from library/alpine\nDigest: sha256:a126728cb7db157f0deb377bcba3c5e473e612d7bafc27f6bb4e5e083f9f08c2\nStatus: Image is up to date for alpine:latest\ndocker.io/library/alpine:latest\n```\n\nDocker has allowed HEAD requests to be made for a manifest for free. The HEAD request response contains the digest of the underlying manifest. So we can make a HEAD request to determine if the manifest we have cached in the Dependency Proxy is up to date.\n\n```shell\ncurl --head -H \"Authorization: Bearer $TOKEN\" https://registry-1.docker.io/v2/library/alpine/manifests/latest\n\nHTTP/1.1 200 OK\nContent-Length: 2782\nContent-Type: application/vnd.docker.distribution.manifest.v1+prettyjws\nDocker-Content-Digest: sha256:a126728cb7db157f0deb377bcba3c5e473e612d7bafc27f6bb4e5e083f9f08c2\nDocker-Distribution-Api-Version: registry/2.0\nEtag: \"sha256:a126728cb7db157f0deb377bcba3c5e473e612d7bafc27f6bb4e5e083f9f08c2\"\nDate: Wed, 15 Dec 2020 03:34:24 GMT\nStrict-Transport-Security: max-age=31536000\nRateLimit-Limit: 100;w=21600\nRateLimit-Remaining: 72;w=21600\n```\n\nThe response even contains information telling us how many requests we have remaining within our rate limit. In this example, we see we have 72 out of 100 remaining.\n\nWhen the Dependency Proxy first receives a request for the manifest, it decides whether or not it needs to pull an image from Docker Hub based on a few rules:\n\n![Dependency Proxy manifest caching](https://about.gitlab.com/images/blogimages/dependency_proxy_flow_chart.png)\n\nThe really great thing about the Dependency Proxy is that you don't have to do anything special to take advantage of these abilities. If you simply update your CI script with your Dependency Proxy image prefix to something like:\n\n```yaml\nimage: gitlab.com/super-awesome-group/dependency_proxy/containers/node:latest\n```\n\nThen you will automatically bypass Docker Hub rate limiting and your cache will have the most up-to-date version of each image tag.\n\n## CI/CD\n\nThe Dependency Proxy makes the most sense as a compliment to CI/CD pipelines. Rather than pulling directly from Docker Hub, you can use the Dependency Proxy to speed up your pipelines, avoid rate limiting, and create security in case of an upstream outage.\n\nAs of 13.9, runners log in to the Dependency Proxy automatically, so you don't need to explicitly log in unless you want to for reasons like using specific tokens.\n\nTo make the Dependency Proxy easier to use, we have added a few predefined environment variables you can use in your `.gitlab-ci.yml` files.\n\n- `CI_DEPENDENCY_PROXY_USER`: A CI user for logging in to the Dependency Proxy.\n- `CI_DEPENDENCY_PROXY_PASSWORD`: A CI password for logging in to the Dependency Proxy.\n- `CI_DEPENDENCY_PROXY_SERVER`: The server for logging in to the Dependency Proxy.\n- `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`: The image prefix for pulling images through the Dependency Proxy. This pulls through the top-level group.\n- `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX` (starting in version 14.3): An alternative image prefix for pulling images through the Dependency Proxy. This pulls through the subgroup, or direct group the project exists in.\n\nDepending on how your scripts and pipelines look you can use these variables in a variety of ways. If you are manually pulling images in the script using `docker pull`, you can log in and pull like this:\n\n```yaml\n# .gitlab-ci.yml\n\ndependency-proxy-pull-master:\n  # Official docker image.\n  image: docker:latest\n  stage: build\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u \"$CI_DEPENDENCY_PROXY_USER\" -p \"$CI_DEPENDENCY_PROXY_PASSWORD\" \"$CI_DEPENDENCY_PROXY_SERVER\"\n  script:\n    - docker pull \"$CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX\"/alpine:latest\n```\n\nIf you want to use the Dependency Proxy to pull images defined as `image` yaml attributes (the base images of the script), you can [create a custom environment variable](https://docs.gitlab.com/ee/ci/variables/#custom-cicd-variables) named `DOCKER_AUTH_CONFIG` with a value of:\n\n```yaml\n{\n    \"auths\": {\n        \"https://gitlab.com:443\": { # if you are using $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX, you should explicitely include the port here.\n            \"auth\": \"(Base64 of username:password)\"\n        }\n    }\n}\n```\n\nYou will need to calculate the base64 value of your credentials. You can do this from the command line:\n\n```shell\n# The use of \"-n\" - prevents encoding a newline in the password.\necho -n \"my_username:my_password\" | base64\n\n# Example output to copy\nbXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ==\n\n# A personal access token also works!\necho -n \"my_username:personal_access_token\" | base64\n```\n\nOnce you have the custom environment variable defined, you can use the Dependency Proxy without having to manually log in within your CI script:\n\n```yaml\n# This is a working script that would publish an NPM package to the GitLab package registry\n# if a properly formatted package.json file exists in the project root.\nimage: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/node:latest\n\nstages:\n  - deploy\n\ndeploy:\n  stage: deploy\n  script:\n    - echo \"//gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}\">.npmrc\n    - npm publish\n```\n\n## Support when Docker Hub is offline\n\nBy caching all files that make up an image, we also now have the ability to keep pipelines green even if Docker Hub experiences an outage. As long as the Dependency Proxy has the image you are using cached, when it makes the HEAD request to check if the cached image is stale or not, if the HEAD request fails, we will just fall back to the cached image.\n\nThanks for reading! If you haven't used the Dependency Proxy yet, [get started using it today](https://docs.gitlab.com/ee/user/packages/dependency_proxy/)!\n\n## Updates\n\nSince this was published in December 2020, there have been many additional improvements and changes to the Dependency Proxy. As a result, some of the suggested approaches in this post have been improved or have become outdated. I suggest looking through [the most recent documentation](https://docs.gitlab.com/ee/user/packages/dependency_proxy/) to learn more.\n",[108,9],{"slug":1895,"featured":6,"template":683},"dependency-proxy-updates","content:en-us:blog:dependency-proxy-updates.yml","Dependency Proxy Updates","en-us/blog/dependency-proxy-updates.yml","en-us/blog/dependency-proxy-updates",{"_path":1901,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1902,"content":1908,"config":1915,"_id":1917,"_type":13,"title":1918,"_source":15,"_file":1919,"_stem":1920,"_extension":18},"/en-us/blog/deploy-a-server-using-go-with-gitlab-google-cloud",{"title":1903,"description":1904,"ogTitle":1903,"ogDescription":1904,"noIndex":6,"ogImage":1905,"ogUrl":1906,"ogSiteName":670,"ogType":671,"canonicalUrls":1906,"schema":1907},"Deploy a server using Go with GitLab + Google Cloud","This tutorial shows how to use GitLab’s Google Cloud integration to deploy a Golang server in less than 10 minutes, helping developers become more independent and efficient.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098028/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945_fJKX41PJHKCfSOWw4xQxm_1750098028126.png","https://about.gitlab.com/blog/deploy-a-server-using-go-with-gitlab-google-cloud","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Deploy a server using Go with GitLab + Google Cloud\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Claire Champernowne\"},{\"@type\":\"Person\",\"name\":\"Noah Ing\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":1903,"description":1904,"authors":1909,"heroImage":1905,"date":1912,"body":1913,"category":701,"tags":1914},[1910,1911],"Claire Champernowne","Noah Ing","2025-01-28","Deploying an application to the cloud often requires assistance from production or DevOps engineers. GitLab's Google Cloud integration empowers developers to handle deployments independently. In this tutorial, you'll learn how to deploy a server to Google Cloud in less than 10 minutes using Go. Whether you’re a solo developer or part of a large team, this setup allows you to deploy applications efficiently.\n\n## You'll learn how to:\n\n1. Create a new project in GitLab\n2. Create a Go server utilizing `main.go`\n3. Use the Google Cloud integration to create a Service account\n4. Use the Google Cloud integration to create Cloud Run via a merge request\n5. Access your newly deployed Go server\n6. Clean up your environment\n\n## Prerequisites\n\n- Owner access on a Google Cloud Platform project\n- Working knowledge of Golang\n- Working knowledge of GitLab CI\n- 10 minutes\n\n## Step-by-step Golang server deployment to Google Cloud\n\n### 1. Create a new blank project in GitLab.\n\nWe decided to call our project `golang-cloud-run` for simplicity.\n\n![Create a new blank project in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098035249.png)\n\n### 2. Create a server utilizing this `main.go` demo.\n\nFind the `main.go` demo [here](https://gitlab.com/demos/applications/golang-cloud-run).\n\n```\n// Sample run-helloworld is a minimal Cloud Run service.\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\tlog.Print(\"starting server...\")\n\thttp.HandleFunc(\"/\", handler)\n\n\t// Determine port for HTTP service.\n\tport := os.Getenv(\"PORT\")\n\tif port == \"\" {\n\t\tport = \"8080\"\n\t\tlog.Printf(\"defaulting to port %s\", port)\n\t}\n\n\t// Start HTTP server.\n\tlog.Printf(\"listening on port %s\", port)\n\tif err := http.ListenAndServe(\":\"+port, nil); err != nil {\n\t\tlog.Fatal(err)\n\t}\n}\n\nfunc handler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Hello %s!\\n\", name)\n}\n```\n\n### 3. Use the Google Cloud integration to create a Service account.\n\nNavigate to **Operate \\> Google Cloud \\> Create Service account**.\n\n![Golang tutorial - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098036/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098035250.png)\n\n### 4. Configure the region you would like the Cloud Run instance deployed to.\n\n![Golang tutorial - image10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098035252.png)\n\n### 5. Use the Google Cloud integration to configure Cloud Run via Merge Request.\n\n![Golang tutorial - image4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098035254.png)\n\n### 6. This will open a merge request. Immediately merge the MR.\n\n![Golang tutorial - image6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098036/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098035257.png)\n\nThis merge request adds a CI/CD deployment job to your pipeline definition. In our case, this is also creating a pipeline definition, as we didn’t have one before.\n\n**Note:** The CI/CD variables `GCP_PROJECT_ID`, `GCP_REGION`, `GCP_SERVICE_ACCOUNT`, `GCP_SERVICE_ACCOUNT_KEY` will all be automatically populated from the previous steps. \n\n![Golang tutorial - image7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098035259.png)\n\n### 7. Voila! Check your pipeline and you will see you have successfully deployed to Google Cloud Run utilizing GitLab CI.\n\n![Golang tutorial - image2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098035261.png)\n\n\u003Cbr>\n\n![Golang tutorial - image3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098035262.png)\n\n## 8. Click the Service URL to view your newly deployed server.\n\nAlternatively, you can navigate to **Operate \\> Environments** to see a list of deployments for your environments.\n\n![Golang tutorial - image5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098035264.png)\n\nBy clicking on the environment called **main**, you’ll be able to view a complete list of deployments specific to that environment.\n\n![Golang tutorial - image8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098035/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098035265.png)\n\n## Next steps\n\nTo get started with developing your Go application, try adding another endpoint. For instance, in your `main.go` file, you can add a `/bye` endpoint as shown below (don’t forget to register the new handler function in main!):\n\n```\nfunc main() {\n\tlog.Print(\"starting server...\")\n\n\thttp.HandleFunc(\"/\", handler)\n\thttp.HandleFunc(\"/bye\", byeHandler)\n```\n\n```\nfunc byeHandler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Bye %s!\\n\", name)\n}\n```\n\nYour `main.go` file should now look something like this:\n\n```\n// Sample run-helloworld is a minimal Cloud Run service.\npackage main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\tlog.Print(\"starting server...\")\n\n\thttp.HandleFunc(\"/\", handler)\n\n\thttp.HandleFunc(\"/bye\", byeHandler)\n\n\t// Determine port for HTTP service.\n\tport := os.Getenv(\"PORT\")\n\tif port == \"\" {\n\t\tport = \"8080\"\n\t\tlog.Printf(\"defaulting to port %s\", port)\n\t}\n\n\t// Start HTTP server.\n\tlog.Printf(\"listening on port %s\", port)\n\tif err := http.ListenAndServe(\":\"+port, nil); err != nil {\n\t\tlog.Fatal(err)\n\t}\n}\n\nfunc handler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Hello %s!\\n\", name)\n}\n\nfunc byeHandler(w http.ResponseWriter, r *http.Request) {\n\tname := os.Getenv(\"NAME\")\n\tif name == \"\" {\n\t\tname = \"World\"\n\t}\n\tfmt.Fprintf(w, \"Bye %s!\\n\", name)\n}\n```\n\nPush the changes to the repo, and watch the `deploy-to-cloud-run job` deploy the updates. Once it’s complete, go back to the Service URL and navigate to the `/bye` endpoint to see the new functionality in action.\n\n## Clean up the environment\n\nTo prevent incurring charges on your Google Cloud account for the resources used in this tutorial, you can either delete the specific resources or delete the entire Google Cloud project. For detailed instructions, refer to the [cleanup guide](https://docs.gitlab.com/ee/tutorials/create_and_deploy_web_service_with_google_cloud_run_component/#clean-up).\n\n> Discover more tutorials like this in our [Solutions Architecture](https://about.gitlab.com/blog/tags/solutions-architecture/) area.\n",[703,478,746,1813,701,9],{"slug":1916,"featured":6,"template":683},"deploy-a-server-using-go-with-gitlab-google-cloud","content:en-us:blog:deploy-a-server-using-go-with-gitlab-google-cloud.yml","Deploy A Server Using Go With Gitlab Google Cloud","en-us/blog/deploy-a-server-using-go-with-gitlab-google-cloud.yml","en-us/blog/deploy-a-server-using-go-with-gitlab-google-cloud",{"_path":1922,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1923,"content":1929,"config":1937,"_id":1939,"_type":13,"title":1940,"_source":15,"_file":1941,"_stem":1942,"_extension":18},"/en-us/blog/deploying-application-eks",{"title":1924,"description":1925,"ogTitle":1924,"ogDescription":1925,"noIndex":6,"ogImage":1926,"ogUrl":1927,"ogSiteName":670,"ogType":671,"canonicalUrls":1927,"schema":1928},"Deploying apps to GitLab-managed Amazon EKS with Auto DevOps","A Kubernetes tutorial: Use GitLab AutoDevOps to deploy your applications to Amazon EKS.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666959/Blog/Hero%20Images/gitlab-aws-cover.png","https://about.gitlab.com/blog/deploying-application-eks","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to deploy your application to a GitLab-managed Amazon EKS cluster with Auto DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2020-05-05\",\n      }",{"title":1930,"description":1925,"authors":1931,"heroImage":1926,"date":1933,"body":1934,"category":849,"tags":1935},"How to deploy your application to a GitLab-managed Amazon EKS cluster with Auto DevOps",[1932],"Abubakar Siddiq Ango","2020-05-05","\n\nDeploying an application onto Amazon EKS doesn't have to be painful. In fact, GitLab's [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) function makes it easy for developers to deploy applications from GitLab onto any cloud. In this tutorial, I break down how to deploy a simple ruby Hello, World application onto our GitLab-managed Amazon EKS cluster, which we created earlier ([read part one to learn how](/blog/gitlab-eks-integration-how-to/)). For the tutorial, I integrated GitLab with Amazon EKS in a GitLab group I created purposely for this, so all the projects created in the group can use the integration without any extra configuration. \n\nIn the previous blog post, we saw how seamless it is to create a Kubernetes cluster on Amazon EKS in GitLab with the right permissions. Developer productivity is greatly improved because there is no more need to manually set-up clusters and the same cluster can be used for multiple projects when Amazon EKS is integrated with GitLab at the group and instance levels, thus making onboarding new projects a breeze.\n\nIn this tutorial, we will be deploying a simple ruby Hello World application to our GitLab-managed Amazon EKS cluster. For the purpose of this tutorial, I have integrated GitLab with Amazon EKS at the group level on a group I own on GitLab.com, this way all projects created in the group can make use of the integration with no extra configuration.\n\n## A few things to note about AutoDevOps\n\nAuto DevOps provides pre-defined [CI/CD configuration](/topics/ci-cd/) which allows you to automatically detect, build, test, deploy, and monitor your applications. All you need to do is push your code and GitLab does the rest, saving you a lot of effort to set up the workflow and processes required to build, deploy, and monitor your project.\n\nYou'll need to execute the following steps for GitLab AutoDevOps to work seamlessly:\n\n* A [base domain](https://docs.gitlab.com/ee/user/project/clusters/#base-domain) name needs to be provided on GitLab’s integration page for Amazon EKS.\n\n ![AutoDevOps Base Domain](https://about.gitlab.com/images/blogimages/deploying-application-eks/base-domain.png){: .shadow.medium.center}\n Setting the base domain for Auto DevOps\n{: .note.text-center}\n\n* GitLab creates subdomains for every project that is deployed using the project slug, project ID and the base domain name. For example, the link `https://abubakar-te-demos-minimal-ruby-app-2.eksdemo-project.gitlabtechevangelism.net/` is automatically created where `abubakar-te-demos-minimal-ruby-app` is the project slug and the project ID of two, both prepended to the base domain name, `eksdemo-project.gitlabtechevangelism.net`.\n\n* Create a wildcard A-record for the base domain and point it to the Ingress endpoint created during the integration in the public-hosted zone of your domain name on Route53. Selecting the ALIAS option in Route 53 will present a list of resources you have already created. You will see your Ingress endpoint in the list of elastic load balancers. Alternatively, you can copy and paste from GitLab’s integration page.\n\n ![Route53 Alias for base Domain](https://about.gitlab.com/images/blogimages/deploying-application-eks/route53.png){: .shadow.small.center}\n Set-up alias for base domain using the generated Ingress endpoint.\n{: .note.text-center}\n\n* Install the pre-defined Kubernetes certificate management controller, certmanager on the GitLab - EKS integration, to ensure every URL created for your application has a Let’s Encrypt certificate.\n\n## Now, lets deploy our application\n\n### How to set-up the project\n\nIt takes five simple steps to set-up the project for your application.\n\nFirst, create a GitLab project from an existing sample, in this case, GitLab’s Auto DevOps example called Minimal Ruby App. There is nothing special about this application, it's just a ruby application you can use to try out the integration. If you integrated Amazon EKS at the group level on GitLab, you can just go ahead to create the project in the group. At the project level, you will have to perform the integration after creating the project.\n\nNext, copy the URL from the “Clone with HTTPS” field of the sample project, Minimal Ruby App:\n\n  ![Cloning over HTTPS](https://about.gitlab.com/images/blogimages/deploying-application-eks/https-clone.png){: .shadow.small.center}\n  The clone sample project.\n{: .note.text-center}\n\nThird, click the \"import project\" tab on the new project page, then click on the \"repo by URL\" button. Paste the URL you copied earlier in the text box for \"Git repository URL\" and click on \"create project\"\n\n  ![Importing Project](https://about.gitlab.com/images/blogimages/deploying-application-eks/import-project.png){: .shadow.medium.center}\n  The progress of the sample project import.\n  {: .note.text-center}\n\nNext, the project will be imported and all the files from the sample will be available in your new project.\n\n  ![Project import progress](https://about.gitlab.com/images/blogimages/deploying-application-eks/import-progress.png){: .shadow.medium.center}\n  The project import is completed.\n  {: .note.text-center}\n\nFinally, go to project settings > CI/CD > Auto DevOps and enable “Default to Auto DevOps pipeline”\n\n  ![Project Settings](https://about.gitlab.com/images/blogimages/deploying-application-eks/project-settings.png){: .shadow.medium.center}\n  Enable the Auto DevOps pipeline.\n  {: .note.text-center}\n\n### How to deploy your application\n\n* Now a pipeline is created and the project built, tested and deployed to production using the [default AutoDevOps CI files](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml).\n\n  ![Project Pipeline](https://about.gitlab.com/images/blogimages/deploying-application-eks/pipeline.png)\n  The first Auto DevOps pipeline.\n  {: .note.text-center}\n\n* Look inside the pipeline output to see the \"deployment to production\" line. This is where the URL is to access your application.\n\n  ![Deployment to production](https://about.gitlab.com/images/blogimages/deploying-application-eks/production-deploy.png)\n  Next, link to the deployed application.\n  {: .note.text-center}\n\n* In the image above, you can see the application has been deployed and can be accessed at `https://abubakar-te-demos-minimal-ruby-app-1.eksdemo-project.gitlabtechevangelism.net/`\n\nAnd it should show a “Hello World” message:\n\n  ![Deployed Application](https://about.gitlab.com/images/blogimages/deploying-application-eks/hello-world.png){: .shadow.medium.center}\n  The deployed application with \"Hello World\" message.\n  {: .note.text-center}\n\n## How to make changes to the deployed application\n\nIf any new changes are pushed, a different set of jobs is run to build, test, and review the changes before they can be merged to the master branch. I changed the \"Hello World\" text in the previous deployment to an HTML text in a new Git branch called `amazon-eks-html` using the GitLab WebIDE tool, and committed the changes.\n\n  ![Make changes to application](https://about.gitlab.com/images/blogimages/deploying-application-eks/new-commit.png)\n  Making new changes to application.\n  {: .note.text-center}\n\nWhile committing the changes, I selected \"start a new merge request (MR),\" which took me to the MR page where I added more information about the changes in a new MR.\n\n  ![New Merge request](https://about.gitlab.com/images/blogimages/deploying-application-eks/new-mr.png)\n  The MR to deploy the new application.\n  {: .note.text-center}\n\nIn the image above, you can see a pipeline is created to build, test and deploy using [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) to allow you review the changes before deploying to production.\n\n  ![New MR pipeline test](https://about.gitlab.com/images/blogimages/deploying-application-eks/new-mr-test.png)\n  MR with Review Apps\n  {: .note.text-center}\n\nOnce the review is finished, the application is deployed to a dedicated namespace in the Amazon EKS cluster for you to review before deploying to production. A URL for the [Review App](https://docs.gitlab.com/ee/ci/review_apps/) is provided, as shown in the image below.\n\n  ![Review Applications](https://about.gitlab.com/images/blogimages/deploying-application-eks/review-apps.png){: .shadow.medium.center}\n  The application in the Review App.\n  {: .note.text-center}\n\nThe `stop_review` job cleans up the Review App once the review is done. If MR approvals are required, the MR must be approved before being merged into the master branch. Once merged to master, the project is built, tested, and deployed to production.\n\n  ![Merged Change MR](https://about.gitlab.com/images/blogimages/deploying-application-eks/merged-mr.png){: .shadow.medium.center}\n  Deploying changes to production.\n  {: .note.text-center}\n\nThe image above shows that a second pipeline ran after the MR was merged. Once completed, a button is provided to `view app` and also see memory consumption as the app runs. The `view app`\"` button will open the application on the project's subdomain.\n\n  ![Updated application](https://about.gitlab.com/images/blogimages/deploying-application-eks/updated-site.png)\n  Changes deployed to production.\n  {: .note.text-center}\n\n## Deploy to Amazon EKS with Auto DevOps\n\nThe Auto DevOps function at GitLab makes deploying an application to the Amazon EKS cluster quite simple. Really, all you need to do is push code, and Auto DevOps automatically detects the programming language and uses the necessary [buildpack](https://buildpacks.io/) to test, build, and deploy your application. GitLab also takes making changes to your application a step further using Review Apps, which deploys your app to a temporary environment for you to review the app before deploying to production.\n\nIf you have questions about how to integrate GitLab with Amazon EKS to create a Kubernetes cluster, revisit the [first blog post](/blog/gitlab-eks-integration-how-to/).\n",[1936,9,976,746],"kubernetes",{"slug":1938,"featured":6,"template":683},"deploying-application-eks","content:en-us:blog:deploying-application-eks.yml","Deploying Application Eks","en-us/blog/deploying-application-eks.yml","en-us/blog/deploying-application-eks",{"_path":1944,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1945,"content":1951,"config":1957,"_id":1959,"_type":13,"title":1960,"_source":15,"_file":1961,"_stem":1962,"_extension":18},"/en-us/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast",{"title":1946,"description":1947,"ogTitle":1946,"ogDescription":1947,"noIndex":6,"ogImage":1948,"ogUrl":1949,"ogSiteName":670,"ogType":671,"canonicalUrls":1949,"schema":1950},"Detect application vulnerabilities with GitLab’s browser-based DAST","Learn why you should include dynamic application security testing as part of a defense-in-depth strategy for software development, and how to migrate from proxy-based DAST.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664923/Blog/Hero%20Images/security-checklist.png","https://about.gitlab.com/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Detect application vulnerabilities with GitLab’s browser-based DAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Meadzinger\"}],\n        \"datePublished\": \"2024-05-13\",\n      }",{"title":1946,"description":1947,"authors":1952,"heroImage":1948,"date":1954,"body":1955,"category":704,"tags":1956},[1953],"Sara Meadzinger","2024-05-13","Proxy-based dynamic application security testing was removed in GitLab 17.0 (May 16, 2024) and replaced with GitLab's proprietary [DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/) tool (formerly called “browser-based DAST”). DAST runs automated penetration tests to find vulnerabilities in your web applications as they are running. DAST automates a hacker’s approach, simulates real-world attacks, and can identify critical threats such as cross-site scripting, a SQL injection, and cross-site request forgery. DAST is completely language-agnostic and examines your application from the outside in. \n\nWe recommend adding [DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/) to your software development security alongside other foundational [application security](https://docs.gitlab.com/ee/user/application_security/) testing such as secret detection, dependency scanning, static application security testing (SAST), container scanning, and API security testing. Including DAST in this defense-in-depth approach ensures that your team can identify and mitigate the runtime vulnerabilities and misconfigurations DAST detects that other security tools cannot detect. With a running application in a test environment, DAST scans can be automated in a CI/CD pipeline, automated on a schedule, or run independently by using [on-demand scans](https://docs.gitlab.com/ee/user/application_security/dast/on-demand_scan.html). Read on to learn how to migrate to GitLab DAST, or how to get started if you aren’t already using this security feature.\n\n## Our decision to remove proxy-based DAST\n\nRemoval of support for proxy-based DAST in 17.0 was [announced in 16.6](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#proxy-based-dast-deprecated). Proxy-based DAST was introduced in GitLab 10.4 (January 2018), and its foundation was the open source Zed Attack Proxy (ZAP) project. At the time, this provided great dynamic analysis within GitLab’s DevSecOps platform. Over time, however, the architecture of apps evolved and web applications grew in complexity. [Legacy DAST crawlers](https://en.wikipedia.org/wiki/Single-page_application#Security_scanning), including proxy-based DAST, couldn’t provide sufficient coverage of modern applications so we began developing our modern, proprietary DAST solution. GitLab’s new DAST offering uses a browser to fully navigate the website like a real user while uncovering vulnerabilities. GitLab DAST runs on either arm64 or amd64 architectures, and a FIPS-compliant version is available as well. Our [Vulnerability Research](https://handbook.gitlab.com/handbook/engineering/development/sec/secure/vulnerability-research/) team wrote GitLab’s DAST detections and regularly updates our vulnerability definitions to ensure \n\n## DAST migration information\n\nIf you are using proxy-based DAST to run a scan in a CI/CD pipeline, we recommend migrating to [DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/) to continue dynamically scanning your web applications for vulnerabilities.  Follow the configuration recommendations outlined in the [DAST Migration Guide](https://docs.gitlab.com/ee/user/application_security/dast/proxy_based_to_browser_based_migration_guide.html) to ensure GitLab DAST scans can continue successfully.\n\nIf you would like to continue using proxy-based DAST, you can do so until GitLab 18.0 (May 2025). Bugs and vulnerabilities in this legacy analyzer will not be fixed. To continue using the non-supported proxy-based DAST, set the CI/CD variable \u003CDAST_VERSION:4> .\n\nIf you are using on-demand DAST scans, they automatically began using the newer DAST analyzer (effective from the third GitLab 17.0 breaking change window, 2024-05-06 09:00 UTC to 2024-05-08 22:00 UTC), without any required action on your part.\n\n## Migrate to GitLab DAST\n\nIf you aren’t using DAST yet, you can either run automatic DAST scans that are initiated by a merge request, or you can run manual on-demand DAST scans. \n\nTo enable automated scans, follow these simple [getting started](https://docs.gitlab.com/ee/user/application_security/dast/#getting-started) steps:\n1. Edit your `.gitlab.ci.yml` file to include the DAST template \u003CDAST.gitlab-ci.yml>\n1. Add a DAST stage to the CI/CD pipeline definition. This should be added after the deploy step.\n1. Define the URL to be scanned by DAST by using one of these methods:\nSet the \u003CDAST_TARGET_URL> variable. If set, this value takes precedence\nAdd the URL in a \u003Cenvironment_url.txt> file at your project’s root\n1. [Configure authentication](https://docs.gitlab.com/ee/user/application_security/dast/browser/configuration/authentication.html) to ensure DAST can crawl as much of your application as possible.\n\nA basic configuration for an application with a single-step login form might look like this:\n\n```\ninclude:\n  - template: DAST.gitlab-ci.yml\n\ndast:\n  variables:\n    DAST_TARGET_URL: \"https://example.com\"\n    DAST_AUTH_URL: \"https://example.com/login\"\n    DAST_AUTH_USERNAME_FIELD: \"css:[name=username]\"\n    DAST_AUTH_PASSWORD_FIELD: \"css:[name=password]\"\n    DAST_AUTH_SUBMIT_FIELD: \"css:button[type=submit]\"\n```\n\nTo run DAST scans manually outside of the DevOps lifecycle, follow these steps to [create an on-demand scan](https://docs.gitlab.com/ee/user/application_security/dast/on-demand_scan.html#create-an-on-demand-scan).\n\n## How DAST works\n\nOnce a DAST scan has been triggered, the following steps occur:\n1. Authenticate - If you have configured authentication, the analyzer will authenticate to allow maximum crawling coverage. If authentication fails, the scan halts.\n1. Discovery - The crawler discovers the surface area of the target application by performing user actions like following links, clicking buttons, and filling out forms.\n1. Passive checks - Identifies vulnerabilities in HTTP messages and pages discovered while crawling. These are enabled by default.\n1. Active checks - Identifies vulnerabilities by injecting payloads into HTTP requests recorded during the crawl phase. DAST:\n- analyzes HTTP requests for injection locations (including but not limited to query values, header values, cookie values, form posts, JSON string values, and XML entities)\n- injects attack payloads into those locations and analyzes the HTTP responses to determine attack success and report vulnerabilities\n\nActive checks are disabled by default due to the nature of their probing attacks. Scan results should be reviewed via the [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/index.html) to prioritize and remediate the detected vulnerabilities. \n\n## DAST benefits\n\nHere are some of the benefits of incorporating DAST into your software development lifecycle:\n- simulates real-world hacking on running applications (pre-production versions recommended only)\n- produces high-confidence, low false-positive findings\n- identifies 9/10 of the OWASP Top 10:2021 (dependency scanning covers the 10th)\n- detects CWEs and provides developers and security teams with remediation guidance before your code goes into production\n- does not analyze source code, so scans are not limited by programming language or framework\n- has a FIPS Compliant analyzer available, ensuring data is protected at rest and at transit according to the Federal Information Processing Standard \nsupports complex, multi-step sign-in workflows\n- utilizes a headless browser to provide excellent crawling coverage and execute all client-side scripting interactions for modern web applications, including SPAs\n\n## Get started today\n\nGitLab DAST is an essential tool to include in your comprehensive security testing program. Our latest crawler provides excellent security coverage of modern applications, whether they are stateless or stateful single-page web apps).  Use DAST in conjunction with GitLab’s other security analyzers to remain compliant with numerous standards, reduce business risk, and detect and remediate cyber threats prior to releasing them into production.\n\n> Sign up for a free 30-day trial of GitLab Ultimate to [get going with GitLab DAST](https://about.gitlab.com/free-trial/devsecops/).\n\n## Additional resources\n- [DAST Migration Guide](https://docs.gitlab.com/ee/user/application_security/dast/browser_based_4_to_5_migration_guide.html)\n- [Tips to configure browser-based DAST scans](https://about.gitlab.com/blog/tips-to-configure-browser-based-dast-scans/)\n- [Introducing browser-based DAST and integrated passive checks](https://about.gitlab.com/blog/browser-based-dast-feature-announcement/)\n- [Introducing GitLab browser-based active checks in DAST](https://about.gitlab.com/blog/dast-release-first-gitlab-active-check/)\n",[704,1124,9,701],{"slug":1958,"featured":90,"template":683},"detect-application-vulnerabilities-with-gitlabs-browser-based-dast","content:en-us:blog:detect-application-vulnerabilities-with-gitlabs-browser-based-dast.yml","Detect Application Vulnerabilities With Gitlabs Browser Based Dast","en-us/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast.yml","en-us/blog/detect-application-vulnerabilities-with-gitlabs-browser-based-dast",{"_path":1964,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1965,"content":1971,"config":1977,"_id":1979,"_type":13,"title":1980,"_source":15,"_file":1981,"_stem":1982,"_extension":18},"/en-us/blog/dev-strategy-review",{"title":1966,"description":1967,"ogTitle":1966,"ogDescription":1967,"noIndex":6,"ogImage":1968,"ogUrl":1969,"ogSiteName":670,"ogType":671,"canonicalUrls":1969,"schema":1970},"Tell us what you think about our Dev strategy","Take a look at how we're going to help you better manage, plan, and create.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668253/Blog/Hero%20Images/pencil2.jpg","https://about.gitlab.com/blog/dev-strategy-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tell us what you think about our Dev strategy\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Pundsack\"}],\n        \"datePublished\": \"2019-12-04\",\n      }",{"title":1966,"description":1967,"authors":1972,"heroImage":1968,"date":1974,"body":1975,"category":298,"tags":1976},[1973],"Mark Pundsack","2019-12-04","\n\nThis is the first in a series of posts diving into our strategy and plans for the GitLab product. This post focuses on the [Dev section](/handbook/product/categories/#dev-section) and is an excerpt of our public [direction page for Dev](/direction/dev/), which you can read for more detail. You can also watch our director of product for Dev, [Eric Brinkman](/company/team/#ebrinkman) present the strategy below. When you're done reading (or watching), please give us your feedback via the [survey](#survey) below!\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/mIpHEbyhsj0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n![Dev Overview](https://about.gitlab.com/images/direction/dev/dev-overview.png)\nSee how the GitLab product team plans to advance our Dev strategy over the next 12 months to three years.\n{: .note.text-center}\n\n## Overview of our Dev product\n\nBefore we dive into the our vision for the future of Dev at GitLab, we're providing some more context on our product and how it fits into the market.\n\nThe Dev section is made up of the [Manage](/handbook/product/categories/#manage-stage), [Plan](/handbook/product/categories/#plan-stage), and [Create](/handbook/product/categories/#create-stage) stages of the DevOps lifecycle. These stages mark the leftmost side of the DevOps lifecycle and primarily focus on the creation and development of software. The scope for Dev stages is wide and encompasses a number of analyst categories including [value stream management](/solutions/value-stream-management/), project portfolio management, enterprise agile planning tools, source code management, IDEs, design management, and even ITSM. It is difficult to truly estimate the total addressable market (TAMkt) for the Dev section, as our scope includes so many components from various industries, but research indicates the estimated [TAM](https://docs.google.com/spreadsheets/d/1HYi_l8v-wTE5-BUq_U29mm5aWNxnqjv5vltXdT4XllU/edit?usp=sharing) in 2019 is roughly ~$3B, growing to ~$7.5B in 2023 (26.5% CAGR).\n\nBased on [DevOps tool revenue](https://drive.google.com/file/d/1VvnJ5Q5PJzPKZ_oYBHGNuc6D7mtMmIZ_/view) at the end of 2018 and comparing to GitLab annual recurring revenue at the end of FY20 Q3, our estimated market share is approximately 1.5% based on revenue. (Note: this assumes we can attribute 100% of GitLab revenue to Dev stages.) Market share based on source code management is somewhere in the [30%](https://docs.google.com/document/d/15TLEUc9BxiiB9N33MW-7zGvfitfFXQj3TM8BfM2q4hM/edit?usp=sharing) range.\n\nNearly [half of organizations](https://drive.google.com/file/d/17ZSI2hGg3RK168KHktFOiyyzRA93uMbd/view?usp=sharing) still have not adopted DevOps methodologies, despite [data](https://drive.google.com/file/d/17MNecg84AepxWlSDB5HjNBrCJggaS9tP/view?usp=sharing) that indicates far higher revenue growth for organizations that do adopt these strategies. Migrating a code base to a modern, Git-backed source control platform like GitLab can often be the first step in a DevOps transformation. As such, we must provide industry-leading solutions in source code and code review, as this is not only the entry into DevOps for our customers, but typically the entry into the GitLab platform. Once a user has begun using repositories and code review features like merge requests, they often move “left” and “right” to explore and use other capabilities in GitLab, such as CI and project management features.\n\nPer our stage monthly active user data, the GitLab stages with the highest useage are Manage and Create. As such, these stages must focus on security fixes, bug fixes, performance improvements, UX improvements, and depth more than other areas of GitLab. Plan, while introduced in 2011 with the release of issue tracking, still falls far behind market leaders who have better experiences for sprint management, portfolio management, roadmapping, and workflows.\n\nOther areas, such as value stream management, are nascent to both GitLab and the market and will require more time devoted to executing problem and solution validation discovery.\n\nOver the next year, Dev will require focus on both breadth and depth activities, and each stage will require significant investment to accelerate the delivery of security issues, performance issues, and direction items.\n\n## Vision themes\n\nOur vision for the Dev section is to provide the world’s best product creation platform. We believe we have a massive opportunity to change how cross-functional, multi-level teams collaborate by providng an experience that breaks down organizational silos and enables better collaboration. We want to deliver a solution that enables higher-quality products to be created faster. The following themes are listed below to surface our view of what will be important to the market and to GitLab over the next three to five years. As such, they will be the cornerstone of our three-year strategy, and all activities in the one-year plan should advance GitLab in one or more of these areas.\n\n### Efficient and automated code review\n\nCode review should be a delightful experience for all involved in the process. Over time, we expect the code review process to evolve from where it is today to become a mostly automated process. Along the way, incremental improvements will occur, where developer platforms like GitLab will focus on performance and usability of the code review tools. Code review should be an efficient process, and the easier GitLab can make code review, the more efficient Dev teams become. [Research indicates that better code review should reduce the number of bugs](https://blog.semmle.com/code-review-metrics/) and increase the amount of higher-quality features an organization can ship. The code review process will continue to provide a venue for developers to learn and collaborate together.\n\nFor example, GitLab will:\n\n* Load large, multi-file diffs faster than any other comparable product on the market.\n* Provide tailored insights to the code reviewer, alerting them to the most important areas to review.\n* Allow for client- and server-side evaluation of code where possible, and integrate it into the code review process.\n\n### Measurement and increased efficiency of the value stream\n\nPeter Drucker has said “[If you can’t measure it, you can’t improve it](https://guavabox.com/if-you-cant-measure-it-you-cant-improve-it/)”. Many Dev teams have no way of measuring their efficiency, and even if they do, there is not enough feedback, information, or actionable insights to improve the efficiency of their team. Even then, once efficiency is improved, it can be difficult to tell if a team’s performance is good or bad, as there is often no point of comparison. Even the best performing team in an organization could be worse than the competition. Increasing efficiency is paramount to companies increasing their **time to value** and helping organizations answer **“Is my DevOps transformation working?”**\n\nWe believe efficiency can be improved in two ways. The first way is by improving existing value stream activities and making them more efficient. This focuses on making existing activities as fast as possible. The second way is to question and change the value stream into higher value-added activities at each step. GitLab’s vision is to help answer both of these questions: “Am I doing things fast enough?” and “Am I doing the right things?”\n\nToday, value stream management is largely focused on visualizing the value chain through deployment. GitLab is uniquely positioned to also visualize, track, and measure value chain activities to the right of deployment. For example, the value created by post-launch activities, such as press releases, blog posts, and marketing campaigns should funnel into value stream management, while providing the business with the right data and insights for their value chain.\n\nFor example, GitLab will provide:\n\n* Easy-to-use and customizable tools that measure the efficiency of the DevOps lifecycle.\n* Insight into areas of waste where teams can improve.\n* Recommendations based on large data sets of other teams using GitLab, for comparison.\n* A visual experience for value stream management that goes beyond code deployment.\n\n### DevOps for more personas\n\nDevOps started with the merging of Development and Operations and has since been augmented to include Security in some circles, [highlighting DevSecOps as the next trend](/topics/devsecops/). There are many other personas that are involved in software development, such as product managers, project managers, product designers, finance, marketing, procurement, etc. These personas will continue to expand until nearly every role at knowledge-work companies touches some facet of the DevOps lifecycle. Over time, organizations will realize that teams who work out of the same platform/set of tools are more efficient and deliver faster business and customer value.\n\nBecause of this trend, each persona of the DevOps lifecycle should ultimately be treated as a first-class citizen in GitLab.\n\nFor example, GitLab will provide:\n\n* A better experience for project management workflows.\n* A space for product designers to design and collaborate on designs with product managers and engineers.\n* A Web IDE experience that is able to run the GDK, serving collaborators of all skill sets and hardware, allowing them to contribute to GitLab.\n\n### Enterprise digital transformation\n\nWhile we will continue to solve for the [modern DevOps use case first](/handbook/product/product-principles/#modern-first), most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible [DevOps platform](/solutions/devops-platform/) that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a [“convention over configuration”](/handbook/product/product-principles/#convention-over-configuration) approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.\n\nAdditionally, compliance, auditing, and surfacing evidence of security/compliance posture will become more important as more GDPR-like legislation is enacted and passed into law. GitLab should make it easy to not only surface and deliver evidence for GitLab controls (i.e., who has access to GitLab, who did what on what group, etc.), but also to track and manage compliance requirements for various legislation our customers may be bound to.\n\nAs examples, GitLab will provide:\n\n* Customizable workflows, unlocking enforcement, approvals, and insight into these workflows.\n* More customizable and fine-grained permissions.\n* Logs for everything that’s done within GitLab and allow those events to be accessible via the API and UI.\n* Alerting on GitLab audit events.\n\n### Project management morphs into product management\n\nProduct managers often struggle with answering the question, \"Is the product or feature I just launched successful?\". There are many sensing mechanisms to help answer this question, including revenue, users, customer feedback, NPS, etc., but there is currently no product that helps product managers exhaustively manage the product development lifecycle from end to end. Many products assist with planning, delivery of code, and deployment, but feedback and iteration are equally as important to product managers as shipping the first iteration. Getting the first iteration out is traditionally celebrated, but is only one of many steps to true product development lifecycle management.\n\nImagine an experience where product managers can log in and view the \"health\" of their entire portfolio on one dashboard. It is clear which features have the most value to customers (and by extension to the business) as measured by key metrics, assisting PMs with priortization activities. PMs can quickly identify features or products within their portfolio that need more attention and drill into them, identifying the correct next action to take, whether it's iteration on the feature or perhaps sunsetting it. PMs can quickly create an issue for the next iteration, use version control features, view security incidents, respond to customer feedback, drill down into analytics, control A/B tests of the feature, and even interact with users of the feature or product directly by creating ad-hoc surveys or questions for users to answer. Additionally, the experience should allow for ROI analysis and tracking of the ROI after capital has been expended.\n\nWithin three years, project management tools will begin evolving to provide this experience and help PMs answer tough product questions. These tools will also assist with measuring and predicting value to the organization, if a specific action is prioritized by the PM. The ideal solution most likely uses data science and predictive analytics to assist product managers with decisions both before and after a feature is launched.\n\nAs examples, GitLab will provide:\n\n* Feature management capabilities, including the ability to manage a feature as an object inside of GitLab that lives on after an issue is closed.\n* An experience where PMs can quickly analyze the health of all relevant features.\n* A framework that helps PMs with prioritization decisions.\n* A framework for ROI analysis and measurement.\n\n## Our three-year strategy\n\nIn three years, the Dev section market will:\n\n* Centralize around Git as the version control of choice for not only code, but for design assets, gaming, silicon designs, and AI/ML models.\n* Have a market leader emerge in the value stream management space. Currently, the market is fragmented with most players focused on integrations into various DevOps tools.\n* Adopt a mindset shift from project management to product management.\n* Recognize the value of a single platform for all software creation activities, including product management.\n* See an uptick in startups and applications being built on the backs of a \"no code\" framework\n\nConsidering the evolution of the Dev section market, in three years, GitLab will:\n\n* Provide a next-generation, highly performant Git-backed version control system for large assets, such as ML models. Our goal in three years should be to host the most repositories of these non-code assets.\n* Emerge as the leader in VSM and be recognized in the industry by customers and analysts as such. Our goal in three years should be to provide the best insights into the product development process that no other tool can come close to, as we have a [unified data model](https://www.ca.com/en/blog-itom/what-is-a-unified-data-model-and-why-would-you-use-it.html) due to GitLab being a single platform.\n* Develop an industry-leading product management platform where multiple features and products can be measured and managed easily.\n* Research and potentially add capabilities for \"no code\" workflows.\n\n## Our one-year plan: What’s next for Dev\n\nOver the next 12 months, each stage in the Dev section will play an integral part in this strategy.\n\nPlease see the [categories page](/handbook/product/categories/#dev-section) for a more detailed look at Dev's plan by exploring `Strategy` links in areas of interest.\n\n### Manage\n\n**Enterprise readiness:** GitLab must be seen as a platform that enterprises can use out-of-the-box for both GitLab.com and self-managed deployments. We're doing this by focusing on improvements in several key areas:\n\n  * Enterprise-grade authentication and authorization. Critical for large organizations managing users at scale, we're focused on investing in SAML SSO that works across a range of identity providers and automates member management.\n  * Improving tools that help compliance-minded organizations thrive. GitLab makes it easy to contribute, but administrators should have comprehensive and consistent views on instance activity. We'll improve audit management to a lovable category and introduce dashboarding and alerting to help tell your compliance story to stakeholders. We'll also solve a pronounced need for fine-grained member permissions.\n\n**Lowering time to production for our customers:** Improvements to productivity and code analytics over the next 12 months will allow our customers to drill down and identify sources of waste in their existing process. Within 12 months, GitLab customers will be able to answer how much their time-to-production metrics have improved.\n\n**A great import experience:** Few instances start from scratch – for most, one of the earliest tasks for a GitLab administrator is importing information from outside the application. We'll invest heavily in a strong import user experience and build bespoke importers for key competitors like Jenkins and Jira. We'll also expand on the capabilities of our existing importers, with a focus on making GitLab.com migration easy.\n\n### Plan\n\n\n\n**Kanban boards**: Current project management tools are capable, but suffer from usability. Trello made significant gains by focusing on the user experience. Unfortunately, Trello chose to be a general tool which left some software teams wanting features designed specifically to help with software development and delivery. GitLab has an opportunity to re-design Kanban boards for software teams – think of how Jira could work if it were designed by Trello as opposed to the other way around. Our boards need to evolve to be a primary interface, a complete WYSIWYG document view where everyone who is looking on board X is seeing the same thing (updated in real time), with rich interaction without having to leave the board. This may include changes such as having short summaries, first-class checklists, quick filters, etc. In addition, boards need to focus on common workflows of software teams such as issue triage, daily workflow, sprint planning, quarterly planning, executive reporting, etc.\n\n**Importing from Jira without losing required data**: In the next 12 months, we will deliver enforced workflows, a better roadmap experience, cumulative flow diagrams, and improvements to boards in order to enable a better planning and project management experience.\n\n**Enhancing portfolio and project roadmaps**: Provide easy-to-use, cross-team roadmaps at the portfolio, project, and epic level that allow users across the organization to see how work is progressing and identify dependencies and blockers. Organize and prioritize work though dynamic roadmaps in real time.\n\n**Easy top-down planning**: Enhanced portfolio management experience allowing customers to start planning from the top: Creating initiatives, projects, and epics while laying them out on a roadmap prior to the creation of issues and milestones. Provide analytics at each level, and allow linking of each object to provide deeper dependency mapping across multiple teams and projects. Enable users to create strategic initiatives and assign work, impact, and resources to each to help them make the right business decisions. Additionally, in order for our users to get more value out of Plan, we will be implementing [Epic features to be more aligned with our buying tiers](https://gitlab.com/groups/gitlab-org/-/epics/1887).\n\n**Reporting and analytics**: Provide dashboarding and analytics for project and portfolio management, allowing business to track and communicate progress on work in-flight, capacity of teams and projects, and overall efficiency across their full portfolio.\n\n**Requirements management**: Many regulated customers want to use GitLab for requirements mapping, dependencies, and process management. GitLab will provide these capabilites in a modern-first way.\n\n### Create\n\n**Realtime:** It's time to fully embrace realtime. Many parts of GitLab update in near real time, but not everything does, and unfortunately some of the parts that are left out are critical to a great experience. Realtime kanban boards is mentioned above in Plan, but within Create, there's tons of opportunity for realtime enhancements. Areas we are thinking about are real time editing of code in the Web IDE for live coding and real time editing of issue/MR descriptions and comments.\n\n**Git availability and performance:** Git is a critical component in the deployment process when practicing [Continuous Deployment](https://docs.gitlab.com/ee/ci/introduction/#continuous-deployment). As such, service degradations or outages that prevent access to Git cannot be tolerated. To this end, making [Gitaly highly available](https://gitlab.com/groups/gitlab-org/-/epics/842) is of the utmost importance, and secondarily, improve the handling of extreme read pressures exterted by highly parallelized CI loads that cause performance degradations.\n\n**Enhancing the code review experience:** In the next 12 months, we must focus code review to be more performant and intelligent. We will do this by investing in [performance improvements](https://gitlab.com/groups/gitlab-org/-/epics/1417), adding additional code review functionality such as jump to definition, identifying references, displaying function documentation and type signatures, and adding support for first-class reviewers. Code review should be an \"IDE like\" experience.\n\n**Making large files “just work” in Git:** To gather more market share from industries that currently use Perforce or SVN, we must invest in making the large-file experience in Git excellent. It should “just work” without configuration or specialized hardware.\n\n**Investing in our Wiki product:** Many customers currently use Wikis for knowledge bases and project management activities. Our first step in making the GitLab Wiki more competitive is making wikis available at the group level and enhancing markdown support.\n\n**Focusing on the gaps in the design management workflow:** Most designers use a sketch or prototyping tool already, but version controlling assets alongside code and providing a workflow to compare those assets to what front-end teams ship is a gap in the market. We are uniquely poised to capitalize on this gap – think\nvisual review apps checked against the mockups checked into the repository. Additionally, we will continue to make improvements to the collaboration aspect of designs and consider other features such as simple sketch functionality inside of issues and MRs.\n\n**Enabling easier contributions to GitLab:** Contributing to GitLab requires users to set up and run the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) locally. This is cumbersome and typically requires multiple hours of debugging with senior engineers. While the process of streamlining the GDK locally should be advanced, GitLab should also provide the GDK as part of the Web IDE experience. Allowing contributors to quickly spin-up feature branches should encourage more contributions from non-engineering GitLab team members, as well as the wider community.\n\n**Bolstering the editor experience:** Our current Web IDE experience is useful for small changes, but has not been useful as an actual replacement for a local IDE. Over the next year, we will evaluate the impact of adding a container-based IDE solution, while continuing to streamline our editing experience, potentially by sunsetting the ACE editor. We will also improve the IDE experience with self-managed, client-side evaluation, server-side evaluation, and live-coding features for pair programming.\n\n**Creating a content management experience:** Projects in GitLab aren't always leveraged by pure engineering teams. Groups like marketing, sales and others often have needs for projects that more closely resemble marketing websites or documentation. While [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) enables the deployment of many popular static site generators, the editing experience is still geared toward technical users. Enabling a more WYSIWYG content management editor will help support non-technical personas use of GitLab for non-engineering driven projects.\n\n### What we're not doing\n\nChoosing to invest in these areas in 2020 means we will choose not to:\n\n* **Invest in features that help companies answer, “Am I doing the right activities?”.** Answering this question is something we will focus on in years two and three of the VSM plan.\n* **Treat ML models as first-class citizens in GitLab.** Instead, we will focus on getting large assets to become performant via improvements to Gitaly. Once this is completed, we will focus on ML models.\n* **Provide recommendations where customers can improve their efficiency in the DevOps lifecycle.** This will likely require comparisons amongst many GitLab users and an AI engine to make intelligent recommendations. These improvements will come in years two and three of the VSM plan.\n\n### Other areas of investment consideration\n\n* Data science: We should consider investment into a data science team that can assist with recommendations for Plan and VSM features.\n* [Dark themes](https://gitlab.com/gitlab-org/gitlab-ee/issues/14531): We should consider prioritizing a dark theme for both GitLab, as well as the Web IDE/editing experience. This is an expected feature of most modern development tools.\n* Engineering: Most Dev groups should see 50-100% headcount growth in order to make our Dev categories lovable.\n* AI: We should consider beginning to invest into AI as a solution for recommendations – for example, recommended assignees, labels, etc.\n\n## Survey\n\nNow that you're heard our strategy and plans, we'd love to hear your feedback. Please click below for a quick two-question survey.\n\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nHelp shape our Dev strategy - [Take our survey](https://docs.google.com/forms/d/e/1FAIpQLSdfZTpqNYilD-bzcRKPPo5AIVZq-k5GrYd_thr21iXcreA-oQ/viewform)!\n  \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\nCover Photo by [Joanna Kosinska](https://unsplash.com/@joannakosinska) on [Unsplash](https://unsplash.com/).\n{: .note}\n",[680,9],{"slug":1978,"featured":6,"template":683},"dev-strategy-review","content:en-us:blog:dev-strategy-review.yml","Dev Strategy Review","en-us/blog/dev-strategy-review.yml","en-us/blog/dev-strategy-review",{"_path":1984,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1985,"content":1991,"config":1998,"_id":2000,"_type":13,"title":2001,"_source":15,"_file":2002,"_stem":2003,"_extension":18},"/en-us/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"title":1986,"description":1987,"ogTitle":1986,"ogDescription":1987,"noIndex":6,"ogImage":1988,"ogUrl":1989,"ogSiteName":670,"ogType":671,"canonicalUrls":1989,"schema":1990},"Developing GitLab Duo: A roundup of recent Chat enhancements","Discover the latest improvements to GitLab Duo Chat, including a new integration, prompt cancellation, and architectural upgrades.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098374/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098374059.png","https://about.gitlab.com/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo: A roundup of recent Chat enhancements\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jannik Lehmann\"},{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-07-10\",\n      }",{"title":1986,"description":1987,"authors":1992,"heroImage":1988,"date":1995,"body":1996,"category":806,"tags":1997},[1993,1994],"Jannik Lehmann","David O'Regan","2024-07-10","GitLab is committed to [continuously improving GitLab Duo Chat](https://gitlab.com/gitlab-org/gitlab/-/issues/430124), our AI assistant, to meet the evolving needs of our users. Here are some recent enhancements that will streamline your workflow and boost productivity.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today](https://about.gitlab.com/seventeen/)!\n\n## Vulnerability Explanation: A new integration\n\nWe've reached a significant milestone in the evolution of Chat: the integration of [GitLab Duo Vulnerability Explanation](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/). This marks the first feature from our [GitLab Duo](https://about.gitlab.com/gitlab-duo/) platform to be integrated into Chat by a team outside of the AI group, showcasing the collaborative spirit and cross-functional capabilities at GitLab.\n\n### Key highlights of this integration:\n\n- **Swift execution:** The team moved from a spike to implementation in just three weeks, demonstrating agility and execution.\n- **Cross-team collaboration:** This integration was led by teams outside the AI group, paving the way for more diverse feature integrations in the future.\n- **Enhanced security insights:** Users will soon be able to leverage Chat to gain deeper understanding of vulnerabilities detected in their projects.\n\nThis integration represents a significant step forward in making Chat an even more powerful and versatile tool for developers, particularly in the realm of security.\n\n## Enhanced context awareness\n\nWe've made significant strides in improving Chat's context awareness, making it more intelligent and helpful in various scenarios.\n\n### Always-available knowledge\n\nGitLab Duo Chat always has access to:\n- GitLab documentation\n- General programming and coding knowledge\n\nIt's crucial to understand that Chat does not have unrestricted access to your entire GitLab instance or codebase. It only processes the specific information you provide in your query or what's immediately relevant to your current view in the GitLab UI or IDE.\n\nWe're continuously working to expand Chat's contextual awareness to include more types of content, always with a focus on user privacy and data security. This gradual expansion aims to make Chat an even more powerful assistant for your development workflow while maintaining appropriate data access boundaries.\n\n### Expanded contextual knowledge\n\nGitLab Duo Chat now has [a better understanding of the context you're working in](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#the-context-chat-is-aware-of), both in the GitLab UI and IDEs. Here's a breakdown of what Chat is aware of.\n\nIn the GitLab UI:\n- **Epics** - Chat understands when you refer to \"this epic\" or use the epic's URL.\n- **Issues** - Similar to epics, Chat recognizes \"this issue\" or the issue's URL.\n- **Code files** - When viewing a single file, Chat can interpret requests about \"this code\" or \"this file\".\n\nIn IDEs:\n- **Selected code** - Chat can analyze code you've selected when you ask about \"this code\" or \"this file\".\n- **Epics and issues** -  Chat can understand context when you provide the URL.\n\nAdditionally, when using slash commands like `/explain`, `/refactor`, or `/tests` in IDEs, Chat has access to the selected code.\n\n![Screenshot of GitLab Duo Chat window](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098382107.png)\n\n### Chat history and caching\nGitLab Duo Chat retains the last 50 messages in the chat history. This history expires three days after last use. Closing your browser or IDE will not permanently delete your chat history within this timeframe, but it's important to note that long-term persistence of chat data is not currently supported.\n\n## Prompt cancellation: Stop responses on demand\n\nOne of the most anticipated features is now available: [prompt cancellation](https://gitlab.com/groups/gitlab-org/-/epics/13662). Users can now cancel ongoing prompts in Chat on GitLab.com, giving you [more control over your interactions](https://gitlab.com/gitlab-org/gitlab/-/issues/458397).\n- Available now: This feature has been rolled out on GitLab.com.\n- Coming soon: This feature will be available for self-managed instances in our next release. GitLab Dedicated users will receive it in the monthly upgrade.\n- Work in progress: [Integration for editor extensions](https://docs.gitlab.com/ee/editor_extensions/) - [follow along in the issue](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/335).\n\nThis enhancement allows you to stop a response if you've sent a prompt too early or had a change of thought while waiting. It's a small but powerful feature that can save you time and frustration.\n\nTo cancel a prompt in GitLab Duo Chat, follow these steps:\n1. Open GitLab Duo Chat on GitLab.com.\n2. Start typing a prompt or question such as `What is this issue about?`.\n\n![Screen showing the start of how to cancel prompts in GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098382108.png)\n\n3. After sending the prompt, if you wish to cancel the response, look for the new \"Cancel\" button that appears while Chat is generating a response.\n\n![Screenshot of Chat with Cancel button](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098382110.png)\n\n4. Click the \"Cancel\" button to immediately stop the response generation.\n\n![Screenshot showing response stopped](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098382112.png)\n\n## Architectural improvements\n\nBehind the scenes, we've been working on architectural improvements to make GitLab Duo Chat more robust and efficient:\n\n- Moving to Language Server Protocol ([LSP](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp)): This effort improves the integration of Chat with various development environments. \n- GitLab Language Server is an experimental TypeScript project that provides a common interface for IDE extensions to build GitLab functionality. It currently supports GitLab Duo Code Suggestions and upcoming will support GitLab Duo Chat.\n\nWhile this change primarily affects the underlying architecture, users may notice:\n- Improved responsiveness and performance when using Chat across different IDEs and editors.\n- More consistent behavior of Chat features across various development environments.\n- Enhanced ability to add new features and improvements in the future.\n\nCheck out our introduction to how GitLab Language Server powers Code Suggestions in this video walkthrough:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VQlWz6GZhrs?si=_G5mOyYqEGAmnRv4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## What's next?\n\nWe're continuously improving GitLab Duo Chat. Here are some highlights:\n\n- We're in the process of migrating our AI features to [Claude 3.5 Sonnet](https://gitlab.com/gitlab-org/gitlab/-/issues/468334). This upgrade will bring improved performance and capabilities to Chat and other AI-powered features.\n- We're actively working on [enabling Chat to work with custom, self-hosted models](https://gitlab.com/groups/gitlab-org/-/epics/13760). This will allow organizations to use their own AI models with Chat, providing more control over the AI's knowledgebase and potentially improving performance for domain-specific tasks.\n- We're currently finishing the [synchronization of messages across all clients](https://gitlab.com/gitlab-org/gitlab/-/issues/418760), including WebUI, to ensure seamless communication and keep all your clients in sync, enhancing your collaboration experience.\n- We’re [migrating the “Summarize Comments” feature to Chat](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/156650). You'll be able to summarize multiple comments on an issue directly within Chat, helping you quickly understand the main points and key takeaways from discussions, thereby improving your collaborative experience.\n\nWe look forward to [hearing your feedback on these enhancements](https://gitlab.com/gitlab-org/gitlab/-/issues/430124). Stay tuned for more updates as we continue to evolve GitLab Duo Chat.\n\n> Find out even more about [how we are developing GitLab Duo](https://about.gitlab.com/blog/developing-gitlab-duo-series/) with our ongoing series.\n",[786,9,701],{"slug":1999,"featured":90,"template":683},"developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","content:en-us:blog:developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","Developing Gitlab Duo A Roundup Of Recent Chat Enhancements","en-us/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","en-us/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"_path":2005,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2006,"content":2012,"config":2019,"_id":2021,"_type":13,"title":2022,"_source":15,"_file":2023,"_stem":2024,"_extension":18},"/en-us/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"title":2007,"description":2008,"ogTitle":2007,"ogDescription":2008,"noIndex":6,"ogImage":2009,"ogUrl":2010,"ogSiteName":670,"ogType":671,"canonicalUrls":2010,"schema":2011},"Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI","Our blog series continues spotlighting a new feature that provides detailed metrics, such as the Code Suggestions Usage Rate, to help understand the effectiveness of AI investments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098611/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098611370.png","https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2024-05-15\",\n      }",{"title":2007,"description":2008,"authors":2013,"heroImage":2009,"date":2015,"body":2016,"category":806,"tags":2017},[2014],"Haim Snir","2024-05-15","***Generative AI marks a monumental shift in the software development industry, making it easier to develop, secure, and operate software. Our new blog series, written by our product and engineering teams, gives you an inside look at how we create, test, and deploy the AI features you need integrated throughout the enterprise. Get to know new capabilities within GitLab Duo and how they will help DevSecOps teams deliver better results for customers.***\n\nAs organizations adopt [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our suite of AI features to power DevSecOps workflows, business and engineering leaders need real-time visibility into the technology's ROI. Granular usage data, performance improvements, the trade-off between speed, security, and quality, and other [productivity metrics](https://about.gitlab.com/blog/measuring-ai-effectiveness-beyond-developer-productivity-metrics/) are essential to evaluate the effectiveness of AI in software development. That's why we created the AI Impact analytics dashboard for GitLab Duo, available in GitLab 17.0, as a new way to measure the ROI of AI.\n\n> [Take an interactive tour of the AI Impact analytics dashboard](https://gitlab.navattic.com/ai-impact).\n\n## Understanding the ROI of GitLab Duo AI-powered capabilities\n\nTo properly evaluate AI's impact on the software development lifecycle, organizations have told us they want to:\n- visualize which metrics improved as a result of investments in AI\n- compare the performance of teams that are using AI against teams that are not using AI\n- track the progress of AI adoption\n- automate insights extraction from a large volume of performance data\n\nAI Impact analytics dashboard features these capabilities and more with customizable visualization, which enables teams to:\n- **Monitor AI adoption:** Observing AI adoption rates enables organizations to evaluate organizational strategies to maximize the ROI on their technology investments. \n- **Track performance improvements:** By tracking performance metrics and observing changes after the adoption of AI, leaders can quickly assess the benefits and business value of AI features.\n\n## What is the AI Impact analytics dashboard?\n\nIn this first release of the AI Impact analytics dashboard, we focus on providing insights and metrics about GitLab Duo Code Suggestions adoption, including:\n\n- **Detailed usage metrics:** Discover the ratio of monthly Code Suggestions usage compared to the total number of unique code contributors to know how deeply Code Suggestions is adopted within your teams.\n- **Correlation observations:** Examine how trends in AI usage within a project or across a group influence other crucial productivity metrics, displayed for the current month and the trailing six months. \n    - For this correlation analysis we added a new metric \"Code Suggestions Usage Rate\" as the Independent Variable (the cause). The monthly Code Suggestions Usage Rate is calculated as the number of monthly unique Code Suggestions users divided by total monthly unique [contributors](https://docs.gitlab.com/ee/user/profile/contributions_calendar.html#user-contribution-events). GitLab considers the total monthly unique code contributors, which means only users with pushed events are included in the calculation.\n    - As Dependent Variables (the effect), we added these [performance metrics](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports): Cycle Time, Lead Time and Deployment Frequency. And as [Quality and Security Metrics](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports), we added Change Failure Rate and Critical Vulnerabilities. \n- **Comparison view:**  Understand the difference in the performance of teams that are and are not using AI, and manage the trade-off between speed, quality, and security exposure.\n\n![Comparison of AI usage and SDLC performance](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098620998.png)\n\n## What’s next for the AI Impact analytics dashboard?\n\nLooking ahead, we have exciting plans to expand the capabilities of the AI Impact analytics dashboard. Here are some of the highlights:\n\n1. New tile visualizations such as \"GitLab Duo Seats: Assigned and Used,\" \"Code Suggestions: Acceptance Rate %,\" and \"GitLab Duo Chat: Unique Users\"  to gain a deeper insight into usage patterns for GitLab Duo.\n\n![AI Impact - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-07-17_at_12.50.31_aHR0cHM6_1750098620999.png)\n\n2. New comparison bar chart to help users observe how changes in one metric correlate with changes in others:\n\n![AI Impact comparison bar chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098621000.png)\n\n3. AI statistics in the [Contribution analytics report](https://docs.gitlab.com/ee/user/group/contribution_analytics/index.html) to understand how users interact with AI features. See which users are leveraging AI features and whether their performance has changed over time:\n\n![Contribution analytics report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098621001.png)\n\n## Get started today\n\nWe're excited about the potential of the AI Impact analytics dashboard to not only demonstrate the real-world business outcomes of AI but also to drive more informed decisions regarding future AI as optimization for the DevSecOps lifecycle. For more information about what is coming next and to share feedback or questions, [please visit our AI Impact analytics dashboard epic](https://gitlab.com/groups/gitlab-org/-/epics/12978).\n\nStart your [free trial of GitLab Duo and the AI Impact analytics dashboard today](https://about.gitlab.com/gitlab-duo/#free-trial).\n\n## Read more of the \"Developing GitLab Duo\" series\n\n- [Developing GitLab Duo: How we validate and test AI models at scale](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [Developing GitLab Duo: How we are dogfooding our AI features](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n- [Developing GitLab Duo: Secure and thoroughly test AI-generated code](https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n- [Developing GitLab Duo: Blending AI and Root Cause Analysis to fix CI/CD pipelines](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._",[786,2018,9],"performance",{"slug":2020,"featured":90,"template":683},"developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai","content:en-us:blog:developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","Developing Gitlab Duo Ai Impact Analytics Dashboard Measures The Roi Of Ai","en-us/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","en-us/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"_path":2026,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2027,"content":2033,"config":2041,"_id":2043,"_type":13,"title":2044,"_source":15,"_file":2045,"_stem":2046,"_extension":18},"/en-us/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"title":2028,"description":2029,"ogTitle":2028,"ogDescription":2029,"noIndex":6,"ogImage":2030,"ogUrl":2031,"ogSiteName":670,"ogType":671,"canonicalUrls":2031,"schema":2032},"GitLab Duo: AI-powered CI/CD pipeline root cause analysis","Discover how we've infused Root Cause Analysis with AI to help remedy broken CI/CD pipelines, including example scenarios and take-away exercises.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097321/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097321081.png","https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo: Blending AI and Root Cause Analysis to fix CI/CD pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rutvik Shah\"},{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-06-06\",\n      }",{"title":2034,"description":2029,"authors":2035,"heroImage":2030,"date":2038,"body":2039,"category":806,"tags":2040},"Developing GitLab Duo: Blending AI and Root Cause Analysis to fix CI/CD pipelines",[2036,2037],"Rutvik Shah","Michael Friedrich","2024-06-06","___Generative AI marks a monumental shift in the software development industry, making it easier to develop, secure, and operate software. Our new blog series, written by our product and engineering teams, gives you an inside look at how we create, test, and deploy the AI features you need integrated throughout the enterprise. Get to know new capabilities within GitLab Duo and how they will help DevSecOps teams deliver better results for customers.___\n\nHave you ever encountered a broken [CI/CD](https://about.gitlab.com/topics/ci-cd/benefits-continuous-integration/) pipeline and had to halt your DevSecOps workflow, or even delay software deployment, as you try to figure out the root cause? Traditionally, when something goes wrong in the process of creating software, developers have to troubleshoot, dig through log files, and often do a lot of trial and error development. [GitLab Duo Root Cause Analysis](https://about.gitlab.com/gitlab-duo/), part of our suite of AI-powered features, removes the guesswork by determining the root cause for a failed CI/CD pipeline. In this article, you'll learn what Root Cause Analysis is and how to apply the AI-powered GitLab Duo feature to your DevSecOps workflow.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n### What is Root Cause Analysis?\n\nGitLab Duo Root Cause Analysis is an AI-powered feature that assists you in determining a root cause and suggesting a fix for a CI/CD job log failure by analyzing the logs.\n\nWhile Root Cause Analysis is often seen in product incident management, its workflows and debugging practices can be found in any DevSecOps workflow. Ops teams, administrators, and platform engineers are challenged by infrastructure-as-code (IaC) deployment errors, Kubernetes and GitOps problems, and long stack traces while investigating pipeline failures.\n\nGitLab Duo Root Cause Analysis keeps everyone in the same interface and uses AI-powered help to summarize, analyze, and propose fixes so that organizations can release secure software faster.\n\nA pipeline can encounter failures for a variety of reasons, including syntax errors in the code, missing dependencies that the pipeline relies on, test failures during the build process, Kubernetes and IaC deployment timeouts, and numerous other potential issues. When such failures occur, it becomes the responsibility of everyone to meticulously review the logs generated by the pipeline. This job log review process involves scrutinizing the detailed output to identify the specific errors and pinpoint the root cause of the pipeline failure. For example, the following pipeline has multiple job failures that need to be investigated and fixed.\n\n![Image depicting multiple job failures](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097332601.png)\n\nThe duration required to fix these failures can vary significantly and is largely influenced by several factors such as:\n- the developer's familiarity with the project\n- their level of experience in dealing with similar issues\n- their overall skill level in troubleshooting and problem-solving within the context of the pipeline.\n\nManual analysis can be exceedingly challenging and time-consuming, given that log data consists of application logs and system messages with a wide variety of potential sources of failures. A typical pipeline fix can consist of several iterations and context switching. The complexity and the unstructured nature of the logs is a perfect fit for speeding up the task using generative AI.  Using AI can reduce the time to identify and fix a pipeline error significantly and also lower the barrier of expertise that would be needed to fix a pipeline such as the above.\n\nWatch GitLab Duo Root Cause Analysis in action:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n \u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n### How does Root Cause Analysis work?\n\n[Root Cause Analysis](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis) works by forwarding a portion of the CI/CD job log to the [GitLab AI Gateway](https://docs.gitlab.com/ee/architecture/blueprints/ai_gateway/). GitLab ensures that the portion sent will fit inside the large language model (LLM) token limits alongside a prompt that has been pre-crafted to provide insights into why the job might have failed. The prompt also instructs the LLM to provide an example of how a user might fix a broken job.\n\nHere are two example scenarios where Root Cause Analysis can provide assistance.\n\n#### 1. Analyze a Python dependency error\n\nA Python application can import package modules with functionality that is not provided in the standard library. The project [Challenge - Root Cause Analysis - Python Config](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config) implements an application that parses configuration and initializes an SQLite database, which both work well without any dependencies. It uses best practices in CI/CD with a Python environment and caching. The latest feature implementation adds a Redis caching client, and now the CI/CD build is failing for some reason. \n\nBy using Root Cause Analysis, you can immediately learn that the `ModuleNotFoundError` text means that the module is actually not installed in the Python environment. GitLab Duo also suggests an example fix: Installing the Redis module through the PIP package manager. \n\n![Image depicting 'modulenotfounderror' and GL Duo suggested resolution](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097332602.png)\n\nThe failing pipeline can be viewed [here](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/jobs/6992716398). \n\nThe Root Cause Analysis prompt provides a summary of the problem, which seems to be a problem with a missing `redis` module. Let's try to fix the problem by installing the `redis` module. You can either call `pip install redis` in the CI/CD job `script` section, or use a more sophisticated approach with the `requirements.txt` file. The latter is useful for a single source of truth for dependencies installed in the development environment and CI/CD pipelines.\n\n```yaml\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis.\n    # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n```\n\nAfter fixing the missing Python dependency, the CI/CD job fails again. Use Root Cause Analysis again to learn that no Redis service is running in the job. Switch to using GitLab Duo Chat and use the prompt `How to start a Redis service in CI/CD` to learn how to configure the `services` attribute in the CI/CD job.\n\n![Depicts the prompt for how to start a Redis service](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097333/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097332602.png)\n\nModify the `.gitlab-ci.yml` with the `test` job, and specify the `redis` service.\n\n```yaml\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis.\n    # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n\n  # Solution 3 - Running Redis\n  services:\n    - redis\n```\n\nRunning the Redis server allows you to successfully execute the Python application, and print its output into the CI/CD job log.\n\n![output of Python application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097332603.png)\n\nThe solution is provided in the [solution/ directory](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/tree/main/solution?ref_type=heads).\n\n**Tip:** You can also ask [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) to follow up on potential future problems:\n\n```markdown\nHow to lint Python code? Which tools are recommended for CI/CD.\nHow to pin a package version in Python requirements file?\t\nWhat are possible ways that this exception stacktrace is triggered in the future?\nAre there ways to prevent the application from failing?\n``` \n\nThe next example is more advanced and includes multiple failures. \n\n#### 2. Analyze missing Go runtime\n\nCI/CD jobs can be executed in containers, spawned from the contributed `image` attribute. If the container does not provide a programming language runtime, the executed `script` sections referencing the `go` binary fail. For example, the error message `/bin/sh: eval: line 149: go: not found` needs to be understood and fixed. \n\nIf the `go` command is not found in the container's runtime context, this can have multiple reasons:\n\n1. The job uses a minimal container image, for example `alpine`, and the Go language runtime was not installed.\n1. The job uses the wrong default container image, for example, specified on top of the CI/CD configuration, or using the `default` keyword.\n1. The job does not use a container image but the shell executor. The host operating system does not have the Go language runtime installed, or it is otherwise broken/not configured.\n\nThe project [Challenge - Root Cause Analysis - Go GitLab Release Fetcher](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher) provides an exercise challenge to analyze and fix CI/CD problems with a GitLab release fetcher application, written in Go. The `build` and `docker-build` CI/CD jobs are failing. Fixing the problem requires different scopes: Understanding why the Go runtime is not installed, and learning about the `Dockerfile` syntax. \n\n![Screenshot showing Change Docker Label job failed](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097332603.png)\n\nThe [`solution/` directory](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher) provides two possible solutions after Root Cause Analysis. \n\n## Practice using Root Cause Analysis\n\nHere are some scenarios to use to practice using Root Cause Analysis.\n\n- When you are running into Kubernetes deployment errors or timeouts. \n\n- With OpenTofu or Terraform IaC pipelines failing to provision your cloud resources.\n\n- When the Ansible playbook fails with a cryptic permission error in CI/CD.\n\n- When the Java stack trace is 10 pages long.\n\n- With a shell script highlighting an execution error.\n\n- When a Perl script fails in a single line, which is the only line in the script.\n\n- When the CI/CD job times out and it is unclear which section would cause this.\n\n- When a network connection timeout is reached, and you think it cannot be DNS.\n\n### What is next for GitLab Duo Root Cause Analysis?\n\nWe want to help our users to get their pipelines back to passing in fewer iterations. The Root Cause Analysis will open and show the response in GitLab Duo Chat, our AI assistant. Users can build on the recommendation to generate a more precise fix by asking specific questions (e.g., programming language-specific fixes) or asking for alternative fixes based on the root cause.\n\nFor example, here is the Root Cause Analysis for a failing job:\n\n![Root Cause Analysis response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097332603.png)\n\nUsers can ask follow-up questions that build upon the AI-generated response.\n\n- I do not want to create my own Docker image. Please explain different ways to fix the problem.\n\n- I don't have access to the Docker image creation. It seems that the Go binary is missing. Are there alternative images you can suggest?\n\nGitLab also will be running quality benchmarks for the generated responses and shipping usability improvements.\n\nPlease see our [Root Cause Analysis GA epic](https://gitlab.com/groups/gitlab-org/-/epics/13080) for more details. We would also love your feedback on the feature. Please leave a comment on our [Root Cause Analysis feedback issue](https://gitlab.com/groups/gitlab-org/-/epics/13872).\n\n## Get started with Root Cause Analysis\n\nPlease see our [documentation](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis) on how to enable the feature available to our GitLab Ultimate customers. Also, GitLab Duo Root Cause Analysis will soon be coming to GitLab self-managed and GitLab Dedicated.\n\nNot a GitLab Ultimate customer? Start [a 30-day free trial](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial) today. \n\n## Read more of our \"Developing GitLab Duo\" series\n\n- [Developing GitLab Duo: How we validate and test AI models at scale](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Developing GitLab Duo: How we are dogfooding our AI features](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- [Developing GitLab Duo: Secure and thoroughly test AI-generated code](https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)",[786,746,703,478,9],{"slug":2042,"featured":90,"template":683},"developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","content:en-us:blog:developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","Developing Gitlab Duo Blending Ai And Root Cause Analysis To Fix Ci Cd","en-us/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","en-us/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"_path":2048,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2049,"content":2055,"config":2060,"_id":2062,"_type":13,"title":2063,"_source":15,"_file":2064,"_stem":2065,"_extension":18},"/en-us/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"title":2050,"description":2051,"ogTitle":2050,"ogDescription":2051,"noIndex":6,"ogImage":2052,"ogUrl":2053,"ogSiteName":670,"ogType":671,"canonicalUrls":2053,"schema":2054},"Developing GitLab Duo: How we are dogfooding our AI features","As part of our blog series, we share real-world examples of how we integrate AI throughout our software development lifecycle and how we use metrics to gauge their success.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098360/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098360821.png","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo: How we are dogfooding our AI features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-20\",\n      }",{"title":2050,"description":2051,"authors":2056,"heroImage":2052,"date":2057,"body":2058,"category":806,"tags":2059},[1994],"2024-05-20","***Generative AI marks a monumental shift in the software development industry, making it easier to develop, secure, and operate software. Our new blog series, written by our product and engineering teams, gives you an inside look at how we create, test, and deploy the AI features you need integrated throughout the enterprise. Get to know new capabilities within GitLab Duo and how they will help DevSecOps teams deliver better results for customers.***\n\n[GitLab Duo](https://about.gitlab.com/gitlab-duo/), our suite of AI-powered features, has transformed our internal engineering workflows, driving efficiency gains across our development process. As strong proponents of dogfooding and transparency, we wanted to showcase how our teams leverage AI, including standouts like GitLab Duo Code Suggestions and GitLab Duo Chat, daily to streamline development processes, reduce manual effort, and enhance productivity. You'll learn about the benefits we've experienced for highly technical teams like engineering to less technical teams such as technical writing and product management.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n## Real-world use cases\n\nOur teams have integrated [GitLab Duo's many features](https://about.gitlab.com/gitlab-duo/#features) into their daily routines. Here are some examples of how GitLab Duo is helping them carry out everyday activities.\n\n### Summarization and documentation\n- **Streamline the code review process:** Staff Backend Developer [Gosia Ksionek](https://about.gitlab.com/company/team/#mksionek) showcases the practical benefits of AI in her workflow by using GitLab Duo to streamline the code review process. She effectively utilizes GitLab Duo to [summarize merge requests](https://youtu.be/3SIhe8dgFEc), making it easier and faster to review code changes. In addition to summarizing merge requests, Gosia also leverages GitLab Duo to [answer coding questions](https://www.youtube.com/watch?v=6n0I53XsjTc) and [explain complex code snippets](https://www.youtube.com/watch?v=3m2YRxa1SCY). This enhances her productivity and helps her better understand and manage intricate codebases. Through these demonstrations, Gosia highlights how GitLab Duo can significantly improve efficiency and clarity in the development process, making it an invaluable tool for developers.\n\n\u003Ccenter>\n\nWatch Gosia use GitLab Duo Merge Request Summary:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3SIhe8dgFEc?si=Q8JG3Ix3K_THhbpv\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWatch Gosia use GitLab Duo to answer coding questions: \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6n0I53XsjTc?si=LA9VBHrgXpfJImSL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWatch Gosia use GitLab Duo to explain complex code snippets:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3m2YRxa1SCY?si=oms3szKwZoz-4yeq\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C/center>\n\n- **Condense comment threads:** [Bartek Marnane](https://about.gitlab.com/company/team/#bmarnane), Vice President of Expansion Software Development, uses GitLab Duo to condense lengthy comment threads into concise summaries, ensuring all relevant details are captured when updating issue descriptions.\n\n- **Create new documentation:** [Taylor McCaslin](https://about.gitlab.com/company/team/#tmccaslin), Group Manager, Product - Data Science Section, leveraged GitLab Duo to [create new documentation for GitLab Duo itself](https://docs.gitlab.com/ee/user/ai_features.html), exemplifying a meta use case that enhances clarity and consistency and greatly reduces the time to document new features.\n\n- **Craft release notes:** [Amanda Rueda](https://about.gitlab.com/company/team/#amandarueda), Senior Product Manager for Product Planning, uses GitLab Duo to [craft brief, impactful summaries for release notes](https://gitlab.com/groups/gitlab-org/-/epics/10267), highlighting changes and their value to users. By using well-crafted prompts like below, Amanda supercharges her workflow and ensures that each release note is clear, concise, and user-focused, enhancing the overall communication and user experience:\u003Cbr>\u003Cbr>\n*“Please create a two sentence summary of this change, which can be used for our release notes. The tone should be conversational and should be in second person. The summary should include a description of the problem or change and be tied to the value we are creating for you, the user.”*\n\u003Cbr>\u003Cbr>\n    - Here are some examples of release notes co-created with GitLab Duo:\n      - [Expanded options for sorting your Roadmap](https://gitlab.com/gitlab-org/gitlab/-/issues/460492)\n      - [Issue Board Clarity now with Milestone & Iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/25758)\n      - [Design Management Features Extended to Product Teams](https://gitlab.com/gitlab-org/gitlab/-/issues/438829)\n\n- **Optimize docs site navigation:** [Suzanne Selhorn](https://about.gitlab.com/company/team/#sselhorn), Staff Technical Writer, tapped GitLab Duo to [optimize the left navigation of documentation](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html) by providing a workflow-based order of pages. Suzanne provided a list of features to GitLab Duo, which generated the optimal order, updating the left navigation to match. GitLab Duo also drafted the [Getting Started](https://docs.gitlab.com/ee/user/get_started/get_started_planning_work.html) documentation much faster than were she to use traditional, manual approaches.\n\n### Goal setting and team alignment\n- **Draft and refine OKRs:** [François Rosé](https://about.gitlab.com/company/team/#francoisrose), Engineering manager, Create:Code Review Backend, finds [GitLab Duo Chat](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/) invaluable for drafting and refining OKRs. By articulating objectives more clearly and effectively, François enhances goal setting and team alignment. Using Chat, François ensures that each OKR is precise, actionable, and aligned with the team's goals, thereby improving overall team performance and cohesion. Here is an example prompt he uses:\u003Cbr>\u003Cbr>\n\n    *\"Here is an OKR I am thinking of creating:*\n\n    *Objective: Retrospect on retrospectives, to foster a thriving team*\n\n    *KR: Measure retrospective satisfaction from 100% of team members*\n\n    *KR: Identify 3 improvements to the async retrospectives*\n\n    *KR: Implement 1 improvement*\n\n    *Please provide direct feedback on how to improve the formulation of this objective and these key results.\"*\n\u003Cbr>\u003Cbr>\n\n- **Streamlined hiring and recruitment processes:** Chat helped [Denys Mishunov](https://about.gitlab.com/company/team/#dmishunov), Staff Frontend Engineer, formulate a clear and concise text for updating the email template for technical interview candidates. The team collaborated on refining the communication to ensure candidates receive all necessary information using a merge request. This example showcased the practical application of AI tools in enhancing communication processes within the hiring workflow.\n\n### Incident response and configuration\n- **Summarize production incidents:** [Steve Xuereb](https://about.gitlab.com/company/team/#sxuereb), Staff Site Reliability Engineer, employs GitLab Duo to summarize production incidents and create detailed incident reviews, streamlining the documentation process.\n\n- **Create boilerplate `.gitlab-ci.yml` files:**  Steve also uses Chat to create boilerplate `.gitlab-ci.yml` files, which significantly sped up his workflow. [Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) serves as a valuable partner for suggesting ideas. Additionally, [Code Explanation](https://docs.gitlab.com/ee/user/ai_features.html#code-explanation) provides detailed answers that are helpful during incidents, enhancing his productivity and understanding of the codebase.\n\n### Code generation and testing\n- **Full-stack development:** [Peter Hegman](https://about.gitlab.com/company/team/#peterhegman), Senior Frontend Engineer, has been using [Code Suggestions for his JavaScript and Ruby development](https://gitlab.com/gitlab-org/gitlab/-/issues/435783#note_1731321963). This highlights that Code Suggestions has become a powerful tool for developers moving across a full technical stack. \n\n- **Generate Python scripts:** Denys conducted [an experiment using GitLab Duo for a non-GitLab task](https://gitlab.com/gitlab-org/ai-powered/ai-framework/ai-experimentation). This example highlights the flexibility and utility of our AI tools beyond typical software development tasks.\n\n\u003Ccenter>\nWatch how Denys uses GitLab Duo to generate Python scripts to fetch content data and store it locally:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/30ZTtk4K5yU?si=p5ZcFLg6dTZL5gFE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C/center>\n\n### Research and support\n- **Generate test source code:**  [Michael Friedrich](https://about.gitlab.com/company/team/#dnsmichi), Senior Developer Advocate, uses GitLab Duo to generate test source code for CI/CD components. This approach has been shared in various talks and presentations, such as the recent Open Source @ Siemens event ([public slides](https://go.gitlab.com/duA2Fc)). Using GitLab Duo in this manner helps ensure that the code is consistent, well-documented, and aligned with our best practices. Check out his [Rust example](https://gitlab.com/components/rust#contributing).\n\n![Rust example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098367547.png)\n\n- **Streamline research tasks:** Our team members consistently turn to Chat when they have questions about GitLab features, streamlining their research and support tasks. Michael shared, \"When I have a question about GitLab features, I default to using Chat instead of opening 100 browser tabs. This workflow helps me assist users on our community forum efficiently. For instance, I recently [helped a user with SSH deployment](https://forum.gitlab.com/t/how-to-make-ssh-deployment-more-clear-in-gitlab/102051/4?u=dnsmichi) using this method.\" Using Chat not only saves time but also provides quick, accurate information, enhancing the support we offer to our community.\n\n### Feature testing\n- **Test new features:** Our engineers use GitLab Duo to test new features like [Markdown support in Code Suggestions](https://gitlab.com/gitlab-org/gitlab/-/issues/443365). One of our team members noted, \"I need to test Markdown support in Code Suggestions for writing blog posts and GitLab docs in VS Code. I saw it was merged for 17.0.\" By testing these features internally, we ensure they meet our quality standards before release.\n\n### Understanding external codebases\n- **Explain external projects:** GitLab Duo's `/explain` feature is particularly useful for understanding external projects imported into GitLab. This capability was highlighted in a recent livestream he did with open source expert Eddie Jaoude. Michael let us know, \"I use `/explain` on external projects to understand the source code. I pitched this idea for learning about open source projects, dependencies, etc. during the livestream.\" This feature is invaluable for developers who need to quickly grasp the functionality and dependencies of unfamiliar codebases, significantly improving their efficiency and understanding.\n\n\u003Ccenter>\nWatch Michael demo `/explain` during a livestream with Eddie Jaoude:\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/L2Mx8hOhkEE?si=R7W3v4EDqeJCaPOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C/center>\n\n## GitLab Duo's benefits\n\nThe integration of GitLab Duo has brought about numerous positive impacts, significantly enhancing our engineering and product development workflows:\n\n- Many tasks that previously required manual intervention are now automated, freeing up valuable time for our engineers. For example, summarizing long threads and creating boilerplate code are now more efficient, allowing our team to focus on more complex issues.\n- The time taken to document and summarize issues has decreased, allowing for quicker information dissemination and decision-making.\n- With AI-assisted code suggestions and explanations, our teams produce higher quality code with fewer errors and faster debugging processes. The integration of GitLab Duo into incident reviews and coding assistance has led to more efficient and effective code reviews.\n- Administrative tasks, such as drafting OKRs and creating release notes, have been streamlined. \n\nGitLab Duo has helped to not only improve our efficiency but also to enhance the quality and speed of our development processes, illustrating the transformative power of AI in software development.\n\n## What's next?\n\nWe are committed to further integrating AI into our workflows and continuously improving GitLab Duo features based on internal feedback and evolving needs. The ongoing collection of use cases and metrics with the [AI Impact analytics dashboard](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) will guide enhancements and ensure that GitLab Duo remains at the forefront of AI-driven development tools.\n\n![Dogfooding Duo - AI analytics dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098367547.png)\n\n> [Get started using GitLab Duo today with our free trial.](https://about.gitlab.com/gitlab-duo/#free-trial)\n\n## Read more \"Developing GitLab Duo\"\n\n- [Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [Developing GitLab Duo: How we validate and test AI models at scale](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [Developing GitLab Duo: Secure and thoroughly test AI-generated code](https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n- [Developing GitLab Duo: Blending AI and Root Cause Analysis to fix CI/CD pipelines](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)",[786,871,9,478,894],{"slug":2061,"featured":90,"template":683},"developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","content:en-us:blog:developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","Developing Gitlab Duo How We Are Dogfooding Our Ai Features","en-us/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","en-us/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"_path":2067,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2068,"content":2073,"config":2079,"_id":2081,"_type":13,"title":2082,"_source":15,"_file":2083,"_stem":2084,"_extension":18},"/en-us/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"title":2069,"description":2070,"ogTitle":2069,"ogDescription":2070,"noIndex":6,"ogImage":777,"ogUrl":2071,"ogSiteName":670,"ogType":671,"canonicalUrls":2071,"schema":2072},"Developing GitLab Duo: How we validate and test AI models at scale","Our blog series debuts with a behind-the-scenes look at how we evaluate LLMs, match them to use cases, and fine-tune them to produce better responses for users.","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo: How we validate and test AI models at scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"}],\n        \"datePublished\": \"2024-05-09\",\n      }",{"title":2069,"description":2070,"authors":2074,"heroImage":777,"date":2076,"body":2077,"category":806,"tags":2078},[2075],"Susie Bitters","2024-05-09","**_Generative AI marks a monumental shift in the software development industry, making it easier to develop, secure, and operate software. Our new blog series, written by our product and engineering teams, gives you an inside look at how we create, test, and deploy the AI features you need integrated throughout the enterprise. Get to know new capabilities within GitLab Duo and how they will help DevSecOps teams deliver better results for customers._**\n\nGitLab values the trust our customers place in us. Part of maintaining that trust is transparency in how we build, evaluate, and ensure the high-quality functionality of our [GitLab Duo](https://about.gitlab.com/gitlab-duo/) AI features. GitLab Duo features are powered by a diverse set of models, which allows us to support a broad set of use cases and gives our customers flexibility. GitLab is not tied to a single model provider by design. We currently use foundation models from [Google](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/vertex_text.py?ref_type=heads#L86) and [Anthropic](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/anthropic.py?ref_type=heads#L62). However, we continuously assess what models are the right matches for GitLab Duo’s use cases. In this article, we give you an inside look at our AI model validation process.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n## Understanding LLMs\n\nLarge language models (LLMs) are generative AI models that power many AI features across the platform. Trained on vast datasets, LLMs predict the next word in a sequence based on preceding context. Given an input prompt, they generate human-like text by sampling from the probability distribution of words conditioned on the prompt.\n\nLLMs enable intelligent code suggestions, conversational chatbots, code explanations, vulnerability analysis, and more. Their ability to produce diverse outputs for a given prompt makes standardized quality evaluation challenging. LLMs can be optimized for different characteristics, which is why there are so many AI models actively being developed.\n\n## Testing at scale\n\nUnlike traditional software systems where inputs and outputs can be more easily defined and tested, LLMs produce outputs that are often nuanced, diverse, and context-dependent. Testing these models requires comprehensive strategies that account for subjective and variable interpretations of quality, as well as the stochastic nature of their outputs. We, therefore, cannot judge the quality of an LLM’s output in an individual or anecdotal fashion; instead, we need to be able to examine the overall pattern of an LLM's behavior. To get a sense of those patterns, we need to test at scale. Testing at scale refers to the process of evaluating the performance, reliability, and robustness of a system or application across a large and diverse array of datasets and use cases. Our [Centralized Evaluation Framework (CEF)](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/) utilizes thousands of prompts tied to dozens of use cases to allow us to identify significant patterns and assess the overall behavior of our foundational LLMs and the GitLab Duo features in which they are integrated.\n\nTesting at scale helps us:\n\n- **Ensure quality:** Testing at scale enables us to assess the quality and reliability of these models across a wide range of scenarios and inputs. By validating the outputs of these models at scale, we can start to identify patterns and mitigate potential issues such as systematic biases, anomalies, and inaccuracies. \n- **Optimize performance:** Scaling up testing efforts allows GitLab to evaluate the performance and efficiency of LLMs under real-world conditions. This includes assessing factors such as output quality, latency, and cost to optimize the deployment and operation of these models in GitLab Duo features.\n- **Mitigate risk:** Testing LLMs at scale helps mitigate the risks associated with deploying LLMs in critical applications. By conducting thorough testing across diverse datasets and use cases, we can identify and address potential failure modes, security vulnerabilities, and ethical concerns before they impact our customers.\n\nTesting LLMs at scale is imperative for ensuring their reliability and robustness for deployment within the GitLab platform. By investing in comprehensive testing strategies that encompass diverse datasets, use cases, and scenarios, GitLab is working to unlock the full potential of AI-powered workflows while mitigating potential risks.\n\n### How we test at scale\n\nThese are the steps we take to test LLMs at scale.\n\n#### Step 1: Create a prompt library as a proxy for production\nWhile other companies view and use customer data to train their AI features, GitLab currently does not.  As a result, we needed to develop a comprehensive prompt library that is a proxy for both the scale and activity of production.\n\nThis prompt library is composed of questions and answers. The questions represent the kinds of queries or inputs that we would expect to see in production, while the answers represent a ground truth of what our ideal answer would be. This ground truth answer could also be mentally framed as a target answer. Both the question and the answer may be human generated, but are not necessarily so. These question/answer pairs give us a basis for comparison and a reference frame that allow us to tease out differences between models and features. When multiple models are asked the same question and generate different responses, we can use our ground truth answer to determine which model has provided an answer that is most closely aligned to our target and score them accordingly.\n\nAgain, a key element of a comprehensive prompt library is ensuring that it is representative of the inputs that we expect to see in production. We want to know how well foundational models fit to our specific use case, and how well our features are performing. There are numerous benchmark prompt datasets, but those datasets may not be reflective of the use cases that we see for features at GitLab. Our prompt library is designed to be specific to GitLab features and use cases.\n\n#### Step 2: Baseline model performance\n\nOnce we have crafted a prompt library that accurately reflects production activity, we feed those questions into [various models](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/foundation_models/) to test how well they serve our customer’s needs. We compare each response to our ground truth and provide it a ranking based on a series of metrics including: [Cosine Similarity Score](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/metrics/#similarity-scores), [Cross Similarity Score](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/metrics/#cross-similarity-score),  [LLM Judge](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/metrics/#llm-judge), and [Consensus Filtering with an LLM Judge](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/metrics/#consensus-filtering-with-llm-judge). This first iteration provides us a baseline for how well each model is performing, and guides our selection of a foundational model for our features. For brevity, we won’t go into the details here, but we encourage you to [learn more about more about the metrics here](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/metrics/). It is important to note this isn’t a solved problem; the wider AI industry is actively researching and developing new techniques. GitLab’s model validation team keeps a pulse on the industry and is continuously iterating on how we measure and score the LLMs GitLab Duo uses.  \n\n#### Step 3: Feature development\n\nNow that we have a baseline for our selected model's performance, we can start developing our features with confidence. While prompt engineering gets a lot of buzz, focusing entirely on changing the behavior of a model via prompting (or any other technique) without validation means that you are operating in the dark and very possibly overfitting your prompting. You may solve one problem, but be causing a dozen more. You would never know. Creating a baseline for a model's performance allows us to track how we are changing behavior over time for all our necessary use cases. At GitLab, we re-validate the performance of our features on a daily basis during active development to help ensure that all changes improve the overall functionality.\n\n#### Step 4: Iterate, iterate, iterate\n\nHere is how our experimental iterations work. Each cycle, we examine the scores from our tests at scale to identify patterns:\n\n- What are the commonalities across our weakest areas?\n- Is our feature performing poorly based on a specific metric or on a certain use case?\n- Do we see consistent errors popping up in response to a certain kind of question?\n\nOnly when we test at scale do these kinds of patterns begin to emerge and allow us to focus our experiments. Based on these patterns, we propose a variety of experiments or approaches to try to improve performance in a specific area and on a specific metric.\n\nHowever, testing at scale is both expensive and time-consuming. To enable faster and less expensive iteration, we craft a smaller scale dataset to act as a mini-proxy. The focused subset will be weighted to include question/answer pairs that we know we want to improve upon, and the broader subset will also include sampling of all the other use cases and scores to ensure that our changes aren't adversely affecting the feature broadly. Make your change and run it against the focused subset of data. How does the new response compare to the baseline? How does it compare to the ground truth?\n\nOnce we have found a prompt that addresses the specific use case we are working on with the focused subset, we validate that prompt against a broader subset of data to help ensure that it won’t adversely affect other areas of the feature. Only when we believe that the new prompt improves our performance in our target area through validation metrics AND doesn’t degrade performance elsewhere, do we push that change to production.\n\nThe entire Centralized Evaluation Framework is then run against the new prompt and we validate that it has increased the performance of the entire feature against the baseline from the day before. In this way, GitLab is constantly iterating to help ensure that you are getting the latest and greatest performance of AI-powered features across the GitLab ecosystem. This allows us to ensure that we keep working faster, together.\n\n### Making GitLab Duo even better\n\nHopefully this gives you insight into how we’re responsibly developing GitLab Duo features. This process has been developed as we’ve brought [GitLab Duo Code Suggestions](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/) and [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) to general availability. We’ve also integrated this validation process into our development process as we iterate on GitLab Duo features. It’s a lot of trial and error, and many times fixing one thing breaks three others. But we have data-driven insights into those impacts, which helps us ensure that GitLab Duo is always getting better.\n\n> Start a [free trial of GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial) today!\n\n ## Resources\n - [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)\n - [GitLab's AI Ethics Principles for Product Development](https://handbook.gitlab.com/handbook/legal/ethics-compliance-program/ai-ethics-principles/)\n - [GitLab AI-powered Direction page](https://about.gitlab.com/direction/ai-powered/)\n\n\u003Cfigure class=video_container>\n\u003Ciframe width=560 height=315 src=\"https://www.youtube-nocookie.com/embed/LifJdU3Qagw?si=A4kl6d32wPYC4168\" title=\"YouTube video player\" frameborder=0 allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen=\"\">\u003C/iframe>\n\u003C/figure>\n\n## Read more of the \"Developing GitLab Duo\" series\n\n- [Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [Developing GitLab Duo: How we are dogfooding our AI features](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/) \n- [Developing GitLab Duo: Secure and thoroughly test AI-generated code](https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n- [Developing GitLab Duo: Blending AI and Root Cause Analysis to fix CI/CD pipelines](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)",[786,703,478,9,680],{"slug":2080,"featured":90,"template":683},"developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","content:en-us:blog:developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","Developing Gitlab Duo How We Validate And Test Ai Models At Scale","en-us/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","en-us/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"_path":2086,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2087,"content":2092,"config":2098,"_id":2100,"_type":13,"title":2101,"_source":15,"_file":2102,"_stem":2103,"_extension":18},"/en-us/blog/developing-gitlab-duo-series",{"title":2088,"description":2089,"ogTitle":2088,"ogDescription":2089,"noIndex":6,"ogImage":777,"ogUrl":2090,"ogSiteName":670,"ogType":671,"canonicalUrls":2090,"schema":2091},"Developing GitLab Duo series","Our unique blog series, written by our Product and Engineering teams, takes you behind the scenes of our AI innovation and guides you through our newest AI features powering your DevSecOps workflow.","https://about.gitlab.com/blog/developing-gitlab-duo-series","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo series\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-06-03\",\n      }",{"title":2088,"description":2089,"authors":2093,"heroImage":777,"date":2095,"body":2096,"category":806,"tags":2097},[2094],"GitLab Team","2024-06-03","Generative AI marks a monumental shift in the software development industry, making it easier to develop, secure, and operate software. Our blog series, written by our product and engineering teams, gives you an inside look at how we create, test, and deploy the AI features you need integrated throughout the enterprise. Get to know new capabilities within GitLab Duo and how they will help DevSecOps teams deliver better results for customers.\n\n> Live demo! Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Register today](https://about.gitlab.com/seventeen/)!\n\n## 1. [How we validate and test AI models at scale](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n\n- Our blog series debuts with a behind-the-scenes look at how we evaluate LLMs, match them to use cases, and fine-tune them to produce better responses for users.\n\n## 2. [AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n\n- We spotlight a new feature that provides detailed metrics, such as the Code Suggestions Usage Rate, to help understand the effectiveness of AI investments.\n\n## 3. [How we are dogfooding our AI features](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n\n- We share real-world examples of how we integrate AI throughout our software development lifecycle and how we use metrics to gauge their success.\n\n## 4. [Secure and thoroughly test AI-generated code](https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n- Learn step-by-step how to enhance AI-generated code reliability and security using GitLab Duo and GitLab Pages (includes code samples and prompts).\n\n## 5. [Blending AI and Root Cause Analysis to fix CI/CD pipelines](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/)\n\n- Discover how we've infused Root Cause Analysis with AI to help remedy broken CI/CD pipelines, including example scenarios and take-away exercises.\n\n## 6. [Developing GitLab Duo: A roundup of recent Chat enhancements](https://about.gitlab.com/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements)\n- Discover the latest improvements to GitLab Duo Chat, including prompt cancellation and architectural upgrades. Learn how these updates streamline workflows and boost productivity.\n\n> Learn more about [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our AI-powered suite of features for your DevSecOps workflow. Then start [a free trial of GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial) to get the incredible benefits in your own organization! \n\n##  7. [Developing GitLab Duo: Use AI to remediate security vulnerabilities](https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities)\nThis tutorial shows how GitLab Duo Vulnerability Explanation and GitLab Duo Vulnerability Resolution, along with our other AI-powered features, can help to address vulnerabilities quickly.",[786,9,703,478],{"slug":2099,"featured":6,"template":683},"developing-gitlab-duo-series","content:en-us:blog:developing-gitlab-duo-series.yml","Developing Gitlab Duo Series","en-us/blog/developing-gitlab-duo-series.yml","en-us/blog/developing-gitlab-duo-series",{"_path":2105,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2106,"content":2112,"config":2118,"_id":2120,"_type":13,"title":2121,"_source":15,"_file":2122,"_stem":2123,"_extension":18},"/en-us/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"title":2107,"description":2108,"ogTitle":2107,"ogDescription":2108,"noIndex":6,"ogImage":2109,"ogUrl":2110,"ogSiteName":670,"ogType":671,"canonicalUrls":2110,"schema":2111},"Developing GitLab Duo: Use AI to remediate security vulnerabilities ","This tutorial shows how GitLab Duo Vulnerability Explanation and GitLab Duo Vulnerability Resolution, along with our other AI-powered features, can help to address vulnerabilities quickly.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098106/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098106040.png","https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing GitLab Duo: Use AI to remediate security vulnerabilities \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"},{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2024-07-15\",\n      }",{"title":2107,"description":2108,"authors":2113,"heroImage":2109,"date":2115,"body":2116,"category":806,"tags":2117},[2037,2114],"Alana Bellucci","2024-07-15","You’ve just started into a new job, and on your first day, a large-scale production incident requires all hands on deck. There are a number of critical new vulnerabilities that require immediate attention, analysis, mitigation and remediation. Where do you start your investigation? \n\nLearn how GitLab Duo Vulnerability Explanation and GitLab Duo Vulnerability Resolution, along with our other AI-powered features, can help you begin addressing vulnerabilities in minutes. You will learn how to benefit from AI-powered assistance to analyze and explain vulnerabilities in a practical example. Additional remediation is highlighted with AI-generated code fixes in MRs to aid faster vulnerability resolution.\n\n> Start [a free trial of GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial) to bring these powerful vulnerability remediation benefits to your own organization!\n\n## How to get started: Analyze\n\nThe first step is to analyze the impact and severity of the vulnerability. Open the GitLab UI and navigate into the [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) in the `Secure > Vulnerability Report` menu. Filter the vulnerability list by `SAST`, and identify the most critical vulnerabilities to work on.\n\n![Vulnerability reports overview](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/vulnerability_reports_overview_aHR0cHM6_1750098116056.png)\n\nThe SAST scanner results are summarized in the detail view, linking to the source code. They provide details from publicly available security advisories. As a developer, it is often hard to start the analysis from the security report, unless you are fully aware of the attack scope, technical details, and vulnerable environments.\n\n## Understand and mitigate with Vulnerability Explanation \n\nUnderstanding the vulnerability and how to fix it in the best and most efficient way is crucial. Fixes must not break existing functionality. If they do, a discussion with maintainers and product owners will be necessary, and, as such, will require a high-level summary and potential mitigation alternatives. Code that someone who left the company wrote or code that has no tests can make the planning for a fix even more difficult. \n\nAI-powered Vulnerability Explanation helps with a summary of how an attacker can exploit the vulnerability, and provides more explanations about the impact and potential fixes. \n\nThe following example shows an OS Command Injection vulnerability, using this code snippet:\n\n```php\n\u003C?php \n\n// Read variable name from GET request\n$name = $_GET['name'];\n\n// Use the variable name to call eval and print its value \neval('echo $' . $name . ';');\n```\n\nThe vulnerability report does not go into much detail, and requires understanding of the full context and impact. Select `Explain vulnerability` from the upper right corner, which will open GitLab Duo Chat with a pre-defined prompt action. This will give an additional summary of the vulnerability, describe how the vulnerability can be exploited, and provide a suggested fix. \n\n![Improper Neutralization of\nSpecial Elements used in an OS Command\n('OS Command Injection') ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098116057.png)\n\n### Make Vulnerability Explanation a conversation with context \n\nYou’ll also recognize a change in UX: The previous vulnerability explanation overlay was replaced with a GitLab Duo Chat workflow. Sometimes, a complex vulnerability unfolds into multiple mitigation steps, or unclear source code paths.\n\nYou can navigate into the source code tree, and continue with the same Chat context to explain, fix, refactor, and test the code. \n\nLet’s try the full workflow with an example in C, where security scanning detected a buffer overflow.\n\n1. Open the security vulnerability detail view, and select \"Explain vulnerability\" on the button in the upper right. This will open up the Chat prompt, providing a summary of the problem, potential attack vectors, and a proposed fix.\n\n![AI for vulnerabilities - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098116059.png)\n\n2. Review the proposed fix, and ask Chat in a follow-up prompt to share alternative paths, using `Can you show an alternative fix using a different function`. The idea is to learn about alternative functions to `strcpy()` that can be more safe to use. \n\n![AI for vulnerabilities - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098116060.png)\n\n3. Chat comes up with an alternative fix using `strlcpy()` in the following example. The function only copies as many characters as allowed in the target string, and always terminates the string with null. It also returns the length of the source string to determine whether the string was truncated. \n\n![AI for vulnerabilities - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098116062.png)\n\n4. Next, click on the `Location` file URL to jump into the source code view. Open Chat again, and verify that the previous vulnerability explanation context is still there. As a next step, we want to add tests before continuing with a proposed fix. This helps to avoid breaking functionality or introduce regressions. For example, use this Chat prompt: `Based on the vulnerability context and opened source code, how would you add tests for it?`.\n\n![AI for vulnerabilities - image 7 ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098116063.png)\n\n5. After generating tests (and assuming they were added now), you can also ask Chat to refactor the source code, using the prompt `Can you refactor the source code too?` in the same session.\n\n![AI for vulnerabilities - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098116063.png)\n\nThe workflow shows how to analyze, understand, mitigate, get alternative approaches, add tests, and even refactor fixes for vulnerabilities. \n\nYou can continue this path using Chat, and then switch into the Web IDE to modify the source code after learning how to do it. Additional continued workflows include committing changes and triggering CI/CD and security scans for the full DevSecOps lifecycle loop. \n\n## Remediate with AI-assisted Vulnerability Resolution \n\nUnderstanding and mitigating a security vulnerability still requires engineering work to create a fix for the problem, run pipelines and security scanning in a new merge request again. It can also be necessary to deploy the fixes into a staging environment and test them for a longer period of time.\n\nAI can help here with generating a proposed fix based on the provided context of the vulnerability and source code.\n\nTip: Think of the most annoying vulnerability you had to fix in your career, and re-create the use case example for your GitLab Duo adoption. The [MITRE CWE Top 25 of the most dangerous software weaknesses](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html) also provides a good starting point.  \n\nThe following example implements [CWE-328: Use of a weak hash function](https://cwe.mitre.org/data/definitions/328.html) by using `md5`. It is correctly identified by [SAST scanning](https://docs.gitlab.com/ee/user/application_security/sast/). \n\n```python\nimport hashlib\n\nclass User:\n    def __init__(self, username, password):\n        self.username = username\n        self.password = password\n\n    def set_password(self, password):\n        self.password = hashlib.md5(password.encode()).hexdigest()\n```\n\n![AI for vulnerabilities - image 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098116064.png)\n\nClick on the button in the upper right `Resolve with merge request`.  This will open an MR that uses AI to propose the fix. For this vulnerability, one possible fix could be using a different hash function. \n\n![AI for vulnerabilities - image 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098116065.png)\n\nAnother common vulnerability example is not checking function error codes or potential exceptions. The following C code snippets implement an example for timing attacks against file operations with [CWE-362](https://cwe.mitre.org/data/definitions/362.html) for the `fopen()` and `chmod()` calls. \n\n```c\n#include \u003Cstdio.h>\n#include \u003Cstring.h>\n#include \u003Csys/mman.h>\n#include \u003Csys/stat.h>\n#include \u003Cunistd.h>\n\nint main(int argc, char **argv) {\n\n    // File operations\n    char *fname = \"gitlab.keksi\";\n\n    FILE *fp;\n    fp = fopen(fname, \"r\");\n    fprintf(fp, \"Hello from GitLab Duo Vulnerability Resolution Challenge\");\n    fclose(fp);\n\n    // Potential chmod() timing attacks    \n\n    // Make the file world readable\n    chmod(fname, S_IRWXU|S_IRWXG|S_IRWXO);\n\n    return 0;\n}\n```\n\nThe SAST report for `chmod()` can look like the following: \n\n![AI for vulnerabilities - image 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098116065.png)\n\nThe proposed `chmod()` merge request includes error handling, and fixes another potential issue with world writable files, changing the permissions from `777` to `600`.\n\n![AI for vulnerabilities - image 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098116066.png)\n\n> Try this async exercise: Find, analyze, and fix the vulnerability for the `fopen()` function.\n\n## More AI assistance required from GitLab Duo \n\nOften, a security problem can be resolved with a quick fix or a workaround that grants the development teams time to discuss and plan a more long-term solution. In other cases, the problem becomes more complex and requires feature APIs disabled, or firewall mitigation, until a proper fix can be rolled into production.\n\nGitLab Duo offers additional AI-powered features that can help resolve these issues. \n\n**Code Explanation:** As a developer or security engineer, it's crucial to feel confident in the changes you've made. Within the IDE, you can use the [Code Explanation feature](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide) to gain a deeper understanding of the AI-suggested fix for the vulnerability. This ensures you know exactly what adjustments have been made and why.\n\n**Root Cause Analysis:** If the fix breaks your pipeline, you can utilize the [Root Cause Analysis feature](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/). This tool helps identify and explain the underlying problem, allowing you to address it effectively. After applying the necessary corrections, you can rerun the tests to ensure a successful resolution.\n\n**Refactor:** Even if the vulnerability has been fixed, it's worth considering if the code can be written in a safer manner. In the IDE, you can open GitLab Duo Chat and use the [refactor action](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide) to explore alternative, more secure ways to write your code. This proactive approach helps maintain a robust and secure codebase.\n\nBy leveraging these GitLab Duo features, you can confidently navigate and resolve vulnerabilities, ensuring your code remains secure and efficient.\n\n## What’s next?\n\nWe plan to bring both Vulnerability Explanation and Vulnerability Resolution \"left\" by incorporating them directly into the MR process. This integration ensures that you can address and resolve vulnerabilities earlier in the development cycle, streamlining your workflow and enhancing code security from the outset.\n\n## Get started with GitLab Duo\n\nPlease see our [documentation](https://docs.gitlab.com/ee/user/gitlab_duo/turn_on_off.html) on how to enable the feature available to our GitLab Ultimate customers. Also, GitLab Duo [Vulnerability Explanation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability) and [Vulnerability Resolution](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution) will soon be coming to GitLab self-managed and GitLab Dedicated.\n\nYou can keep up with what's new in GitLab Duo by [following the \"Developing GitLab Duo\" blog series](https://about.gitlab.com/blog/developing-gitlab-duo-series/).\n\n> Start [a free trial of GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial) to bring these powerful vulnerability remediation benefits to your own organization!\n",[786,704,701,9,746],{"slug":2119,"featured":90,"template":683},"developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","content:en-us:blog:developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","Developing Gitlab Duo Use Ai To Remediate Security Vulnerabilities","en-us/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","en-us/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"_path":2125,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2126,"content":2132,"config":2137,"_id":2139,"_type":13,"title":2140,"_source":15,"_file":2141,"_stem":2142,"_extension":18},"/en-us/blog/devops-adoption",{"title":2127,"description":2128,"ogTitle":2127,"ogDescription":2128,"noIndex":6,"ogImage":2129,"ogUrl":2130,"ogSiteName":670,"ogType":671,"canonicalUrls":2130,"schema":2131},"Understand how your teams adopt DevOps with DevOps reports","Learn about analytics, DevOps reports, DevOps scores, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668473/Blog/Hero%20Images/john-schnobrich-FlPc9_VocJ4-unsplash.jpg","https://about.gitlab.com/blog/devops-adoption","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understand how your teams adopt DevOps with DevOps reports\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n        \"datePublished\": \"2021-12-15\",\n      }",{"title":2127,"description":2128,"authors":2133,"heroImage":2129,"date":2134,"body":2135,"category":1513,"tags":2136},[972],"2021-12-15","\n\nGitLab has an extraordinary range of features for a single application, providing an [entire DevOps platform](/stages-devops-lifecycle/) from [portfolio planning](/stages-devops-lifecycle/plan/) all the way through to [monitoring](/stages-devops-lifecycle/monitor/) and [service desk](https://docs.gitlab.com/ee/user/project/service_desk/). As such, GitLab is uniquely positioned to deliver a complete picture of your organization's DevOps journey and your return on investment in automation and DevOps practices.\n\nSome of the most interesting and difficult questions that organizations ask themselves are:\n\n* What do we gain from different development practices used by our teams?\n* What makes one team more efficient than another?\n* What practices have been successful in one team that we can introduce to others?\n\n## Analytics\n\nGitLab has several metrics to give you insight into the development lifecycle:\n\n* [Application Security](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#project-security-dashboard) -  provides a comprehensive set of features for viewing and managing vulnerabilities.\n* [CI/CD](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html) - tracks the history of your pipeline successes and failures, as well as how long each pipeline ran.\n* [Code Review](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html) - displays open merge requests and their review time.\n* [Insights](https://docs.gitlab.com/ee/user/project/insights/index.html)- allows you to configure custom analytics that will be displayed.\n* [Issue](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html) - illustrates the number of issues created each month.\n* [Merge Request](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html) - displays information that will help you evaluate the efficiency and productivity of your merge request process.\n* [Repository](https://docs.gitlab.com/ee/user/analytics/repository_analytics.html) - displays information such as commit statistics, code coverage, and programming languages used in the repository.\n* [Value Stream Analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html) - measures the time spent to go from an idea to production.\n\nSome analytics are only available for instance-level (self-managed), group level, or project level. Read [more](https://docs.gitlab.com/ee/user/analytics/) about analytics.\n\nThese analytics are a great way to see contributions from different projects and groups. On their own, however, they don't give insights into which processes your teams are using. For that, we offer DevOps Reports.\n\n## DevOps adoption reports\n\nDevOps Adoption is a DevOps Report located in group-level analytics. It shows you data for how teams in your organization use the most essential GitLab features.\n\nYou can use DevOps Adoption to:\n\n- Identify specific subgroups that are lagging in their adoption of GitLab features, so you can guide them on their DevOps journey.\n- Find subgroups that have successfully adopted certain features, and could provide guidance to other subgroups on how to use those features.\n- Verify if you are getting the return on investment that you expected from GitLab.\n\n![DevOps Adoption](https://about.gitlab.com/images/blogimages/devops_reports.png){: .shadow}\n\nIn this example, we can see some interesting data on how a team uses features in development, security, and operations categories:\n\n* **Development**\n  * Approvals: At least one merge request approval on a merge request.\n  * Code owners: At least 1 defined code owner that owns a specific file or repository in the group.\n  * Issues: At least 1 issue opened in this group.\n  * Merge requests: At least 1 merge request opened in this group.\n* **Security**\n  * DAST:  At least 1 DAST scan run in a pipeline in the group.\n  * Dependency Scanning: At least 1 dependency scan ran in a pipeline in the group.\n  * Fuzz Testing: At least 1 fuzz testing scan ran in a pipeline in the group.\n  * SAST: At least 1 SAST scan ran in a pipeline in the group.\n* **Operations**\n  * Deployments: At least 1 deployment.\n  * Pipelines: At least 1 pipeline ran successfully.\n  * Runners: At least 1 runner configured for the project or group.\n\nIn the future we plan to add even more feature categories to DevOps Reports, such as:\n* [Environments](https://docs.gitlab.com/ee/ci/environments/#environments-and-deployments)\n* [Pages](https://docs.gitlab.com/ee/user/project/pages/)\n* [Compliance Pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration)\n* [Incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html)\n* [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/#review-apps)\n\n...and much more. You can follow our future plans in the following [epic](https://gitlab.com/groups/gitlab-org/-/epics/5019).\n\n_DevOps Reports are available for the Ultimate tier for self-managed and SaaS users. To find DevOps Reports, go to your group and in the left sidebar, select Analytics > DevOps adoption_\n\n## DevOps Score\n\nYou can use the DevOps score to compare your DevOps status to other organizations.\n\nThe DevOps Score tab shows usage of major GitLab features on your instance over the last 30 days. GitLab calculates the averages feature usage based on the number of billable users in that time period. You can also see the Leader usage score, calculated from top-performing instances based on Service Ping data that GitLab collects. GitLab compares your score to the lead score of each feature and shows it as a percentage underneath the feature. Your overall DevOps Score is an average of your feature scores.\n\nTo analyze your DevOps Score, GitLab aggregates Service Ping (sometimes referred to as Usage Ping) data on GitLab servers for analysis. Your usage information is not sent to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for GitLab to collect enough data to calculate your DevOps Score.\n\n![DevOps Score](https://about.gitlab.com/images/blogimages/dev_ops_score_v12_6.png){: .shadow}\n\n_DevOps score is available at the admin panel for all tiers under Analytics > DevOps Reports._\n\nTo see the DevOps score, you must activate your GitLab instance’s [Service Ping](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#service-ping). This is because DevOps Score is a comparative tool, so your score data must first be centrally processed by GitLab, Inc.\n\nThere are several benefits of enabling Service Ping, such as DevOps Score and cohorts:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZhLrhZlb_zI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Cohorts\n\nCohorts shows your teams' GitLab activities over time, and is a useful tool for administrators to view user retention and manage seats in their GitLab instance.\n\n![Cohorts](https://about.gitlab.com/images/blogimages/cohorts_v13_9_a.png){: .shadow}\n\nUsers are considered active if they have performed at least one of the following activities:\n\n* Sign in to GitLab.\n* Perform a Git activity such as push or pull.\n* Visit pages related to dashboards, projects, issues, or merge requests.\n* Use the API.\n* Use the GraphQL API.\n\nCover image credit:\n\nCover image by [John Schnobrich](https://unsplash.com/photos/FlPc9_VocJ4) on [Unsplash](https://unsplash.com)\n{: .note}\n",[851,9,746],{"slug":2138,"featured":6,"template":683},"devops-adoption","content:en-us:blog:devops-adoption.yml","Devops Adoption","en-us/blog/devops-adoption.yml","en-us/blog/devops-adoption",{"_path":2144,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2145,"content":2151,"config":2157,"_id":2159,"_type":13,"title":2160,"_source":15,"_file":2161,"_stem":2162,"_extension":18},"/en-us/blog/elasticsearch-update",{"title":2146,"description":2147,"ogTitle":2146,"ogDescription":2147,"noIndex":6,"ogImage":2148,"ogUrl":2149,"ogSiteName":670,"ogType":671,"canonicalUrls":2149,"schema":2150},"Update: The challenge of enabling Elasticsearch on GitLab.com","How we got started with enabling Elasticsearch on the largest GitLab instance, GitLab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666832/Blog/Hero%20Images/enable-global-search-elasticsearch.jpg","https://about.gitlab.com/blog/elasticsearch-update","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Update: The challenge of enabling Elasticsearch on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Thomas\"}],\n        \"datePublished\": \"2019-07-16\",\n      }",{"title":2146,"description":2147,"authors":2152,"heroImage":2148,"date":2154,"body":2155,"category":849,"tags":2156},[2153],"Nick Thomas","2019-07-16","\nBack in March, [Mario](/company/team/#mdelaossa) shared some of the [lessons we'd learned from our last attempt to enable\nElasticsearch](/blog/enabling-global-search-elasticsearch-gitlab-com/) on GitLab.com, an integration that would unlock both [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_search.html)\nand [Advanced Syntax Search](https://docs.gitlab.com/ee/user/search/advanced_search.html). Since then, we've been working hard to address problems with the integration and prepare for [another attempt](https://gitlab.com/groups/gitlab-org/-/epics/853).\n\n## Selective indexing\n\nAt the heart of our dilemma was a classic \"chicken and egg\" problem. We needed\nto gather more information about [Elasticsearch](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html) to make improvements to the total\nindex size, but without an active deployment, that information was very hard to\ngather. Customer feedback and small-scale testing in development environments\nall help, but [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding)\nthe integration is the best way to get the information we require.\n\nTo resolve this, we prioritized changes to enable Elasticsearch integration on\nGitLab.com. Since the index size was a hard problem, this meant some kind of\nselective indexing was necessary, so we've added\n[per-project and per-group controls](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html).\n\nOn Jun. 24, 2019, we enabled the integration for the `gitlab-org` group on\nGitLab.com. Now, any searches at the group or project level will make use of the\nElasticsearch index, and the advanced features the integration unlocks will be available.\nWe figured, why not [give it a try](https://gitlab.com/search?search=gitlab-org+%28gitaly+%7C+ee%29&group_id=9970)?\n\nThe total index size for this group – which includes about 500 projects – is around 2.2\nmillion documents and 15GB of data, which is really easy to manage from the point of view of\nElasticsearch administration. The indexing operation itself didn't [go as smoothly as we hoped](https://gitlab.com/gitlab-com/gl-infra/production/issues/800), however!\n\n## Bug fixes\n\nAnother advantage to having selective Elasticsearch indexing enabled on GitLab.com\nis that our engineers need confidence that the feature is performant,\nthat it won't threaten the overall stability of GitLab.com, and that it is\nsubstantially bug-free. So we went through a [Production Readiness Review](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/64)\nbefore enabling it. The review uncovered a number of pre-existing bugs and new regressions, which have all been fixed in the\n[12.0 release](/releases/2019/06/22/gitlab-12-0-released/). Some of the bugs included:\n\n* [Elasticsearch was sometimes used for searches, even when disabled](https://gitlab.com/gitlab-org/gitlab-ee/issues/11795)\n* [Performance regression indexing database content](https://gitlab.com/gitlab-org/gitlab-ee/issues/11595)\n* [Regression searching for some projects at group level](https://gitlab.com/gitlab-org/gitlab-ee/issues/12091)\n* [Regression visiting page 2 of search results](https://gitlab.com/gitlab-org/gitlab-ee/issues/12254)\n* [Wiki indexing still relied on a shared filesystem](https://gitlab.com/gitlab-org/gitlab-ee/issues/11269)\n* [Searching snippets with Elasticsearch enabled still queries the database, not Elasticsearch](https://gitlab.com/gitlab-org/gitlab-ee/issues/10548)\n\nWe still can't claim to be bug-free, of course, but the picture is a lot rosier than if we'd attempted to roll out this feature without first using it ourselves.\n\nWe'd tested the new indexing code on our staging environment, but this was last\nrefreshed more than a year ago, and was significantly smaller than the group on\nGitLab.com, containing around 150 projects. As a result, some bugs and\nscalability issues were uncovered for the first time in production. We're\naddressing them with high priority in the 12.1 and 12.2 releases. The scaling issues include:\n\n* [Project imports unconditionally enqueue an ElasticCommitIndexerWorker](https://gitlab.com/gitlab-org/gitlab-ee/issues/12362)\n* [Allow maximum bulk request size to be configured](https://gitlab.com/gitlab-org/gitlab-ee/issues/12375)\n* [Intelligently retry bulk-insert failures when indexing](https://gitlab.com/gitlab-org/gitlab-ee/issues/12372)\n* [Note bulk indexing often fails due to statement timeout](https://gitlab.com/gitlab-org/gitlab-ee/issues/12402)\n* [Cannot index large snippets](https://gitlab.com/gitlab-org/gitlab-ee/issues/12111)\n* [Removing documents from the index can fail with a conflict error](https://gitlab.com/gitlab-org/gitlab-ee/issues/12114)\n\nOnce these issues are addressed, indexing at scale should be quick, easy, and\nreliable. Indexing at scale is invaluable from the point of view of an engineer trying out\nchanges to reduce total index size.\n\n## Administration\n\nAnother area for improvement is administering the indexing process\nitself. Although GitLab automatically creates, updates, and removes documents\nfrom the index when changes are made, backfilling existing data required manual\nintervention, running a set of complicated (and slow) rake tasks to get the\npre-existing data into the Elasticsearch index. Unless these instructions were\nfollowed correctly, search results would be incomplete. There was also no way\nto configure a number of important parameters for the indexes created by GitLab.\n\nWhen using the selective indexing feature, GitLab now automatically enqueues\n\"backfill\" tasks for groups and projects as they are added, and removes the\nrelevant records from the index when they are supposed to be removed. We've also made it possible to\n[configure the number of shards and replicas](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html)\nfor the Elasticsearch index directly in the admin panel, so when GitLab creates\nthe index for you, there's no need to manually change the parameters afterwards.\n\nPersonal snippets are the one type of document that won't be respected in the\nselective-indexing case. To ensure they show up in search results, you'll still\nneed to run the [`gitlab:elastic:index_snippets`](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html) rake task [for now](https://gitlab.com/gitlab-org/gitlab-ee/issues/12333).\n\nThere are also improvements if you're not using selective indexing – the admin\narea now has a \"Start indexing\" button. Right now, this only makes sense if\nstarting from an empty index, and doesn't index personal snippets either, but\nwe're hopeful we can [remove the rake tasks entirely](https://gitlab.com/gitlab-org/gitlab-ee/issues/11206)\nin the future.\n\n## What next?\n\nWe're really happy to have Elasticsearch enabled for the `gitlab-org` group, but\nthe eventual goal is to have it [enabled on all of GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/153).\nWe'll be rolling it out to more groups in the future.\n\nTo get there, we'll need to continue to improve the\n[administration experience](https://gitlab.com/groups/gitlab-org/-/epics/428) using Elasticsearch.\nFor instance, it's still difficult to see the indexing status of a group or\nproject at a glance, a function that would be really useful for our support team to answer\nqueries like \"Why isn't this search term returning the expected results?\"\n\n### Managing the Elasticsearch schema is also a challenge\n\nCurrently, we take the easy route of reindexing everything if we need to change some aspect of the\nschema, which doesn't scale well as the index gets larger. [Some\nwork on this is ongoing](https://gitlab.com/gitlab-org/gitlab-ee/issues/328),\nand the eventual goal is for GitLab to automatically manage changes to the\nElasticsearch index in the same way it does for the database.\n\n[Reducing the index size](https://gitlab.com/groups/gitlab-org/-/epics/429) is\nstill a huge priority, and we hope to make progress on this now that we\nhave an Elasticsearch deployment to iterate against.\n\n### We'd also like to improve the quality of search results\n\nFor example, we have\nreports of code search [failing to find certain identifiers](https://gitlab.com/gitlab-org/gitlab-ee/issues/10693) and we'd like to use the Elasticsearch index in more contexts, such as for\n[filtered search](https://gitlab.com/gitlab-org/gitlab-ee/issues/12082).\n\nThe Elasticsearch integration is progressing. Finally, responsibility for the Elasticsearch integration has been passed from\nthe [Plan stage](/handbook/product/categories/#plan-stage)\nto the [Editor group of the Create stage](/handbook/product/categories/#editor-group).\nI hope you'll join Mario and me in wishing [Kai](/company/team/#phikai),\n[Darva](/company/team/#DarvaSatcher), and the rest of the team the best of luck in tackling the remaining challenges for Elasticsearch. An up-to-date overview of their plans can always be found on\nthe [search strategy](/direction/global-search/) page.\n\nPhoto by [Benjamin Elliott](https://unsplash.com/photos/vc9u77c0LO4) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[9,230,680],{"slug":2158,"featured":6,"template":683},"elasticsearch-update","content:en-us:blog:elasticsearch-update.yml","Elasticsearch Update","en-us/blog/elasticsearch-update.yml","en-us/blog/elasticsearch-update",{"_path":2164,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2165,"content":2171,"config":2176,"_id":2178,"_type":13,"title":2179,"_source":15,"_file":2180,"_stem":2181,"_extension":18},"/en-us/blog/eliminate-risk-with-feature-flags-tutorial",{"title":2166,"description":2167,"ogTitle":2166,"ogDescription":2167,"noIndex":6,"ogImage":2168,"ogUrl":2169,"ogSiteName":670,"ogType":671,"canonicalUrls":2169,"schema":2170},"How to use feature flags to lower risk in deployments","Follow this comprehensive tutorial to learn how to create and use feature flags in your software development environment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667743/Blog/Hero%20Images/flags.png","https://about.gitlab.com/blog/eliminate-risk-with-feature-flags-tutorial","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use feature flags to lower risk in deployments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2023-09-20\",\n      }",{"title":2166,"description":2167,"authors":2172,"heroImage":2168,"date":2173,"body":2174,"category":1513,"tags":2175},[803],"2023-09-20","\nDevelopers typically use advanced techniques like canary, blue/green, and incremental deployments to reduce risk when practicing progressive delivery, a facet of continuous delivery (CD). In this tutorial, we will show you how to use feature flags, another progressive delivery option developers can use to test while in production.\n\n## What is progressive delivery?\nProgressive delivery is the ability to test in production while controlling your audience of who can exercise or see updates to an application with a high level of granularity. This approach can also be thought of as developer experimentation.\n\n## What are feature flags\nFeature flags enable you to choose what to deploy and who to deploy to in production. They allow you to define the audience for your application updates as well as the fashion in which they will be served.\n\nFeature flags help stakeholders reduce risk, allowing them to do controlled testing of features and separate feature delivery from customer launch.\n\n## Benefits of feature flags\nThe following are benefits of GitLab's feature flags.\n- **Lower risk.** Feature flags prevent unscheduled outages, control your audience in a fine-grained fashion, and can be optionally used in conjunction with canary deployments.\n- **Ease of use.** Feature flags have simple configurability and instrumentation, support user lists, and offer built-in service.\n- **Language agnostic.** Our feature flag implementation supports all of the main programming languages.\n- **Better compliance and audit capabilities.** The GitLab platform automatically records all feature flags actions.\n\n## Tutorial requirements\nThis is what you need for this tutorial:\n1. A GitLab account on gitlab.com SaaS\n2. Flux CLI installed on your local desktop (on my Mac, I installed it by executing `brew install fluxcd/tap/flux`)\n3. A running Kubernetes cluster, i.e. a GKE cluster with 3 e2-medium nodes\n4. `kubectl` connectivity to your Kubernetes cluster from a local Terminal window on your desktop\n\n## About this feature flag tutorial\nThis tutorial is based on a fictitious application, which is a simplified inventory system. The goal of this tutorial is to show you how to create, configure, and implement a feature flag using GitLab.\n\n**Note:** This tutorial is for learning purposes and not meant to deploy a production-ready architecture. Also, to keep the number of steps low, masked variables and sealed secrets are not being used throughout this tutorial.\n\n## Flux and the GitLab agent for Kubernetes\nHere is how to install Flux and GitLab agent for Kubernetes.\n- Log on to your GitLab workspace.\n- Create a personal access token (PAT) from your GitLab account by navigating to **User settings > Preferences > Access tokens**. In the **Personal Access Tokens** section, click on the **Add new token** button on the righthand side of the section. For **Token name**, enter `pat-for-flux`. Leave the expiration date with its default (it should be 30 days from its creation) and select the **API** scope for your **PAT**. Click on the **Create personal access token** button to create your PAT. Copy and save the value of your **PAT**; you will need it at a later step.\n\n![create-pat](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-pat.png){: .shadow.medium.center}\nCreating a personal access token\n{: .note.text-center}\n\n- Head back to your GitLab workspace main page.\n- Create a group named “hn” by clicking the button **New group** (or **New subgroup** if you are creating this group inside an existing group) on the top right hand side of your screen, and then clicking on the **Create group** tile. Enter \"hn\" for your **Group name** and click on the **Create group** button to create it. Leave the rest of the fields with their defaults.\n\n![create-group-hn](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-group-hn.png){: .shadow.medium.center}\nCreating group \"hn\"\n{: .note.text-center}\n\n- Inside group “hn”, create project “flux-config” by clicking the **New project** on the top righthand side of your screen and then clicking on the **Create blank project** tile.\n\n![create-proj-flux-config](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-proj-flux-config.png){: .shadow.medium.center}\nCreating project \"flux-config\"\n{: .note.text-center}\n\n- From the Terminal window with `kubectl` access to your Kubernetes cluster, export your **PAT** by entering the following command:\n\n> export GITLAB_TOKEN=`\u003Creplace with your PAT value>`\n\n- From the Terminal window with `kubectl` access to your Kubernetes cluster, bootstrap Flux by executing the following command:\n\n**Note:** Make sure to replace `\u003Cyour path>` with whatever precedes your group “hn”. For example, it could be `--owner=tech-marketing/sandbox/hn`, or if your group “hn” is at the very top level of your GitLab workspace, it would be `--owner=hn`.\n\n```\nflux bootstrap gitlab \\\n  --owner=\u003Cyour path>/hn \\\n  --repository=flux-config \\\n  --branch=main \\\n  --path=clusters/my-cluster \\\n  --deploy-token-auth\n```\n\n![flux-bootstrap-output](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/flux-bootstrap-output.png){: .shadow.medium.center.}\nFlux bootstrap output\n{: .note.text-center}\n\nThe “flux-config” project should now contain new directories and files as shown below:\n\n![flux-config-post-bootstrap](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/flux-config-post-bootstrap.png){: .shadow.medium.center}\nProject flux-config post flux bootstrap process\n{: .note.text-center}\n\n- Head over to project **hn/flux-config** and create file “.gitlab/agents/k8s-agent/config.yaml” by clicking on the **+** sign next to the “flux-config” and selecting **New file**. Paste the following into it the new file:\n\n**Note:** Make sure to replace `\u003Cyour path>` with whatever precedes your group “hn”. For example, it could be `- id: tech-marketing/sandbox/hn` or if your group “hn” is at the very top level of your GitLab workspace, it would be `- id: hn`.\n\n```\nci_access:\n  groups:\n    - id: \u003Cyour path>/hn\n```\n\nCommit this file to main by clicking on the **Commit changes** button and ensuring that the target branch is “main”.\n\n![create-config-yaml](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-config-yaml.png){: .shadow.medium.center}\nCreating the GitLab agent for Kubernetes configuration manifest\n{: .note.text-center}\n\n- Head to **Operate > Kubernetes clusters** and register the agent by clicking the **Connect a cluster** button.\n\n![register-agent](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/register-agent.png){: .shadow.medium.center}\nRegistering the GitLab agent for Kubernetes\n{: .note.text-center}\n\n- On the “Connect a Kubernetes cluster” dialog, click on the popdown list and select agent “k8s-agent”. Click on the **Register** button. The dialog will refresh and show the **Agent access token**. Copy and save the **Agent access token**; you will need it at a later step. Close the dialog by clicking on the **Close** button.\n\n![agent-access-token-dialog](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/agent-access-token-dialog.png){: .shadow.medium.center}\nThe agent access token to save\n{: .note.text-center}\n\nAt this moment, you will see the agent listed and its Connection status will be “Never connected”.\n\n![agent-not-connected](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/agent-not-connected.png){: .shadow.medium.center}\nAgent registered but not connected yet\n{: .note.text-center}\n\n-  Head to **flux-config/clusters/my-cluster** directory and create a file named “namespace-gitlab.yaml” and paste the following into it:\n\n```\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: gitlab\n```\n\n![gitlab-namespace-manifest](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/gitlab-namespace-manifest.png){: .shadow.medium.center}\nManifest for the gitlab namespace\n{: .note.text-center}\n\nCommit this file to main by clicking on the **Commit changes** button and ensuring that the target branch is “main”.\n\n```\nNote: You can check that the namespace was created in your cluster by executing this command from a Terminal:\n\nkubectl get ns\n```\n\n![gitlab-ns-created](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/gitlab-ns-created.png){: .shadow.medium.center}\nFlux created gitlab namespace\n{: .note.text-center}\n\n- Before we have Flux deploy the GitLab agent for Kubernetes to your cluster, we need to create a secret, containing the **Agent access token** you saved earlier, in your cluster. Create a file named “secret.yaml” in your local desktop, paste the following into it and then save it:\n\n**Note:** Make sure to replace `\u003Cyour-agent-access-token-here>` with your **Agent access token** you saved earlier.\n\n```\napiVersion: v1\nkind: Secret\nmetadata:\n  name: gitlab-agent-token-initial\ntype: Opaque\nstringData:\n  values.yaml: |-\n    config:\n      token: \"\u003Cyour-agent-access-token-here>\"\n```\n\n![agent-token-secret](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/agent-token-secret.png){: .shadow.medium.center.}\nManifest for agent token secret created on local desktop\n{: .note.text-center}\n\n- Create the secret in your cluster by executing the following command from a Terminal:\n\n> kubectl apply -f secret.yaml -n gitlab\n\n```\nNote: You can check that the secret was created in your cluster by executing this command from a Terminal:\n\nkubectl get secrets -n gitlab\n```\n\n![apply-agent-token-secret](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/apply-agent-token-secret.png){: .shadow.medium.center}\nApplying the agent token secret to the Kubernetes cluster\n{: .note.text-center}\n\n- Now let’s use the Flux Helm Controller to deploy the GitLab agent for Kubernetes to your cluster. Head to **flux-config/clusters/my-cluster** directory and create a file named “agentk.yaml” and paste the following into it:\n\n```\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: HelmRepository\nmetadata:\n  labels:\n    app.kubernetes.io/component: agentk\n    app.kubernetes.io/created-by: gitlab\n    app.kubernetes.io/name: agentk\n    app.kubernetes.io/part-of: gitlab\n  name: gitlab-agent\n  namespace: gitlab\nspec:\n  interval: 1h0m0s\n  url: https://charts.gitlab.io\n---\napiVersion: helm.toolkit.fluxcd.io/v2beta1\nkind: HelmRelease\nmetadata:\n  name: gitlab-agent\n  namespace: gitlab\nspec:\n  chart:\n    spec:\n      chart: gitlab-agent\n      sourceRef:\n        kind: HelmRepository\n        name: gitlab-agent\n        namespace: gitlab\n  interval: 1h0m0s\n  values:\n    replicas: 1\n    config:\n      kasAddress: \"wss://kas.gitlab.com\"  \n  valuesFrom:\n    - kind: Secret\n      name: gitlab-agent-token-initial\n      valuesKey: values.yaml\n```\n\n![create-agentk-manifest](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-agentk-manifest.png){: .shadow.medium.center}\nCreating the manifest for the GitLab agent for Kubernetes\n{: .note.text-center}\n\nCommit this file to main by clicking on the **Commit changes** button and ensuring that the target branch is “main”.\n\n```\nNote: In a few seconds, you can check that the GitLab agent for Kubernetes was created in your cluster by executing this command from a Terminal (the pod name should start with “gitlab-agent”):\n\nkubectl get pods -n gitlab\n```\n![agentk-pod-up](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/agentk-pod-up.png){: .shadow.medium.center}\nAgentk running in the Kubernetes cluster\n{: .note.text-center}\n\n## Creating an instance of MySQL database in your cluster via Flux\n- Using the breadcrumb at the top of your window, head to group “hn” and create a new project by clicking on the **New project** button. On the **Create new project** window, click on the **Import project** tile.\n- At the **Import project** window, click on the **Repository by URL** button. The window will display fields to enter the URL of the repository you would like to import. In the text field **Git repository URL**, enter the following:\n\n> [https://gitlab.com/tech-marketing/sandbox/mysql.git](https://gitlab.com/tech-marketing/sandbox/mysql.git)\n\nLeave the rest of the fields with their defaults.\n\n![import-mysql-proj](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/import-mysql-proj.png){: .shadow.medium.center}\nImporting mysql project into group \"hn\"\n{: .note.text-center}\n\n- Click on the **Create project** button at the bottom of the screen. You will see an \"Importing in progress\" message temporarily on your screen.\n- Now we need to create a deploy token for this project so that Flux can interact with it. While in project “mysql”, select **Settings > Repository** and scroll down to the **Deploy tokens** section. Click on the **Expand** button to the right of the **Deploy tokens** section. Then click on the **Add token** button, which will expand the section to include fields to start entering information for the deploy token to be created.\n- Give the deploy token the name “mysql-flux-deploy-token” and check the checkbox **read_repository** for it. Then click on the button **Create deploy token** to create the token.\n\n![create-mysql-deploy-token](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-mysql-deploy-token.png){: .shadow.medium.center}\nCreating the deploy token for \"mysql\" project for Flux to interact with it\n{: .note.text-center}\n\nCopy and save the username and password for the newly created deploy token; you will need them at a later step.\n\n![mysql-deploy-token-created](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/mysql-deploy-token-created.png){: .shadow.medium.center}\nCreating the deploy token for \"mysql\" project for Flux to interact with it\n{: .note.text-center}\n\n-  From a Terminal, execute the following command to create a secret in your cluster for the deploy token you just created:\n\n**Note:** Make sure to replace `\u003Cyour path>` with the missing partial path to the project “mysql”, \u003Cyour-deploy-token-username> with the deploy token username you saved earlier, and the \u003Cyour-deploy-token-password> with the deploy token password you saved earlier.\n\n```\nflux create secret git mysql-flux-deploy-authentication \\\n         --url=https://gitlab.com/\u003Cyour path>/hn/mysql \\\n         --namespace=default \\\n         --username=\u003Cyour-deploy-token-username> \\\n         --password=\u003Cyour-deploy-token-password>\n```\n\n```\nNote: You can check that the secret was created in your cluster by executing this command from a Terminal:\n\nkubectl -n default get secrets mysql-flux-deploy-authentication\n```\n\n![mysql-secret-created](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/mysql-secret-created.png){: .shadow.medium.center}\nCreating secret for the deploy token for \"mysql\" project in the Kubernetes cluster\n{: .note.text-center}\n\n- Head back to project “hn/flux-config” and open the Web IDE from it.\n\n![open-web-ide](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/open-web-ide.png){: .shadow.medium.center}\nSelecting Web IDE from the dropdown menu\n{: .note.text-center}\n\n- From inside the Web IDE, navigate to directory \"clusters/my-cluster\".\n\n![goto-clusters-mycluster](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/goto-clusters-mycluster.png){: .shadow.medium.center}\nNavigate to directory \"clusters/my-cluster\" in the Web IDE\n{: .note.text-center}\n\n- Inside “clusters/my-cluster” directory, create file “mysql-manifests-source.yaml” and paste the following text into it:\n\n**Note:** Replace `\u003Cyour path>` with the missing partial path to the project “mysql”\n\n```\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: GitRepository\nmetadata:\n  name: mysql\n  namespace: default\nspec:\n  interval: 1m0s\n  ref:\n    branch: main\n  secretRef:\n    name: mysql-flux-deploy-authentication\n  url: https://gitlab.com/\u003Cyour path>/hn/mysql\n```\n\n![create-mysql-source-manifest](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-mysql-source-manifest.png){: .shadow.medium.center}\nCreating mysql-manifests-source.yaml file in the Web IDE\n{: .note.text-center}\n\n- Still in the Web IDE, inside “clusters/my-cluster” directory, create file “mysql-manifests-kustomization.yaml” and paste the following text into it:\n\n```\napiVersion: kustomize.toolkit.fluxcd.io/v1beta2\nkind: Kustomization\nmetadata:\n  name: mysql-source-kustomization\n  namespace: default\nspec:\n  interval: 1m0s\n  path: ./\n  prune: true\n  sourceRef:\n    kind: GitRepository\n    name: mysql\n    namespace: default\n  targetNamespace: default\n```\n\n![create-mysql-kustomization-manifest](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-mysql-kustomization-manifest.png){: .shadow.medium.center}\nCreating mysql-manifests-kustomization.yaml file in the Web IDE\n{: .note.text-center}\n\n- From the Web IDE, commit both files to the main branch by clicking on the **Source Control** icon on the left vertical menu, pressing the **Commit to main** button.\n\n![commit-to-main](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/commit-to-main.png){: .shadow.medium.center}\nClicking on the Source Control icon and committing to main in the Web IDE\n{: .note.text-center}\n\nThen press the **Continue** button to confirm that you want to commit your changes to the default branch:\n\n![commit-to-main-continue](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/commit-to-main-continue.png){: .shadow.medium.center}\nClicking on the Source Control icon and committing to main in the Web IDE\n{: .note.text-center}\n\n- Flux will deploy MySQL to your Kubernetes cluster. You can close the Web IDE browser tab at this point.\n\n```\nNote: You can check that the GitLab agent for Kubernetes was created in your cluster by executing this command from a Terminal:\n\nkubectl get pods -l app=mysql\n\nYou can check the persistent volume by executing this command from a Terminal:\n\nkubectl describe pvc mysql-pv-claim\n```\n\n![mysql-pod-and-pv-up](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/mysql-pod-and-pv-up.png){: .shadow.center}\nVerifying that mysql pod and its associated persitent volume claim are up and ready\n{: .note.text-center}\n\n- Now that the MySQL pod is up and running, we need to create a database, tables, and indexes in it and also populate some of the tables with dummy data for the inventory system. Using the breadcrumb at the top of your window, head over to the “mysql” project and select **Build > Pipelines** from the left vertical navigation menu.\n\n![head-to-mysql-build-pipelines](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/head-to-mysql-build-pipelines.png){: .shadow.medium.center}\nHead to \"mysql\" project and select **Build > Pipelines** from the left vertical navigation menu\n{: .note.text-center}\n\n- Click on the **Run pipeline** button on the top right side of the **Pipelines** window. This will put you on the **Run pipeline** window. Click on the **Run pipeline** button on the bottom left of the **Run pipeline** window leaving the rest of the fields with its defaults.\n\n![run-pipeline-button](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/run-pipeline-button.png){: .shadow.medium.center}\nClicking on the **Run pipeline** button to run the project \"mysql\" pipeline\n{: .note.text-center}\n\n- At this point you will see the pipeline stage and jobs. There are two jobs under the **Build** stage: **create_and_load_db** and **clear_db**.\n\n![mysql-pipeline](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/mysql-pipeline.png){: .shadow.medium.center}\nThe \"mysql\" pipeline and its two manual jobs\n{: .note.text-center}\n\n- Click on the Play button (the right solid arrow) next to the **create_and_load_db** job name. This job will create a **product** table and a **users** table and populate them with dummy data. It will also create tables and indexes needed for storing all the session-related information as users log in and log out from the inventory system.\n\n**Note:** The **clear_db** job should only be used if you’d like to erase all of the database resources created by the **create_and_load_db** job. The **clear_db** should only be used AFTER a failed run of the **create_and_load_db** job.\n\nNow that we have the database ready to go, let’s set up the project that we will use for the creation of the feature flags.\n\n## Creating and importing projects\n- Head back to group “hn” and inside of it, create a cluster management project (you can call it “cluster-management”) at the same level as the project you imported above. You can view this [instructional video](https://www.youtube.com/watch?v=QRR3WuwnxXE&t=200s) (up to minute 6:09) to see how to do this. While applying the steps in the video for this tutorial, adjust the variables values from the video to this post as described in the following notes:\n\n**Note 1:** Make sure to create and set the KUBE_CONTEXT and KUBE_NAMESPACE variable in group “hn” and to these values:\n\n| variable | value |\n| ---          | ---      |\n| KUBE_CONTEXT | `\u003Cyour path>`/hn/flux-config:k8s-agent |\n| KUBE_NAMESPACE | my-apps |\n\nFor example, in my case `\u003Cyour path>` was “tech-marketing/sandbox/hn/flux-config:k8s-agent”. In your case, it will be different. If `\u003Cyour path>` is at the root of your GitLab workspace, then it would be empty so the value of KUBE_CONTEXT would be “hn/flux-config:k8s-agent”.\n\n![add-var-KUBE_CONTEXT](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/add-var-KUBE_CONTEXT.png){: .shadow.medium.center}\nAdding variable KUBE_CONTEXT in group \"hn\"\n{: .note.text-center}\n\n![add-var-KUBE_NAMESPACE](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/add-var-KUBE_NAMESPACE.png){: .shadow.medium.center}\nAdding variable KUBE_NAMESPACE in group \"hn\"\n{: .note.text-center}\n\n**Note 2:** As an FYI, when uncommenting the GitLab managed apps in the “helmfile.yaml” file, there will not be one for Prometheus. So, you will only uncomment the lines for ingress and cert-manager.\n\n![uncomment-ingress-and-cert-manager](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/uncomment-ingress-and-cert-manager.png){: .shadow.medium.center}\nUncommenting lines for ingress and cert-manager in file \"helmfile.yaml\"\n{: .note.text-center}\n\n**Note 3:** When the pipeline for project “cluster-management” runs, you will notice that the job “sync” is a manual job. You will need to click on its **Play** (right arrow next to its name) button to run it. Wait until the “sync” job completes successfully before continuing.\n\n![click-play-on-sync-job](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/click-play-on-sync-job.png){: .shadow.medium.center}\nJob \"sync\" is manual so you need to press on the **Play** button next to its name\n{: .note.text-center}\n\n**Note 4:** Once the pipeline finishes, for your convenience, here is the command you need to run from a Terminal window to get the **external IP** address of your cluster:\n\n```\nkubectl --namespace gitlab-managed-apps get services -o wide -w ingress-ingress-nginx-controller\n```\n\n![getting-external-ip-address](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/getting-external-ip-address.png){: .shadow.medium.center}\nRunning `kubectl` command to get the ingress IP address to the cluster\n{: .note.text-center}\n\nCreate and set a variable `KUBE_INGRESS_BASE_DOMAIN` in group “hn” and set it to the **external IP** address of your cluster and append the suffix “.nip.io” to it.\n\n![add-var-KUBE_INGRESS_BASE_DOMAIN](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/add-var-KUBE_INGRESS_BASE_DOMAIN.png){: .shadow.medium.center}\nAddding variable KUBE_INGRESS_BASE_DOMAIN in group \"hn\"\n{: .note.text-center}\n\n- Inside group “hn”, create a new project. Click on the **New project** button. On the **Create new project** window, click on the **Import project** tile and then click on the **Repository by URL** button.\n- This will expand the window and show fields to enter the URL of the repository you would like to import. In the field **Git repository URL**, enter the following:\n\n> [https://gitlab.com/tech-marketing/sandbox/prodmgr.git](https://gitlab.com/tech-marketing/sandbox/prodmgr.git)\n\nLeave the rest of the fields with their defaults.\n\n![import-prodmgr-proj](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/import-prodmgr-proj.png){: .shadow.medium.center}\nImporting project \"prodmgr\" into group \"hn\"\n{: .note.text-center}\n\n- Click on the **Create project** button at the bottom of the screen. You will see an **Importing in progress** message temporarily on your screen.\n- In project “prodmgr”, create a pipeline file and make sure to name it “.gitlab-ci.yml”. Paste the following code block into the empty file:\n\n```\ninclude:\n  template: Auto-DevOps.gitlab-ci.yml\n\nvariables:\n  K8S_SECRET_TF_VAR_dbusername: \"sasha\"\n  K8S_SECRET_TF_VAR_dbpassword: \"password\"\n  TEST_DISABLED: \"true\"\n  CODE_QUALITY_DISABLED: \"true\"\n  LICENSE_MANAGEMENT_DISABLED: \"true\"\n  BROWSER_PERFORMANCE_DISABLED: \"true\"\n  LOAD_PERFORMANCE_DISABLED: \"true\"\n  SAST_DISABLED: \"true\"\n  SECRET_DETECTION_DISABLED: \"true\"\n  DEPENDENCY_SCANNING_DISABLED: \"true\"\n  CONTAINER_SCANNING_DISABLED: \"true\"\n  DAST_DISABLED: \"true\"\n  REVIEW_DISABLED: \"true\"\n  CODE_INTELLIGENCE_DISABLED: \"true\"\n  CLUSTER_IMAGE_SCANNING_DISABLED: \"true\"\n  POSTGRES_ENABLED: \"false\"\n  STAGING_ENABLED: \"true\"\n  INCREMENTAL_ROLLOUT_MODE: \"manual\"\n```\n\nClick on the **Commit changes** button ensuring that the **Target branch** is main.\n\n![prodmgr-proj-pipeline](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/prodmgr-proj-pipeline.png){: .shadow.medium.center}\nCreating an Auto-DevOps-based pipeline for project \"prodmgr\"\n{: .note.text-center}\n\n- The previous step builds the application and deploys it to the staging environment. Once deployed to staging, head to **Build > Pipelines** and click on the most recently executed pipeline (should be the first one in the list). Click on the pipeline to display it and then deploy the application to production by clicking on “rollout 100%” job.\n\n![rollout-to-prod](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/rollout-to-prod.png){: .shadow.medium.center}\nTo deploy the application to production, click on the **rollout 100%** Play button\n{: .note.text-center}\n\nAt this point, you have a running application in the staging and production environments in your Kubernetes cluster. Let’s start creating a feature flag.\n\n## Creating a new feature flag\n-  In project “prodmgr”, select **Deploy > Feature flags** from your left vertical navigation menu.\n\n### Creating a user list\n- Click on the link **View user lists** on the top right hand side of your screen.\n- Click on the **New user list** button on the top right hand side of your screen.\n- In the **Name** field of the user list, enter “prods-in-alphabetical-order-userlist” and then click on the **Create** button.\n\n![create-ff-userlist](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/create-ff-userlist.png){: .shadow.medium.center.}\nCreating user list named \"prods-in-alphabetical-order-userlist”\n{: .note.text-center}\n\n- On the next screen, click on the **Add Users** button on the top right hand side of your screen.\n- In the **User IDs** text field, enter the following two email addresses and then click on the **Add** button:\n\n> michael@cfl.rr.com,mary@cfl.rr.com\n\n![add-users-to-list](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/add-users-to-list.png){: .shadow.medium.center}\nAdding users to user list \"prods-in-alphabetical-order-userlist”\n{: .note.text-center}\n\n- Head back to the Feature flags window by selecting **Deploy > Feature flags** from your left vertical navigation menu.\n\n### Creating the flag\n- Click on the **New feature flag** button on the top right hand side of your screen.\n- In the **New feature flag** window, enter “prods-in-alphabetical-order-ff”.\n\n### Specifying the strategy for the production environment\nIn the **Strategies** section of the **New feature flag** window, there should already be sub-sections for **Type** and **Environments**.\n- For **Type**, select **Percent rollout** from the dropdown menu.\n- For **Percentage**, enter **50** in the field.\n- For **Based on**, ensure that **Available ID** is selected from the popdown menu.\n- For **Environments**, click on the **+** sign and select the **production** environment.\n\n### Specifying the strategy for the staging environment\n- Click on the **Add strategy** button on the right hand side of the **Strategies** section. A new sub-section for another strategy will appear.\n- For **Type**, select **User List** from the dropdown menu.\n- For **User List**, select the user list **prods-in-alphabetical-order-userlist**.\n- For **Environments**, click on the **+** sign and select the **staging** environment.\n- Click on **Create feature flag** button at the bottom of your screen to complete the creation of the feature flag.\n\n![ff-and-strats-def](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/ff-and-strats-def.png){: .shadow.medium.center}\nDefining the feature flag with its strategies for strating and production environments\n{: .note.text-center}\n\n## Sharing feature flag configuration information with developers\nIn order for developers to instrument their code for this feature flag, you need to share with them the following information:\n- On the **Feature flags** window, click on the **Configure** button on the top right hand side of your screen.\n- Copy and save the values of **API URL** (URL where the client application connects to get a list of feature flags) and **Instance ID** (unique token that authorizes the retrieval of the feature flags). These are the two values that you will need for feature flag instrumentation.\n\n![ff-api-url-and-instance-id](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/ff-api-url-and-instance-id.png){: .shadow.medium.center}\nCopy and save the values for the feature flag API URL and Instance ID\n{: .note.text-center}\n\n- Head over to **Settings > CI/CD** and scroll down to the **Variables** section and click on its **Expand** button. Add the following two variables to your project:\n\n| Variable Key | Variable Value | Variable Type | Environment Scope | Flag - Protect variable | Flag - Mask variable\n| ----------- | ----------- | ----------- |----------- | ----------- | ----------- |\n| K8S_SECRET_UNLEASH_URL | \\\u003Csaved **API URL** value\\> | Variable | All (default) | unchecked | unchecked\n| K8S_SECRET_UNLEASH_INSTANCE_ID | \\\u003Csaved **Instance ID** value\\> | Variable | All (default) | unchecked | unchecked\n\n![add-var-K8S_SECRET_UNLEASH_URL](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/add-var-K8S_SECRET_UNLEASH_URL.png){: .shadow.medium.center}\nAdding variable K8S_SECRET_UNLEASH_URL to project \"prodmgr\"\n{: .note.text-center}\n\n![add-var-K8S_SECRET_UNLEASH_INSTANCE_ID](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/add-var-K8S_SECRET_UNLEASH_INSTANCE_ID.png){: .shadow.medium.center}\nAdding variable K8S_SECRET_UNLEASH_INSTANCE_ID to project \"prodmgr\"\n{: .note.text-center}\n\nThese two variables contain values that will be passed to your application (via the K8S_SECRET_ keyword) so that it can make use of the feature flags defined and managed by GitLab.\n\nIn order for your application to be able to use feature flags, you need to instrument your application with our Feature Flags framework. Let's see how you do this in the sample Java application.\n\n## Instrumenting the code\nIn this example, we are using the Java client for Unleash but if you’re using a different programming language then you need to use the client library for your language. To get all the supported languages, refer to the [Unleash documentation](https://docs.getunleash.io/reference/sdks) or [Unleash open source project](https://github.com/Unleash/unleash#unleash-sdks).\n\n### Instrumenting Java class files\n- In project “prodmgr”, navigate to the directory `src/main/java/csaa/jspring/ProductManager`.\n- Click on the file name “AppController.java” to view its contents and then click on the Edit button to enter edit mode.\n- You will see a few code blocks that have been commented out and are preceded by the line:\n\n> // Uncomment block below to instrument Feature Flag\n\nUncomment all the code blocks under each of the lines indicated above.\n\n![java-file-with-uncommented-lines](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/java-file-with-uncommented-lines.png){: .shadow.medium.center}\nPartial view of AppController.java file with uncommented code blocks\n{: .note.text-center}\n\n- Commit the changes to the main branch.\n- The commit starts a pipeline that deploys the application to the staging environment. Head to **Build > Pipelines** and click on the most recently executed pipeline (should be the first one in the list). Click on the pipeline to display it and wait until the **staging** job finishes. Then deploy the application to production by clicking on “rollout 100%” job.\n\nNow that the application is running in the staging and production environments, let’s see the feature flag in action.\n\n## Feature flag in action\nNow let's check how the feature flag is working.\n### Checking the feature flag in the staging environment\n- In project “prodmgr”, click on **Operate > Environments** to see the list of all environments. Then click on the \"Open live environment\" button for the staging environment.\n- A new browser tab will appear and will display a login screen. If your browser complains about the connection being insecure, accept the risk and open the browser tab.\n- Remember that the feature flag strategy for staging is based on the user list containing michael and mary in it. Let’s try logging in as each of them.\n- Enter credentials michael@cfl.rr.com with password p33sw0rd. Verify that Michael gets a product list sorted in alphabetical order. Log out and close the browser tab to ensure that his session closes.\n\n![michael-gets-ff](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/michael-gets-ff.png){: .shadow.medium.center}\nMichael gets the feature flag that orders the list of product names in alphabetical order\n{: .note.text-center}\n\n- From the Environments window, click on the \"Open live environment\" button for the staging environment. Enter credentials \"mary@cfl.rr.com\" with password \"p33sw0rd\". Verify that mary gets a product list sorted in alphabetical order. Log out and close the browser tab to ensure that her session closes.\n- From the Environments window, click on the \"Open live environment\" button for the staging environment. This time, enter credentials for \"thomas@gmail.com\" with password \"p33sw0rd\". Verify that thomas does **not** get a product list sorted in alphabetical order. Log out and close the browser tab to ensure that his session closes.\n\n![thomas-does-not-get-the-ff](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/thomas-does-not-get-the-ff.png){: .shadow.medium.center}\nThomas does not get the feature flag because the product names are not ordered in alphabetical order\n{: .note.text-center}\n\nThe steps above demonstrate that the feature flag strategy for staging successfully worked.\n\n### Checking the feature flag in the production environment\n- Click on **Operate > Environments** to see the list of all environments. Then click on the \"Open live environment\" button for the production environment.\n- A new browser tab will appear and will display a login screen. If your browser complains about the connection being insecure, accept the risk and open the browser tab.\n- Remember that the strategy in production is that the feature will be served to 50% of the users. Try logging into the web application as each of the following users keeping track of who gets the list of products sorted in alphabetical order by name and who does not:\n\n**Note:** Remember to click on the \"Open live environment\" button for the **production** environment. Once you log out from each user, remember to **close** the browser tab to ensure that the session closes.\n\n| Username | Password\n| ----------- | ----------- |\n| peter@gmail.com | pa33w0rd\n| magic@cfl.rr.com | pa33w0rd\n| michael@cfl.rr.com | pa33w0rd\n| henry@gmail.com | pa33w0rd\n| mary@cfl.rr.com | pa33w0rd\n| thomas@gmail.com | pa33w0rd\n\nYour final count should consist of three users being served the feature and three not, matching the strategy that was set for the production environment.\n\nAs changes are made to feature flags, you can track them from the audit events window.\n\n## Auditing feature flag changes\n**Note:** A Premium GitLab subscription is needed for viewing Audit events.\n\n- In project “prodmgr”, select **Secure > Audit events** from the left vertical navigation menu.\n- This displays all the events that have occurred in GitLab for the last thirty days. You will see that events related to updates to feature flags are listed.\n\n![audit-events-list](https://about.gitlab.com/images/blogimages/feature-flags-tutorial/audit-events-list.png){: .shadow.medium.center}\nAudit events is an auditable list of actions that have been taken againt resources\n{: .note.text-center}\n\nThis auditing allows you to identify when and who made changes to feature flags. It can also help preempt out-of-compliance scenarios and streamline audits to avoid penalties, providing an opportunity to optimize cost, and lower risk of unscheduled production outages.\n\nNow you know how to create and use feature flags to lower your deployment risk.\n\nPhoto by \u003Ca href=\"https://unsplash.com/@liamdesic?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Liam Desic\u003C/a> on \u003Ca href=\"https://unsplash.com/photos/acKSt3THWKA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>\n",[108,9,703],{"slug":2177,"featured":6,"template":683},"eliminate-risk-with-feature-flags-tutorial","content:en-us:blog:eliminate-risk-with-feature-flags-tutorial.yml","Eliminate Risk With Feature Flags Tutorial","en-us/blog/eliminate-risk-with-feature-flags-tutorial.yml","en-us/blog/eliminate-risk-with-feature-flags-tutorial",{"_path":2183,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2184,"content":2190,"config":2197,"_id":2199,"_type":13,"title":2200,"_source":15,"_file":2201,"_stem":2202,"_extension":18},"/en-us/blog/empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners",{"title":2185,"description":2186,"ogTitle":2185,"ogDescription":2186,"noIndex":6,"ogImage":2187,"ogUrl":2188,"ogSiteName":670,"ogType":671,"canonicalUrls":2188,"schema":2189},"GPU-enabled runners for ModelOps and HPC workloads in CI/CD","Learn how to leverage our GitLab-hosted GPU-enabled runners for ModelOps and high-performance computing workloads.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682702/Blog/Hero%20Images/gitlab-data-science-icon.png","https://about.gitlab.com/blog/empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Empower ModelOps and HPC workloads with GPU-enabled runners integrated with CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gabriel Engel\"}],\n        \"datePublished\": \"2023-07-06\",\n      }",{"title":2191,"description":2186,"authors":2192,"heroImage":2187,"date":2194,"body":2195,"category":806,"tags":2196},"Empower ModelOps and HPC workloads with GPU-enabled runners integrated with CI/CD",[2193],"Gabriel Engel","2023-07-06","\n\n\u003Ci>This blog post is the latest in an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). Start with the first blog post: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nIn today's fast-paced world, organizations are constantly looking to improve their [ModelOps](/direction/modelops/) and high-performance computing (HPC) capabilities. Leveraging powerful graphical processing units ([GPUs](https://www.techtarget.com/searchvirtualdesktop/definition/GPU-graphics-processing-unit)) has become a game-changer for accelerating machine learning workflows and compute-intensive tasks. To help meet these evolving needs, we recently released our first GPU-enabled runners on GitLab.com.\n\nSecurely hosting a GitLab Runner environment for ModelOps and HPC is non-trivial and requires a lot of knowledge and time to set up and maintain. In this blog post, we'll look at some real-world examples of how you can harness the potential of GPU computing for ModelOps or HPC workloads while taking full advantage of a SaaS solution.\n\n## What are GPU-enabled runners?\nGPU-enabled runners are dedicated computing resources for the AI-powered DevSecOps platform. They provide accelerated processing power for ModelOps and HPC such as the training or deployment of large language models ([LLMs](https://www.techtarget.com/whatis/definition/large-language-model-LLM)) as part of ModelOps workloads. In the first iteration of releasing GPU-enabled runners, [GitLab.com SaaS offers](https://docs.gitlab.com/ee/ci/runners/saas/gpu_saas_runner.html) the GCP `n1-standard-4` machine type (4 vCPU, 15 GB memory) with 1 NVIDIA T4 (16 GB memory) attached. The runner behaves like a GitLab Runner on Linux, using the docker+machine [executor](https://docs.gitlab.com/runner/executors/). \n\n## Using GPU-enabled runners\nTo take advantage of GitLab GPU-enabled runners, follow these steps:\n\n### 1. Have a project on GitLab.com\nAll projects on GitLab.com SaaS with a `Premium` or `Ultimate` [subscription](https://about.gitlab.com/pricing/) have the GPU-enabled runners enabled by default - no additional configuration is required.\n\n### 2. Create a job running on GPU-enabled runners\nCreate a job in your `.gitlab-ci.yml` configuration file, and set the [runner `tag`](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#use-tags-to-control-which-jobs-a-runner-can-run) to the `saas-linux-medium-amd64-gpu-standard` value. \n\n```yaml\ngpu-job:\n  stage: build\n  tags:\n    - saas-linux-medium-amd64-gpu-standard\n```\n\n### 3. Select a Docker image with the Nvidia CUDA driver\n\nThe CI/CD job runs in an isolated virtual machine (VM) with a bring-your-own-image policy as with [GitLab SaaS runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html). GitLab mounts the GPU from the host VM into your isolated environment. You must use a Docker image with the GPU driver installed to use the GPU. For Nvidia GPUs, you can use the [CUDA Toolkit](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda) directly, or third-party images with Nvidia drivers installed, such as the [TensorFlow GPU image](https://hub.docker.com/r/tensorflow/tensorflow/).\n\nThe CI/CD job configuration for the Nvidia CUDA base Ubuntu image looks like this:\n\n```yaml\n  image: nvcr.io/nvidia/cuda:12.1.1-base-ubuntu22.04\n```\n\n### 4. Verify that the GPU is working\nTo verify that the GPU drivers are working correctly, you can execute the `nvidia-smi` command in the CI/CD job `script` section. \n\n```yaml\n  script:\n    - nvidia-smi\n```\n\n## Basic usage examples\nLet's explore some basic scenarios where GPU-enabled runners can supercharge your ModelOps and HPC workloads:\n\n### Example 1: ModelOps with Python\nIn this example, we train a model on our GPU-enabled runner defined in the `train.py` file using the Nvidia CUDA base Ubuntu image mentioned earlier.\n\n`.gitlab-ci.yml` file:\n```yaml\nmodel-training:\n  stage: build\n  tags:\n    - saas-linux-medium-amd64-gpu-standard\n  image: nvcr.io/nvidia/cuda:12.1.1-base-ubuntu22.04\n  script:\n    - apt update\n    - apt install -y --no-install-recommends python3 python3-pip \n    - pip3 install -r requirements.txt\n    - python3 --version\n    - python3 train.py\n```\n\n### Example 2: Scientific simulations and HPC\nComplex scientific simulations require significant computing resources. GPU-enabled runners can accelerate these simulations, allowing you to get results in less time.\n\n`.gitlab-ci.yml` file:\n```yaml\nsimulation-run:\n  stage: build\n  tags:\n    - saas-linux-medium-amd64-gpu-standard\n  image: nvcr.io/nvidia/cuda:12.1.1-base-ubuntu22.04\n  script:\n    - ./run_simulation --input input_file.txt\n```\n\n## Advanced usage examples\nLet's go through some real-world scenarios of how we use GPU-enabled runners at GitLab.\n\n### Example 3: Python model training with a custom Docker image\nFor our third example, we will use this [handwritten digit recognition model](https://gitlab.com/gitlab-org/modelops/demos/handwritten-digit-recognition). We are using this project as a demo to showcase or try out new ModelOps features.\n\n[Open the project](https://gitlab.com/gitlab-org/modelops/demos/handwritten-digit-recognition) and fork it into your preferred namespace. You can follow the next steps using the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) in the browser, or clone the project locally to create and edit the files. Some of the next steps require you to override existing configuration in the `Dockerfile` and `.gitlab-ci.yml`. \n\nAs we need more pre-installed components and want to save installation time when training the model, we decided to create a custom Docker image with all dependencies pre-installed. This also gives us full control over the build environment we use and allows us to reuse it locally without relying on the `.gitlab-ci.yml' implementation.\n\nIn addition, we are using a more complete pipeline configuration with the following stages:\n\n```yaml\nstages:\n  - build\n  - test\n  - train\n  - publish\n```\n\n![GPU pipeline overview](https://about.gitlab.com/images/blogimages/2023-07-06-gpu-enabled-runners-for-modelops/pipeline-overview.png)\n\n#### Building a custom Docker image\nThe first step is to define a `Dockerfile`. In this example, we start with the Nvidia CUDA base Ubuntu image and then install `Python3.10`. Using `pip install`, we then add all the required libraries specified in a `requirements.txt` file.\n\n```docker\nFROM nvcr.io/nvidia/cuda:12.1.1-base-ubuntu22.04\n\n1. Update and install required packages\nRUN apt-get update && apt-get install -y \\\n    python3.10 \\\n    python3.10-dev \\\n    python3-pip \\\n    && rm -rf /var/lib/apt/lists/*\n\n2. Set Python 3.10 as the default Python version\nRUN ln -s /usr/bin/python3.10 /usr/bin/python\n\n3. Copy the requirements.txt file\nCOPY requirements.txt /tmp/requirements.txt\n\n4. Install Python dependencies\nRUN pip3 install --no-cache-dir -r /tmp/requirements.txt\n```\n\nIn the `.gitlab-ci.yml` file we use [Kaniko](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html) to build the Docker image and push it into the [GitLab Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/).\n\n```yaml\nvariables:\n  IMAGE_PATH: \"${CI_REGISTRY_IMAGE}:latest\"\n  GIT_STRATEGY: fetch\n\ndocker-build:\n  stage: build\n  tags:\n    - saas-linux-medium-amd64\n  image:\n    name: gcr.io/kaniko-project/executor:v1.9.0-debug\n    entrypoint: [\"\"]\n  script:\n    - /kaniko/executor\n      --context \"${CI_PROJECT_DIR}\"\n      --dockerfile \"${CI_PROJECT_DIR}/Dockerfile\"\n      --destination \"${IMAGE_PATH}\"\n      --destination \"${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}\"\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\nIn [rules](https://docs.gitlab.com/ee/ci/yaml/#rules) we define to only trigger the Docker image build for a new git tag. The reason is simple - we don't want to run the image build process for every time we train the model.\n\nTo start the image build job [create a new Git tag](https://docs.gitlab.com/ee/user/project/repository/tags/#create-a-tag). You can either do this by using `git tag -a v0.0.1` command or via UI. Navigate into `Code > Tags` and click on `New Tag`. As Tag name type `v0.0.1` to create a new Git tag and trigger the job.\n\nNavigate to `Build > Pipelines` to verify the `docker-build` job status, and then locate the tagged image following [`Deploy > Container Registry`](https://docs.gitlab.com/ee/user/packages/container_registry/).\n\n![Docker image](https://about.gitlab.com/images/blogimages/2023-07-06-gpu-enabled-runners-for-modelops/gpu-docker-image.png)\n\n#### Testing the Docker image\nTo test the image, we will use the following `test-image` job and run `nvidia-smi` and check that the GPU drivers are working correctly.\n\nThe job configuration in `.gitlab-ci.yml` file looks as follows:\n\n```yaml\ntest-image:\n  stage: test\n  tags:\n    - saas-linux-medium-amd64-gpu-standard\n  image: $IMAGE_PATH\n  script:\n    - nvidia-smi\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\nWe also include container scanning and more [security scanning](https://docs.gitlab.com/ee/user/application_security/) templates in the `.gitlab-ci.yml` file.\n\n```yaml\ninclude:\n  - template: Security/Secret-Detection.gitlab-ci.yml\n  - template: Security/Container-Scanning.gitlab-ci.yml\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n  - template: Security/SAST.gitlab-ci.yml\n```\n\n#### Training the model with our custom Docker image\nNow that we have built our Custom docker image, we can train the model without installing any more dependencies in the job.\n\nThe train job in our `.gitlab-ci.yml` looks like this:\n\n```yaml\ntrain:\n  stage: train\n  tags:\n    - saas-linux-medium-amd64-gpu-standard\n  image: $IMAGE_PATH\n  script:\n    - python train_digit_recognizer.py\n  artifacts:\n    paths:\n      - mnist.h5\n    expose_as: 'trained model'\n```\n\nNavigate to `Build > Pipelines` to see the job logs.\n\n![Train job logs](https://about.gitlab.com/images/blogimages/2023-07-06-gpu-enabled-runners-for-modelops/train-job-log.png)\n\nFrom here, you can also inspect the `train` job artifacts.\n\n#### Publishing the model\nIn the last step of our `.gitlab-ci.yml` file, we are going to publish the trained model.\n\n```yaml\npublish:\n  stage: publish\n  when: manual\n  dependencies:\n    - train\n  image: curlimages/curl:latest\n  script:\n    - 'curl --header \"JOB-TOKEN: $CI_JOB_TOKEN\" --upload-file mnist.h5 \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/MNIST-Model/${CI_COMMIT_TAG}/mnist.h5\"'\n```\n\nNavigate to `Build > Pipelines` and trigger the `publish` job manually. After that, navigate into `Deploy > Package Registry` to verify the uploaded trained model.\n\n![Package Registry](https://about.gitlab.com/images/blogimages/2023-07-06-gpu-enabled-runners-for-modelops/package-registry.png)\n\n### Example 4: Jupyter notebook model training for ML-powered GitLab Issue triage\n\nIn the last example, we are using our GPU-enabled runner to train the internal [GitLab model to triage issues](https://gitlab.com/gitlab-org/ml-ops/tanuki-stan/-/tree/using-gpu-enabled-runner). We use this model at GitLab to determine and assign issues to the right team from the context of the issue description.\n\nDifferent from the previous examples, we now use the [`tensorflow-gpu` container image](https://hub.docker.com/r/tensorflow/tensorflow) and install the [requirements](https://gitlab.com/gitlab-org/ml-ops/tanuki-stan/-/blob/using-gpu-enabled-runner/notebooks/requirements.tensorflow-gpu.txt) in the job itself.\n\n`.gitlab-ci.yml` configuration:\n\n```yaml\ntrain:\n  tags:\n    - saas-linux-medium-amd64-gpu-standard\n  image: tensorflow/tensorflow:2.4.1-gpu\n  script:\n    - nvidia-smi\n    - cd notebooks\n    - pip install -r requirements.tensorflow-gpu.txt\n    - jupyter nbconvert --to script classify_groups.ipynb\n    - apt-get install -y p7zip-full\n    - cd ../data\n    - 7z x -p${DATA_PASSWORD} gitlab-issues.7z\n    - cd ../notebooks\n    - python3 classify_groups.py\n  artifacts:\n    paths:\n      - models/\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\" || $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n      when: manual\n      allow_failure: true\n```\n\n![TensorFlow train](https://about.gitlab.com/images/blogimages/2023-07-06-gpu-enabled-runners-for-modelops/tensorflow-train.png)\n\nIf you are interested in another Jupyter notebook example, check out our recently published video on [Training ML Models using GPU-enabled runner](https://youtu.be/tElegG4NCZ0).\n\n\u003Ciframe width=\"768\" height=\"432\" src=\"https://www.youtube.com/embed/tElegG4NCZ0\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen>\u003C/iframe>\n\n## Results\nThe integration of GPU-enabled runners on GitLab.com SaaS opens up a new realm of possibilities for ModelOps and HPC workloads.\nBy harnessing the power of GPU-enabled runners, you can accelerate your machine learning workflows, enable faster data processing, and improve scientific simulations, all while taking full advantage of a SaaS solution and avoiding the hurdles of hosting and maintaining your own build hardware.\n\nWhen you try the GPU-enabled runners, please share your experience in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/403008).\n\nCompute-heavy workloads can take a long time. A known problem is timeouts after three hours because of the current [configuration of GitLab SaaS runners](https://docs.gitlab.com/ee/ci/runners/#how-saas-runners-work).\nWe plan to release more powerful compute for future iterations to handle heavier workloads faster. You can follow updates about GPU-enabled runners in the [GPU-enabled runners epic](https://gitlab.com/groups/gitlab-org/-/epics/8648) and learn more in the [GPU-enabled runners documentation](https://docs.gitlab.com/ee/ci/runners/saas/gpu_saas_runner.html).\n",[703,786,108,701,9],{"slug":2198,"featured":6,"template":683},"empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners","content:en-us:blog:empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners.yml","Empowering Modelops And Hpc Workloads With Gpu Enabled Runners","en-us/blog/empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners.yml","en-us/blog/empowering-modelops-and-hpc-workloads-with-gpu-enabled-runners",{"_path":2204,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2205,"content":2210,"config":2217,"_id":2219,"_type":13,"title":2220,"_source":15,"_file":2221,"_stem":2222,"_extension":18},"/en-us/blog/enabling-global-search-elasticsearch-gitlab-com",{"title":2206,"description":2207,"ogTitle":2206,"ogDescription":2207,"noIndex":6,"ogImage":2148,"ogUrl":2208,"ogSiteName":670,"ogType":671,"canonicalUrls":2208,"schema":2209},"Lessons from implementing global code search on GitLab.com","Read about some of the dead ends we've encountered on the way to enabling global code search on GitLab.com, and how we're working on a way forward.","https://about.gitlab.com/blog/enabling-global-search-elasticsearch-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lessons from our journey to enable global code search with Elasticsearch on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mario de la Ossa\"}],\n        \"datePublished\": \"2019-03-20\",\n      }",{"title":2211,"description":2207,"authors":2212,"heroImage":2148,"date":2214,"body":2215,"category":849,"tags":2216},"Lessons from our journey to enable global code search with Elasticsearch on GitLab.com",[2213],"Mario de la Ossa","2019-03-20","\nWe're [working hard to switch our search infrastructure on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/153) to\ntake advantage of our [Elasticsearch integration](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html), which should allow us to improve global search and enable global code search for our users.\n\nEnabling this integration on GitLab.com is important to us because it will unlock better search performance and allow us\nto improve the relevance of results for our GitLab.com users – something our self-managed users have been able to take advantage of for a few years now.\nWe've been working on this for a while, and have hit many dead ends and pitfalls which maybe you can learn from too.\n\n## Our plan\n\nWe have two very important things that need to happen: we must reduce the Elasticsearch index size,\nand we must improve the administration of the Elasticsearch integration.\n\n## 1. Reduce index size\n\nCurrently, the Elasticsearch index utilizes approximately 66 percent of the space the repos use.\nThis is our biggest blocker, as this is the bare minimum amount of space required – this number goes up when you consider the need for replicas.\n\nWe've attempted multiple things to get the index size down, but all of them resulted in minimal (or no) changes at all,\nso due to the complexity of implementing the changes we've decided to ignore them (at least for now).\n\n### Things we've tried\n\n#### Force merges\n\nWhen you delete a document from Elasticsearch, it doesn't actually free up space right away.\nInstead it does a soft delete, and Elasticsearch will release the space used in the future via an operation called a [merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html).\n\nIn [gitlab-org/gitlab-ee#7611](https://gitlab.com/gitlab-org/gitlab-ee/issues/7611) we investigated the possibility of forcing Elasticsearch\nto reclaim this space periodically via an operation called a [forcemerge](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html).\nThis seemed like a very worthwhile thing to investigate as an Elasticsearch index could theoretically grow up to 50 percent more due to these soft deletions.\nIn the end though, we found out that a `forcemerge` is a blocking call, and causes extreme performance degradation while it runs –\nnot something you want in a production environment!\nSadly we were forced to abandon this, but we did learn a bit more about [how to tune Elasticsearch so merges are less painful, which we documented here](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html).\n\n#### NGram sizes\n\nIn order to allow users to search without using exact phrases (it would be annoying if a search for \"house\" didn't bring up \"houses\" for\nexample) we use what is called an [Edge NGram](https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-edgengram-tokenizer.html)\nfilter for blobs (code files) and SHA1 strings (commit IDs).\n\nWe have our Edge NGram filters set to create a maximum length of 40.\nRight off the bat we knew we could not lower the maximum size for our SHA1 filter, since we want our users to be able to find commits no matter how many characters of the ID they give us, and the maximum is 40.\n\nWe could, however, play with the Edge NGram filter we use to analyze code, so we tested a few different scenarios in [gitlab-org/gitlab-ee#5585](https://gitlab.com/gitlab-org/gitlab-ee/issues/5585).\nWe came up with conflicting results, but the savings were between 7-15 percent.\nNot bad! We still haven't changed the maximum length though, as we still need to confirm that searching is not impacted unduly with such a change.\n\n#### Separate indexes\n\nCurrently, our Elasticsearch integration lumps all document types into the same index.\nThis is because, in order to only return results to which a user has access, we must check the Project the object belongs to for the user's access level, which would be very expensive to do if we had to do it result per result after Elasticsearch returns the results of the query.\n\nThat said, there was a chance that having separate indexes could improve our space usage, and it would definitely improve the re-indexing\nexperience, so in [gitlab-org/gitlab-ee#3217](https://gitlab.com/gitlab-org/gitlab-ee/issues/3217) we took a stab at it.\nWe learned that having separate indexes does nothing for space usage, which we already suspected since Elasticsearch 6.0 shipped with great support for [sparse fields](https://www.elastic.co/blog/minimize-index-storage-size-elasticsearch-6-0).\n\nWe're still looking into having separate indexes, as in testing we have discovered it [greatly improves indexing speed](https://gitlab.com/gitlab-org/gitlab-ee/issues/3217#note_130304358)\nand should also improve the experience of having to re-index certain models.\n\n## 2. Improve administration capabilities for Elasticsearch\n\nRight now, all administration related to Elasticsearch must be done on the Elasticsearch cluster directly.\nWe also currently require the Elasticsearch integration to be an all-or-nothing deal: you must enable it for all projects, or none of them.\nTo make matters worse, when we make a change to the index schema, we require a full re-index of the entire repo right away in order for the update to work.\nWe need to fix all these things and make Elasticsearch easier to administer from within GitLab if we want to have a fighting chance at\nenabling Elasticsearch support on GitLab.com.\n\nSome concrete things we're working on:\n\n### Better cluster visibility\n\nIn order to help the administration of Elasticsearch, we must enable better controls for it from within GitLab.\nIssues [gitlab-org/gitlab-ee#3072](https://gitlab.com/gitlab-org/gitlab-ee/issues/3072) and\n[gitlab-org/gitlab-ee#2973](https://gitlab.com/gitlab-org/gitlab-ee/issues/2973) aim to provide a simple, but functional, admin interface\nfor Elasticsearch within GitLab.\n\n### Graceful recovery\n\nCurrently, if some data fails to index, whether due to a Sidekiq outage or any other reason, the only solution is to\nre-index the full Elasticsearch cluster, which is painful! In [gitlab-org/gitlab-ee#5299](https://gitlab.com/gitlab-org/gitlab-ee/issues/5299)\nwe will be looking into ways to improve this.\n\n### Selective/progressive indexing\n\nIn [gitlab-org/gitlab-ee#3492](https://gitlab.com/gitlab-org/gitlab-ee/issues/3492) we will be taking a look at enabling\nElasticsearch on a project-by-project basis.\n\n### Allow disabling of code indexing\n\nIn [gitlab-org/gitlab-ee#7870](https://gitlab.com/gitlab-org/gitlab-ee/issues/7870) we're investigating making\ncode indexing optional. What this would mean is that global code search would not be available, but searching within a\nproject would work as it currently does, backed by direct Gitaly searches. This is attractive to us as it would bring\nsearch improvements to Projects, Groups, Issues, and Merge Requests. This will also be a very useful feature for self-managed\ninstances that want to have better search support for Issues/MRs/etc. but don't really need global code search. Indexing\nthe repos to enable global code search takes an incredible amount of time, so offering the choice of disabling it gives our\nself-managed users more choice.\n\n### Shard Elasticsearch per group\n\nIn [gitlab-org/gitlab-ee#10519](https://gitlab.com/gitlab-org/gitlab-ee/issues/10519) we're considering having separate Elasticsearch\nservers per group, similar to how Gitaly works, but on a group level instead of project level. Elasticsearch servers can become very large,\nreducing performance and making them less maintainable. By having a separate server per group we would also gain resiliency in case one\ncluster goes down, as only the group related to that cluster would be affected.\n\nWe're still investigating this approach as there are some concerns about how search would work if we had separate Elasticsearch servers per group.\n\n## The future\n\nWe haven't given up yet! We have high hopes that we'll find ways to lower usage enough to make better search available to all our users.\n\nMeanwhile, we're switching all our engineering time from lowering index usage to improving administration capabilities, as we feel that\nenabling things like selective indexing of projects will allow us to improve our Elasticsearch integration with more confidence, as we will\nbe dogfooding our changes in production.\n\nIf you'd like to follow along with us, feel free to check out the following epics: [gitlab-org&153](https://gitlab.com/groups/gitlab-org/-/epics/153),\n[gitlab-org&429](https://gitlab.com/groups/gitlab-org/-/epics/429), and [gitlab-org&428](https://gitlab.com/groups/gitlab-org/-/epics/428).\nIf you have any concerns, comments, etc. we'll be glad to hear them. Remember, everyone can contribute!\n\nPhoto by [Benjamin Elliott](https://unsplash.com/photos/vc9u77c0LO4) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[9,230,680],{"slug":2218,"featured":6,"template":683},"enabling-global-search-elasticsearch-gitlab-com","content:en-us:blog:enabling-global-search-elasticsearch-gitlab-com.yml","Enabling Global Search Elasticsearch Gitlab Com","en-us/blog/enabling-global-search-elasticsearch-gitlab-com.yml","en-us/blog/enabling-global-search-elasticsearch-gitlab-com",{"_path":2224,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2225,"content":2231,"config":2239,"_id":2241,"_type":13,"title":2242,"_source":15,"_file":2243,"_stem":2244,"_extension":18},"/en-us/blog/ensuring-compliance",{"title":2226,"description":2227,"ogTitle":2226,"ogDescription":2227,"noIndex":6,"ogImage":2228,"ogUrl":2229,"ogSiteName":670,"ogType":671,"canonicalUrls":2229,"schema":2230},"How to ensure separation of duties and enforce compliance with GitLab","Use your DevSecOps platform to help maintain compliance without compromising on development speed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","https://about.gitlab.com/blog/ensuring-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to ensure separation of duties and enforce compliance with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }",{"title":2226,"description":2227,"authors":2232,"heroImage":2228,"date":2235,"body":2236,"category":704,"tags":2237,"updatedDate":2238},[2233,2234],"Beatriz Barbosa","Fernando Diaz","2022-04-04","In this article, you'll learn the different ways to ensure **separation of duties** and\n**continuous compliance** with the GitLab DevSecOps platform. But first, let's level-set on two key concepts:\n\n**Compliance** means being in accordance with guidelines and specifications that have been\ndefined either by your corporation or a regulatory agency. Compliance helps maintain\ncorporate ethics, appropriate user policies, security standards, and much more for\nthe safety of consumers.\n\nNon-compliance may result in a bundle of legal fees and fines, so it is very important to maintain compliance. While maintaining compliance, DevSecOps teams must also ensure sustained development velocity, providing necessary simplicity, visibility, and control.\n\n**Separation of duties** requires multiple actors to complete a task to increase protection from error as well as prevent malicious activity. Separation of duties ensures roles best-suited for the job are the only ones that can perform it. As an example, some of the following\nactors are observed, each with a specific purpose:\n\n- a developer will be responsible for developing new features\n- a compliance officer will be responsible for creating and enforcing the usage of a pipeline\n- an application security engineer will be responsible for approving merge requests with vulnerabilities\n\nConsidering the above roles, we can ensure that a developer cannot change a running pipeline.\nThis is a task that can only be performed by a compliance officer, ensuring only compliant code can be pushed without approval.\n\nAn application security engineer is responsible for reviewing and approving code with vulnerabilities, ensuring proper mitigation can be performed, and that nothing comes as a surprise in the future. In this scenario, developers can't merge code until compliance\nand security requirements are met.\n\n## Security policies\nGitLab provides **Security Policies**, which enable security teams to require security scans to run according to a configuration. This gives security teams confidence that the configured scans have not been changed or disabled.\n\nSecurity policies can be scoped to meet certain **Compliance Frameworks**. This means that your project has certain compliance requirements and needs additional oversight. This label can be created in **Secure > Compliance Center > Frameworks** under your top-level group.\n\n![Compliance Framework Label](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n**Note:** Compliance labels can only be assigned to projects within the top-level group in which we create the label.\n\nThere are three types of policies, [Scan Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), [Merge Request Approval Policies](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html), and [Pipeline Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n* **Scan Execution Policies:** Require that security scans run on a specified schedule or with the project pipeline.\n* **Merge Request Approval Policies:** Take action based on scan results, such as requiring approval from the security team before a merge can occur.\n* **Pipeline Execution Policies:** Enforce CI/CD jobs for applicable projects.\n\nThese policies can be configured via the Policy Editor in a few simple steps.\n\n### Scan execution\n\n1. Go to **Security & Compliance > Policies**.\n\n2. Create a new policy by pressing the **New Policy** button.\n\n3. Select **Scan Execution**.\n\n4. Create the rule. I'm creating a rule that requires [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) to be configured in order for a pipeline to run.\n\n```yaml\nname: force_sast\ndescription: 'require sast to run'\nenabled: true\nrules:\n- type: pipeline\n  branches:\n  - main\nactions:\n- scan: sast\n```\n\n5. Submit the policy by creating a merge request and then merge.\n\nAll scan execution policy changes are applied through a background job that runs once every 10 minutes.\nAllow up to 10 minutes for any policy changes committed to this project to take effect.\n\n6. Try and run a pipeline. It will not be run unless SAST is defined in the YAML.\n\n**Note**: You can also force SAST to run on a timer. For more information, see the scan execution\npolicies [documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html).\n\n### Merge Request Approval\n\n1. Go to **Secure > Policies**.\n\n2. Create a new policy by pressing the **New Policy** button.\n\n3. Select **Merge Request Approval Policy**.\n\n4. Define policy scope.\n\n5. Create the rule.\n\n![separation of duties update - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n6. Add action to take.\n\n![separation of duties update - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n**Note:** The policy is evaluated according to the rules you set. This means that, if the rules are invalid, or can’t be evaluated, approval is required. To prevent this, the default Fallback behavior field can be changed to `open`.\n\n![separation of duties update - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n1. Submit the policy by creating a merge request and then merging\n\n2. Create a separate merge request with vulnerabilities\n\nYou can see how to add vulnerabilities by checking out the Developer Workflow section of the GitLab DevSecOps Workshop.\n\n3. Verify Merge Request Approval Policy is being used by viewing merge request.\n\n### Pipeline Execution Policy\n\nTo set up a pipeline execution policy, you need to first create a project containing the CI files you would like to run. Make sure that only the security team and/or administrator has access to ensure separation of duties. I created the \"Compliance and Deploy\" project, which contains the YAML I wish to enforce.\n\n1. Go to **Secure > Policies**.\n\n2. Create a new policy by pressing the **New Policy** button.\n\n3. Select **Pipeline Execution Policy**.\n\n4. Define policy scope.\n\n5. Add action to take.\n\n![separation of duties update - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n6. Add conditions.\n\n7. Submit the policy by creating a merge request and then merging.\n\n8. Try and run a pipeline. You will see the policy specific jobs and stages in your pipeline.\n\n## Audit Management and Compliance Dashboard\n\nAnother important part of compliance is knowing it is actually happening in your groups/projects. GitLab has Audit Events and Compliance Reports to assist with audits.\n\n**Audit Events** allows GitLab owners and administrators to track important events such as who performed certain actions and the time they occurred.\n\n![Audit events](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\nAudit Events records different events per group and per project, which can be seen\nin the [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) documentation.\nAudit Events can be accessed by going to **Security & Compliance > Audit Events**.\nSome examples include:\n\n- user was added to project and their permissions\n- permission changes of a user assigned to a project\n- project CI/CD variable added, removed, or protected status changed\n- user was added to group and their permissions\n- group name or path changed\n\nAudit Events can also be sent to an HTTP endpoint using Audit Event Streaming. Learn how\nto implement Audit Event Streaming in this [video](https://youtu.be/zHwVF9-i7e4?t=52).\n\n**Standards Adherence** gives you the ability to see a group's merge request activity. It provides a high-level view for all projects in the group.\n\n![separation of duties update - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\nYou can use the report to:\n- get an overview of the latest merge request for each project\n- see if merge requests were approved and by whom\n- see merge request authors\n- see the latest CI/CD pipeline result for each merge request\n\nThe Standards Adherence report can be accessed in the top-level group by going to **Secure > Compliance Center**, and choosing the **Standards Adherence** tab.\n\n---\n\nThanks for reading! For more information on separation of duties within GitLab, check out [Continous Software Compliance with GitLab](/solutions/compliance/)\n",[704,1396,1397,9],"2024-12-16",{"slug":2240,"featured":6,"template":683},"ensuring-compliance","content:en-us:blog:ensuring-compliance.yml","Ensuring Compliance","en-us/blog/ensuring-compliance.yml","en-us/blog/ensuring-compliance",{"_path":2246,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2247,"content":2253,"config":2259,"_id":2261,"_type":13,"title":2262,"_source":15,"_file":2263,"_stem":2264,"_extension":18},"/en-us/blog/epics-roadmap",{"title":2248,"description":2249,"ogTitle":2248,"ogDescription":2249,"noIndex":6,"ogImage":2250,"ogUrl":2251,"ogSiteName":670,"ogType":671,"canonicalUrls":2251,"schema":2252},"Coming in 11.3: Seamless planning with epics & roadmap","See how you can plan and track larger initiatives even more easily with milestone dates integrated into epics.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672146/Blog/Hero%20Images/epics-issues-milestones-planning.jpg","https://about.gitlab.com/blog/epics-roadmap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Coming in 11.3: Seamless top-down and bottom-up planning with epics and roadmap\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n        \"datePublished\": \"2018-08-23\",\n      }",{"title":2254,"description":2249,"authors":2255,"heroImage":2250,"date":2256,"body":2257,"category":298,"tags":2258},"Coming in 11.3: Seamless top-down and bottom-up planning with epics and roadmap",[1550],"2018-08-23","\n\n[Epics](https://docs.gitlab.com/ee/user/group/epics/) and [roadmap](https://docs.gitlab.com/ee/user/group/roadmap/)\n are two newer features in [GitLab Ultimate](/pricing/) and [GitLab.com Gold](/pricing/#gitlab-com). Used together, your team\n can plan and track larger initiatives. On September 22, we're shipping a new feature\n which we will help you transition seamlessly between top-down and bottom-up planning.\n\n## First things first: epics vs. issues vs. roadmap\n\nAn epic is similar to an [issue](https://docs.gitlab.com/ee/user/project/issues/) in that it\nrecords a proposed scope of work to be done, allows for team members to discuss that scope,\nand then is tracked and updated over time as that work is actually implemented.\n\nHowever, an epic exists at the [group](https://docs.gitlab.com/ee/user/group/index.html) level (as opposed to an issue, which exists at the [project](https://docs.gitlab.com/ee/user/project/index.html) level). So\nimmediately you see that an epic is designed to reflect a larger scope, and higher level of discussion\ncompared to an issue. Additionally, you can [attach any number of issues to an epic](https://docs.gitlab.com/ee/api/epic_issues.html#assign-an-issue-to-the-epic), with the idea that\nthe epic's scope decomposes into those individual issues.\n\n![epic](https://about.gitlab.com/images/blogimages/epic-view.png){: .shadow.medium.center}\n\nSince an epic is designed to scope work over a longer period of time (several issues' worth),\na timeline-based view in the form of a [roadmap](https://docs.gitlab.com/ee/user/group/roadmap/)\n is also useful: it serves as a visualization to anticipate that work, and track it as it's\n progressively completed. So the roadmap, also scoped at the group level, presents all the\n epics in time for that group.\n\nYou can apply [group labels](https://docs.gitlab.com/ee/user/project/labels.html#project-labels-and-group-labels)\n to epics, making it easy to quickly narrow down to the epics you care about, whether you\n are looking at a list view or a roadmap view.\n\n| Epics list | Roadmap |\n| --- | --- |\n| ![roadmap](https://about.gitlab.com/images/blogimages/epic-list-view.png){: .shadow} | ![roadmap](https://about.gitlab.com/images/blogimages/roadmap-view.png){: .shadow} |\n\n## Long-term vs short-term planning\n\nWhen planning any initiative, uncertainty, by definition, increases further out in\nthe future. You don't know how many resources you will have. You don't know if previous\ndependent work will be finished. You don't know if the market and your customers will change\nsuch that you won't even need that planned out initiative at all.\n\nConversely, the nearer-term future is much more certain. You have a good handle of the work\nthat should be accomplished and that it can be completed within the next few weeks, up to a\nmonth or so.\n\nAnd of course, the work you are doing now, and have already completed in the past, has zero\nuncertainty. You can't change the past.\n\nEpics and roadmap help you plan and track work in all these cases:\n\n### Long-term future: top-down planning\n\nWhen planning far in the future, we use _top-down planning_. We have strategic initiatives\nthat we want to achieve, with approximate scope and timelines. So in this case, you would\ncreate an epic, and assign `Fixed` dates (a planned start date and planned finish date) to it.\nThe epic would appear in the roadmap view, and you would be able to see it positioned further\nin the future.\n\nThis helps high-level planning, such as starting discussions with various departments in\nyour organizations, or presenting a strategic roadmap to your executive leadership. By creating the\nepic early on, it provides a collaborative space for all stakeholders to discuss feasibility\nand further detailed ideas.\n\n### Short-term future: bottom-up planning\n\nWhen planning for the nearer-term future, we use _bottom-up_ planning. So suppose the epic\nyou created previously with fixed dates has gained some traction within your organization.\nPeople are excited about the prospects and want to flesh out detailed designs and implementation\nsteps. You and your team would then start creating issues and attach them to the epic.\n\nEventually, you have scoped out the detailed work in the issues and even assigned milestones to them,\nindicating when they are planned to be worked on. Now, instead of having to manually update the epic\nto reflect the milestone dates, you would simply choose `From milestones` in the epic sidebar. In this\ncase, the epic planned start date becomes a dynamic date reflecting the earliest start date across all\nthe epic's assigned milestones. The same goes for the epic's planned end date too.\n\nThis functionality is coming in GitLab 11.3 – you can [view the original issue here](https://gitlab.com/gitlab-org/gitlab-ee/issues/6470).\n\nAdditionally, the [roadmap bar edges will reflect the fixed or dynamic start and end dates](https://gitlab.com/gitlab-org/gitlab-ee/issues/6471) accordingly.\n\n![inherited-dates](https://about.gitlab.com/images/blogimages/inherited-dates.png){: .shadow.medium.center}\n\nSo with this design, you are in control when you want to seamlessly transition an epic from a\ntop-down planning scenario, to a bottom-up one. The roadmap reflects these dates automatically too,\nso that all your epics are shown together in one view.\n\nPhoto by [Christopher Machicoane-Hurtaud](https://unsplash.com/photos/ewZkOqjl2Ys?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/ewZkOqjl2Ys?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1164,9,680,894],{"slug":2260,"featured":6,"template":683},"epics-roadmap","content:en-us:blog:epics-roadmap.yml","Epics Roadmap","en-us/blog/epics-roadmap.yml","en-us/blog/epics-roadmap",{"_path":2266,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2267,"content":2273,"config":2278,"_id":2280,"_type":13,"title":2281,"_source":15,"_file":2282,"_stem":2283,"_extension":18},"/en-us/blog/everyone-who-has-contributed",{"title":2268,"description":2269,"ogTitle":2268,"ogDescription":2269,"noIndex":6,"ogImage":2270,"ogUrl":2271,"ogSiteName":670,"ogType":671,"canonicalUrls":2271,"schema":2272},"Visualizing 11 years of GitLab contributions","Check out this animated video, which beautifully visualizes every contribution since our start.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682555/Blog/Hero%20Images/gitlabeveryonecontributesdna.png","https://about.gitlab.com/blog/everyone-who-has-contributed","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Visualizing 11 years of GitLab contributions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n        \"datePublished\": \"2022-12-19\",\n      }",{"title":2268,"description":2269,"authors":2274,"heroImage":2270,"date":2275,"body":2276,"category":996,"tags":2277},[742],"2022-12-19","\n\nGitLab’s mission is to make it so that **[everyone can contribute](/company/mission/#mission)**. While I have been experiencing this mission for three years, I wondered if there was a way to visualize the effect of having everyone contribute over GitLab's history. It turns out there is. An open source project known as [Gource](https://gource.io/) can create an animated visualization of the commit history of a repository. I ran it against the GitLab repository and it visualizes 11 years of busy developers contributing over 300,000 commits to GitLab - covered in just under 10 minutes of video. Each node in the visualization is a file and the count of various file types is shown on the left.\n\nA big thank you to absolutely everyone who has made contributions to GitLab over the years. Hopefully this visualization helps you have a greater sense of this community.\n\nGitLab has recently published the management principles that help enable the \"everyone can contribute\" mission within GitLab. This new people management framework is called [TeamOps](/teamops/). Everyone can learn and become certified in TeamOps through GitLab’s learning portal.\n\nAs another mile marker of the power of the everyone can contribute mission, GitLab also just celebrated one year as [a public company](/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public/)!\n\nI hope you enjoy Gource’s video visualization, which is filled with the glow of light - seems very appropriate for the many global cultural festivals at this time of year that use light and fireworks to celebrate their communities!\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"1870\" height=\"937\" src=\"https://www.youtube.com/embed/QxLzyJDljpg\" title=\"\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nIf you'd like to become a contributor, check out our [contribution guide](/community/contribute/).\n",[266,1166,9],{"slug":2279,"featured":6,"template":683},"everyone-who-has-contributed","content:en-us:blog:everyone-who-has-contributed.yml","Everyone Who Has Contributed","en-us/blog/everyone-who-has-contributed.yml","en-us/blog/everyone-who-has-contributed",{"_path":2285,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2286,"content":2291,"config":2298,"_id":2300,"_type":13,"title":2301,"_source":15,"_file":2302,"_stem":2303,"_extension":18},"/en-us/blog/expanded-registration-features-program",{"title":2287,"description":2288,"ogTitle":2287,"ogDescription":2288,"noIndex":6,"ogImage":1387,"ogUrl":2289,"ogSiteName":670,"ogType":671,"canonicalUrls":2289,"schema":2290},"Security features now free with expanded Registration Program","More features are now available for free to free self-managed Enterprise Edition users when they register and turn on their Service Ping.","https://about.gitlab.com/blog/expanded-registration-features-program","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Free access to security, other features with expanded Registration Features Program\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Waldner\"}],\n        \"datePublished\": \"2023-05-24\",\n      }",{"title":2292,"description":2288,"authors":2293,"heroImage":1387,"date":2295,"body":2296,"category":678,"tags":2297},"Free access to security, other features with expanded Registration Features Program",[2294],"Sarah Waldner","2023-05-24","\nIn GitLab 14.1, we introduced [Registration Features](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#registration-features-program), which offers free self-managed users running [GitLab Enterprise Edition](https://about.gitlab.com/enterprise/) free use of paid features by registering with GitLab and sending us activity data via Service Ping. This month, we are expanding the program to include five more features:\n\n1. [Password complexity requirements](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#password-complexity-requirements): By default, the only requirement for user passwords is minimum password length. To increase security of user accounts, you have the option to add additional complexity requirements. Under Minimum password length, select additional password complexity requirements. You can require numbers, uppercase letters, lowercase letters, and symbols.\n2. [Track description changes in issues](https://docs.gitlab.com/ee/user/discussions/index.html#view-description-change-history): When multiple people are collaborating on an issue, it is common to see the description change with no explanation. This feature makes it easy to review previous versions of the issue description or understand who made which specific changes. Issue description versions can be compared by looking at the changes to the description listed in the history. To compare the changes, select Compare with the previous version.\n3. [Configurable issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html#configurable-issue-boards): An issue board can be associated with a milestone, labels, assignee, weight, and current iteration, which automatically filter the board issues accordingly. This allows you to create unique boards according to your team’s needs.\n4. [Coverage-guided fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#coverage-guided-fuzz-testing): Coverage-guided fuzz testing sends random inputs to an instrumented version of your application in an effort to cause unexpected behavior. Such behavior indicates a bug that you should address. GitLab allows you to add coverage-guided fuzz testing to your pipelines. This helps you discover bugs and potential security issues that other QA processes may miss.\n5. [Maintenance Mode](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html): Maintenance Mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, and Container repositories. When Maintenance Mode is enabled, in-progress actions finish relatively quickly since no new actions are coming in, and internal state changes are minimal.\n\nThe above five features join the list of features already available to the registered tier:\n1. [Email from GitLab](https://docs.gitlab.com/ee/administration/email_from_gitlab.html#email-from-gitlab): Allow admins to send mass notification emails to all users, or subset of users based on project or group memberships.\n2. [Repository size limit](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#repository-size-limit): Ensure that disk space usage is under control by setting a hard limit for your repositories’ size; limits can be set globally, per group or per project.\n3. [Restrict access by IP address](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-ip-address): Restrict access at the group level to incoming traffic adhering to an IP address subnet; ensures only people from your organization can access particular resources.\n\n## How to to participate in the Registration Features Program \nIf you are interested in participating as a free self-managed user running GitLab Enterprise Edition, you can read about [how to turn on Service Ping here](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#enable-or-disable-usage-statistics).\n",[9,678,701],{"slug":2299,"featured":6,"template":683},"expanded-registration-features-program","content:en-us:blog:expanded-registration-features-program.yml","Expanded Registration Features Program","en-us/blog/expanded-registration-features-program.yml","en-us/blog/expanded-registration-features-program",{"_path":2305,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2306,"content":2312,"config":2318,"_id":2320,"_type":13,"title":2321,"_source":15,"_file":2322,"_stem":2323,"_extension":18},"/en-us/blog/expanding-guest-capabilities-in-gitlab-ultimate",{"title":2307,"description":2308,"ogTitle":2307,"ogDescription":2308,"noIndex":6,"ogImage":2309,"ogUrl":2310,"ogSiteName":670,"ogType":671,"canonicalUrls":2310,"schema":2311},"The feature you wanted - Expanded Guest capabilities in GitLab Ultimate","GitLab Ultimate customers can now provide Guests the ability to view code. Learn how to access this new capability.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682652/Blog/Hero%20Images/iterating-cover.jpg","https://about.gitlab.com/blog/expanding-guest-capabilities-in-gitlab-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The feature you wanted - Expanded Guest capabilities in GitLab Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hannah Sutor\"}],\n        \"datePublished\": \"2023-03-08\",\n      }",{"title":2307,"description":2308,"authors":2313,"heroImage":2309,"date":2315,"body":2316,"category":849,"tags":2317},[2314],"Hannah Sutor","2023-03-08","\n\n[Customizable roles](https://docs.gitlab.com/ee/user/permissions.html) have been on GitLab's roadmap for the past two years. When we began working on them a year ago, our team struggled to find the [minimal viable change](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) (MVC) that would benefit customers. At the same time, through different feedback channels, customers were telling us they wanted more from their Ultimate tier Guest user roles. There it was: our MVC!\n\nHere is what happened next.\n\n## Our MVC journey\n\nWhen we began working on customizable roles, we knew that the six static, out-of-the-box roles that come with GitLab were not flexible enough to cover the use cases of our customers. Some roles were too permissive, while others didn’t grant the permissions necessary to accomplish a task. At a time when security and abiding by [the principle of least privilege](https://www.techtarget.com/searchsecurity/definition/principle-of-least-privilege-POLP) is more top of mind than ever, we needed to give our customers a way to define their own roles.\n\nThe customer ask was clear, but the implementation path was not. Performance considerations were top of mind. Permission policies are evaluated when any user action is performed, and we need a secure but scalable way for thousands of users, who may have hundreds of custom roles created, to do their work in GitLab. The team did a lot of technical discovery and performance testing in order to ensure the chosen technical implementation was scalable.\n\nWe decided to start with a very small implementation of custom roles - something that would be meaningful to customers, while also allowing our team to test the new backend implementation that will support custom role creation and usage.\n\n## How custom roles work\n\nFor our MVC, we decided that GitLab.com customers with an Ultimate license should be able to create a custom role that is based on the current “Guest” role. They will be able to add one additional permission to the “Guest” role - the ability to view code. This effectively creates a “Guest+1” role. They can then assign this custom role to any existing user. \n\nPreviously, Guests were able to view code on Self-Managed GitLab, and only on internal or public projects. Now, this functionality is available to Guests across the board - in GitLab.com and Self-Managed GitLab, and regardless of project visibility setting. You just need to create and apply the custom Guest role to any user who wishes to view code.\n\nYou can read more about how to [implement this yourself](https://docs.gitlab.com/ee/user/permissions.html#custom-roles) and watch a demo [here](https://about.gitlab.com/releases/2023/02/22/gitlab-15-9-released/#users-with-the-guest-role-can-view-private-repositories).\n\n## Create a custom role\n\nUse the API to create the “Guest+1” custom role. This role will show up as \"Guest - custom\" in the UI, so that it's easy to see which users have this version of the \"Guest\" role assigned.\n\nOnce the custom role is created, you can [use the API](https://docs.gitlab.com/ee/user/permissions.html#custom-roles) to associate it to a list of users. Voila! Now, your users have a custom role that allows them to view code as a Guest.\n\n![customizable guest role](https://about.gitlab.com/images/blogimages/iterating-towards-customizable-roles/guest-custom-role.png){: .shadow}\n\n## Why this MVC?\n\nSometimes, something is so loud that you’re forced to listen to it. That’s undoubtedly how I felt when I heard the dissatisfaction of our Ultimate customers around Guest users in private projects.\n\nAn unlimited number of Guest users are free with a GitLab Ultimate subscription. However, if the Guest user doesn’t have enough access to really do much within the product, is it really of any value at all? Customers left us a lot of feedback that the low level of privilege the Guest users have for private projects was detrimental to their users' workflows - making those “free” users not actually useful at all. We knew it was time to deliver more value.\n\n## What’s next\n\nOur final vision for customizable roles in GitLab is for our users to be able to take what exists today in our [permissions table](https://docs.gitlab.com/ee/user/permissions.html) and toggle each permission off/on as they please to define a custom role. \n\nWe plan to start on this by [consolidating](https://gitlab.com/groups/gitlab-org/-/epics/8914) some of these permissions - both for practical and performance reasons. As you can imagine, some permissions don’t make sense to be toggled “on” if a different feature is “off.\" We will be removing the need for complex logic by consolidating permissions into larger sets that make sense to be enabled/disabled at the same time. This should also translate nicely on the usability side - permutations of 100+ individual permissions would be unwieldy to manage, as a systems administrator, and difficult to understand your role definition, as an end user.\n\nThis update to custom roles is a great example of our iteration value here at GitLab, and I’m most excited about the fact that it’s solving an acute pain point for our Ultimate customers. They deserve to get a lot of value out of their Ultimate subscription, and I am hopeful that an additional permission for Guest users is one way we can increase their value. It’s also a great first step towards our grand customizable roles vision. I hope you’ll give it a try!\n\n**Check out this demo that shows the customizable guest role in action:**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/46cp_-Rtxps\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[9,829,478],{"slug":2319,"featured":6,"template":683},"expanding-guest-capabilities-in-gitlab-ultimate","content:en-us:blog:expanding-guest-capabilities-in-gitlab-ultimate.yml","Expanding Guest Capabilities In Gitlab Ultimate","en-us/blog/expanding-guest-capabilities-in-gitlab-ultimate.yml","en-us/blog/expanding-guest-capabilities-in-gitlab-ultimate",{"_path":2325,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2326,"content":2331,"config":2337,"_id":2339,"_type":13,"title":2340,"_source":15,"_file":2341,"_stem":2342,"_extension":18},"/en-us/blog/explain-this-code",{"title":2327,"description":2328,"ogTitle":2327,"ogDescription":2328,"noIndex":6,"ogImage":906,"ogUrl":2329,"ogSiteName":670,"ogType":671,"canonicalUrls":2329,"schema":2330},"ML experiment: Explain this source code","Learn how GitLab is experimenting with ML-powered source code explanation features in this fourth installment of our ongoing AI/ML in DevSecOps series.","https://about.gitlab.com/blog/explain-this-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Explain this source code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2023-04-06\",\n      }",{"title":2327,"description":2328,"authors":2332,"heroImage":906,"date":2334,"body":2335,"category":806,"tags":2336},[2333],"Taylor McCaslin","2023-04-06","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nDeciphering the source code of a new software project can be a daunting or at least time-consuming task. The code may be poorly documented, or it may be written in a programming language that is unfamiliar to the developer. Even if the developer is familiar with the programming language, the code may be complex and difficult to understand. But what if developers had a helpful tool to figure out very quickly what code was doing? With recent advancements in AI models, it's now possible to have code explained in natural language. \n\n## Explain this code with AI\nAt GitLab, we’re experimenting with AI-assisted code explanations. We want to enable software developers to quickly understand source code they encounter. Whether it's starting with a new project, contributing to a project in a language they're not fluent in, or just trying to understand historical code, we want to help developers get up to speed quickly.\n\nIn a rapid prototype, our own [Denys Mishunov](https://gitlab.com/mishunov), Staff Frontend Engineer, and [Michael Le](https://gitlab.com/mle), Senior Product Designer for our [Create::Source Code group](/handbook/product/categories/#source-code-group), leverage AI to power code explanations within [GitLab's repository source code file viewer](https://docs.gitlab.com/ee/user/project/repository/).\n\n\n![Prototype UX for Explain this Code](https://about.gitlab.com/images/blogimages/explain-this-code-hr.png){: .shadow}\n\nAbove, you can see an example of highlighting a selection of code and asking for a code explanation. Watch the full demo below. \n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/xzsFfFqvlnU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Iterating on AI/ML features\nWhile just an experiment today, we are iterating on how to effectively bring features like this to our customers. We're starting on the repository file viewer, and this prototype can be extended to anywhere you interact with code within GitLab, from [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) to [snippets](https://docs.gitlab.com/ee/user/snippets.html), and beyond. \n\nThis experiment is just the start of the ways we’re looking to infuse GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI Assisted features. We’ll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas. \n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[851,701,9,786],{"slug":2338,"featured":6,"template":683},"explain-this-code","content:en-us:blog:explain-this-code.yml","Explain This Code","en-us/blog/explain-this-code.yml","en-us/blog/explain-this-code",{"_path":2344,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2345,"content":2350,"config":2355,"_id":2357,"_type":13,"title":2358,"_source":15,"_file":2359,"_stem":2360,"_extension":18},"/en-us/blog/explain-this-vulnerability",{"title":2346,"description":2347,"ogTitle":2346,"ogDescription":2347,"noIndex":6,"ogImage":1387,"ogUrl":2348,"ogSiteName":670,"ogType":671,"canonicalUrls":2348,"schema":2349},"ML experiment: Explain this vulnerability","Learn how GitLab is experimenting with vulnerability explanation and mitigation recommendations in this latest installment of our ongoing 'AI/ML in DevSecOps' series.","https://about.gitlab.com/blog/explain-this-vulnerability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Explain this vulnerability\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2023-05-02\",\n      }",{"title":2346,"description":2347,"authors":2351,"heroImage":1387,"date":2352,"body":2353,"category":806,"tags":2354},[2114],"2023-05-02","\n\n\u003Ci>This blog is the latest post an ongoing series about GitLab’s journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The first blog post can be found [here](/blog/what-the-ml-ai/). Throughout the series, we’ll feature blogs from our product, engineering, and UX teams to showcase how we’re infusing AI/ML into GitLab.\u003C/i>\n\nGitLab surfaces vulnerabilities that contain relevant information. However, more often users aren't sure where to start. \nIt takes time to research and synthesize information that is surfaced within the vulnerability record. Moreover, figuring out how to fix a given vulnerability can be difficult.\n\nTo help teams identify an effective way to fix a vulnerability within the context of their specific code base, we have released an [experimental](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment)\n feature that provides GitLab AI-assisted vulnerability recommendations leveraging the explanatory power of large language models. This capability combines basic vulnerability \n information with insights derived from the customer's code to explain the vulnerability in context, demonstrate how it can be exploited, and provide an example fix.\n\n[Isaac Dawson](https://gitlab.com/idawson) and [Dinesh Bolkensteyn](https://gitlab.com/dbolkensteyn), both [GitLab Vulnerability Research](/handbook/engineering/development/sec/secure/vulnerability-research/) \nengineers, tested prompts in a large language model to see if prompts could yield helpful results. After fine-tuning the prompts, they found that some prompts could provide better details\n and even suggest recommendations for a fix to vulnerabilities related to static application security testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)). \n In a week's time, Product Designer [Becka Lippert](https://gitlab.com/beckalippert) designed a prototype and [Daniel Tian](https://gitlab.com/dftian), \n [Mo Khan](https://gitlab.com/mokhax), and [Neil McCorrison](https://gitlab.com/nmccorrison) built this experimental feature in GitLab.\n\n![Explain and mitigate this vulnerability with AI](https://about.gitlab.com/images/blogimages/2023-04-27-explain-this-vulnerability.png){: .shadow}\n\n\nThis feature is powered by Google AI. Learn more about [our partnership with Google Cloud](https://about.gitlab.com/press/releases/2023-05-02-gitLab-and-google-cloud-partner-to-expand-ai-assisted-capabilities.html) to enrich GitLab features with generative AI.\n\nYou can explore the \"explain this vulnerability\" feature with a [click-through demo](https://go.gitlab.com/0qIe3O).\n\n## Iterating on AI/ML features\n\nThis [experimental](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment) feature is available in GitLab.com today. We are exploring what this feature could look like for \nother types of vulnerabilities beyond SAST and in a merge request. Have an idea that would make this feature better? Please share it with us, along with any feedback, in this \n[issue](https://gitlab.com/gitlab-org/gitlab/-/issues/407295).\n\nThis experiment is just the start of the ways we're looking to infuse GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI Assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[678,9,703,786],{"slug":2356,"featured":6,"template":683},"explain-this-vulnerability","content:en-us:blog:explain-this-vulnerability.yml","Explain This Vulnerability","en-us/blog/explain-this-vulnerability.yml","en-us/blog/explain-this-vulnerability",{"_path":2362,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2363,"content":2368,"config":2374,"_id":2376,"_type":13,"title":2377,"_source":15,"_file":2378,"_stem":2379,"_extension":18},"/en-us/blog/extending-code-suggestions",{"title":2364,"description":2365,"ogTitle":2364,"ogDescription":2365,"noIndex":6,"ogImage":906,"ogUrl":2366,"ogSiteName":670,"ogType":671,"canonicalUrls":2366,"schema":2367},"ML experiment: Extending Code Suggestions to more development environments","Learn how GitLab is experimenting with extending Code Suggestions to Visual Studio, JetBrains IDE, Neovim, and other environments in our ongoing 'AI/ML in DevSecOps' series.","https://about.gitlab.com/blog/extending-code-suggestions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Extending Code Suggestions to more development environments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2023-06-01\",\n      }",{"title":2364,"description":2365,"authors":2369,"heroImage":906,"date":2371,"body":2372,"category":806,"tags":2373},[2370],"Kai Armstrong","2023-06-01","\n\n\u003Ci>This blog is the latest post in an ongoing series about GitLab's journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nWe've been continuing to [extend the reach](/blog/code-suggestions-for-all-during-beta/) of GitLab Code Suggestions and make [improvements](/blog/code-suggestions-improves-developer-productivity/) to enhance developer productivity. Continuing with our theme of experimentation and iteration, we're now announcing experimental support for Code Suggestions in Visual Studio, JetBrains IDEs, Neovim, and other development environments.\n\n## Code Suggestions for Visual Studio\n\nIn this rapid prototype, [Michael Eddington](https://gitlab.com/mikeeddington), Staff Backend Engineer, built an extension to bring GitLab Code Suggestions to Visual Studio. With this experiment, you can begin writing code and have suggestions provided to help accelerate your development efforts while you type.\n\n![GitLab Code Suggestions in Visual Studio](https://about.gitlab.com/images/blogimages/code-suggestions-visual-studio-ide.gif){: .shadow}\n\nYou can follow our instructions for [getting started](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-visual-studio-experiment#getting-started) to try this extension out today. Provide your feedback about this extension in [this issue](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-visual-studio-experiment/-/issues/1).\n\n## Code Suggestions for JetBrains IDEs\n\nIn this rapid prototype, [Dinesh Bolkensteyn](https://gitlab.com/dbolkensteyn), Senior Vulnerability Researcher, built a plugin to bring GitLab Code Suggestions to JetBrains IDE. With this experiment, you can begin writing code and have suggestions provided to help accelerate your development efforts while you type.\n\n![GitLab Code Suggestions in JetBrains IDE](https://about.gitlab.com/images/blogimages/code-suggestions-jetbrains-ide.gif){: .shadow}\n\nYou can follow our instructions for [getting started](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-jetbrains-experiment#getting-started) to try it out today. Provide your feedback about this extension in [this issue](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-jetbrains-experiment/-/issues/2).\n\n## Code Suggestions Language Server for Neovim and more\n\nIn this rapid prototype, [Julian Thome](https://gitlab.com/julianthome), Staff Vulnerability Research Engineer, and [Michael Henriksen](https://gitlab.com/mhenriksen), Senior Vulnerability Research Engineeer, developed a language server that leverages the Language Server Protocol to provide GitLab Code Suggestions in Neovim or any other [editor with LSP support](https://microsoft.github.io/language-server-protocol/implementors/tools/). \n\n![GitLab Code Suggestions in Neovim](https://about.gitlab.com/images/blogimages/code-suggestions-neovim.gif){: .shadow}\n\nThis language server allows you to configure any supporting editor or IDE to start receiving GitLab Code Suggestions as you type. We've provided instructions for getting started with [Neovim](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-language-server-experiment/-/blob/main/docs/nvim.md), [Sublime Text](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-language-server-experiment/-/blob/main/docs/sublime.md), and [Emacs](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-language-server-experiment/-/blob/main/docs/emacs.md) for your convenience. Provide your feedback about these integrations in [this issue](https://gitlab.com/gitlab-org/editor-extensions/experiments/gitlab-code-suggestions-language-server-experiment/-/issues/2).\n\n## Iterating on AI/ML features\n\nWhile these are just experiments today, we are iterating on how to effectively bring mature IDE integrations like these to our customers. We'll continue to refine these integrations and improve the experience to provide you with streamlined code suggestions while you work, wherever you choose to work. We're also working to expand our scope beyond these IDEs so if you have an interest in seeing an additional editor/IDE supported, [let us know](https://gitlab.com/groups/gitlab-org/-/epics/2431).\n\nThis experiment is just the start of the ways we're infusing GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":2375,"featured":6,"template":683},"extending-code-suggestions","content:en-us:blog:extending-code-suggestions.yml","Extending Code Suggestions","en-us/blog/extending-code-suggestions.yml","en-us/blog/extending-code-suggestions",{"_path":2381,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2382,"content":2388,"config":2394,"_id":2396,"_type":13,"title":2397,"_source":15,"_file":2398,"_stem":2399,"_extension":18},"/en-us/blog/feature-flags-continuous-delivery",{"title":2383,"description":2384,"ogTitle":2383,"ogDescription":2384,"noIndex":6,"ogImage":2385,"ogUrl":2386,"ogSiteName":670,"ogType":671,"canonicalUrls":2386,"schema":2387},"Learn more about Feature Flags: The next step in Progressive Delivery","How Feature Flags are continuing the next evolution of continuous delivery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670020/Blog/Hero%20Images/feature-flags.jpg","https://about.gitlab.com/blog/feature-flags-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Learn more about Feature Flags: The next step in Progressive Delivery\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-08-06\",\n      }",{"title":2383,"description":2384,"authors":2389,"heroImage":2385,"date":2391,"body":2392,"category":849,"tags":2393},[2390],"Chrissie Buchanan","2019-08-06","\n\n[DevOps](/topics/devops/) is always evolving. Continuous delivery made a major impact on the way software is deployed, but we don’t think the innovation stops there. As we move into more of a [multi-cloud](/topics/multicloud/), hybrid development world, continuous delivery has continued to change into something more “progressive.”\n\n[Progressive Delivery](https://redmonk.com/jgovernor/2018/08/06/towards-progressive-delivery/) isn’t exactly the new idea that continuous delivery was; it’s simply a continuation of it. What Progressive Delivery does is give more precision to the delivery process through new ideas and best practices, reducing the risks of one big, risky deployment. At GitLab, we think Progressive Delivery is the next logical evolution of DevOps beyond CI/CD and will become the default way to release software in the future.\n\nWe previously discussed [how Review Apps can enable Progressive Delivery](/blog/progressive-delivery-using-review-apps/), and today we’ll discuss the targeted rollout process of Feature Flags.\n\n## What are Feature Flags?\n\n[Feature Flags](/direction/release/feature_flags/) (also known as feature toggles, feature flippers, or feature switches) give developers the ability to roll out features selectively without changing the source code. Incomplete features can be merged into the production code but flagged on or off, which allows many small, incremental versions of software to be delivered without the cost of constant branching and merging.\n\nFeature Flags are designed to minimize the blast radius of releasing new features. By utilizing Feature Flags, developers can release to a subset of users and roll back easily through toggling, leaving the live code intact. A feature can also be tested before it’s completed and ready for release. This technique allows developers to release a version of a product that has unfinished features which are hidden (toggled) so they do not appear in the user interface.\n\n[Martin Fowler organizes Feature Flags into four different categories](https://martinfowler.com/articles/feature-toggles.html) based on how long they’re typically in place and how dynamic they should be:\n\n*   **Release toggles**: A temporary flag which allows incomplete, latent code to be shipped to production and turned on or off, or perhaps never enabled at all.\n*   **Experiment toggles**: A short-lived toggle usually used for multivariate A/B testing, kept in place only long enough to gather results.\n*   **Ops toggles**: For releases that have unclear performance implications, this toggle allows system administrators to roll back quickly, but it’s not unheard of for long-term toggles to remain in place as a kill switch.\n*   **Permission toggles**: Manages features for specific users, such as “premium” features, alpha or beta features, or even internal features. These toggles can be very long-lived.\n\nFeature Flags can be a quick way to do [version control](/topics/version-control/) so that [continuous delivery](/topics/continuous-delivery/) remains continuous. Their ability to turn off or on with simple commands makes Feature Flags a low-risk option for introducing new features. While they’re easy to use, they can have some drawbacks if not implemented properly.\n\n## Working with Feature Flags\n\nSome worry about the added complexity with Feature Flags, since code may need to be tested with toggles on and off, essentially doubling the load. While it’s not necessary to test every toggle configuration, a best practice is for developers to test code that has the greatest likelihood of going live in production. According to Martin Fowler, a good convention is to enable existing or legacy behavior when a Feature Flag is Off, and new or future behavior when it's On.\n\nAnother risk of using Feature Flags is stale flags, a situation when flags are left in the code and forgotten about. As teams add more and more flags into their code, it can become harder to keep track of and verify the flags.\n\nToday, organizations rely on feature management systems such as [Launch Darkly](https://launchdarkly.com/) or [Optimizely](https://blog.optimizely.com/2017/10/18/feature-management/) in order to use Feature Flags. As with any link in a toolchain, this adds an additional level of oversight that can be hard to manage and maintain. Analysts recognize that feature-toggling capabilities are becoming more of what's fundamentally needed for a continuous delivery platform. While we are still in the early stages of Feature Flags, we do have some alpha Feature Flag capabilities already built into GitLab you can try out today, and we will be launching additional functionality in 12.2:\n\n*   [Feature Flags enabled for specific users](https://gitlab.com/gitlab-org/gitlab-ee/issues/11459)\n*   [Percent rollout per environment](https://gitlab.com/gitlab-org/gitlab-ee/issues/8240)\n\n## GitLab and Progressive Delivery\n\nAs we continue to iterate on our [product vision for CI/CD](/direction/ops/#progressive-delivery), we’re adopting a Progressive Delivery mindset for how we implement new features into GitLab. As a complete [DevOps platform](/solutions/devops-platform/), delivered as a [single application](/topics/single-application/), it’s important for us to offer a comprehensive solution that offers the latest best practices. Review Apps, Canary Deployments, and Feature Flags are just some of the ways we’re bringing Progressive Delivery to the GitLab community.\n\nTo learn more about how we’re using Feature Flags and Feature flag best practicies in GitLab, watch this deep dive with our Director of Product Management, [Jason Yavorska](/company/team/#jyavorska).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/TSSqNUhbbmQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nFeature Flags can be a useful way to validate and measure performance before rolling out a feature to a broader audience. High visibility makes DevOps more efficient, and integrating Feature Flags into the same application where your code repositories, CI/CD, project planning, and monitoring occurs can overcome many of the challenges associated with Feature Flags.\n\nLearn how GitLab’s built-in CI/CD helps teams implement Progressive Delivery tools such as [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/), [Feature Flags](/direction/release/feature_flags/), and [Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html), without the complicated integrations and plugin maintenance.\n\n[Explore GitLab CI/CD](/solutions/continuous-integration/)\n{: .alert .alert-gitlab-purple .text-center}\n\nCover image by [Chris Lawton](https://unsplash.com/@chrislawton?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/flags?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[108,9],{"slug":2395,"featured":6,"template":683},"feature-flags-continuous-delivery","content:en-us:blog:feature-flags-continuous-delivery.yml","Feature Flags Continuous Delivery","en-us/blog/feature-flags-continuous-delivery.yml","en-us/blog/feature-flags-continuous-delivery",{"_path":2401,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2402,"content":2408,"config":2414,"_id":2416,"_type":13,"title":2417,"_source":15,"_file":2418,"_stem":2419,"_extension":18},"/en-us/blog/first-look-the-new-agile-planning-experience-in-gitlab",{"title":2403,"description":2404,"ogTitle":2403,"ogDescription":2404,"noIndex":6,"ogImage":2405,"ogUrl":2406,"ogSiteName":670,"ogType":671,"canonicalUrls":2406,"schema":2407},"First look: The new Agile planning experience in GitLab","Learn about new capabilities, including a brand-new framework, that will support a more unified and flexible user experience – and find out what's coming next.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"First look: The new Agile planning experience in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Melissa Ushakov\"}],\n        \"datePublished\": \"2024-06-18\",\n      }",{"title":2403,"description":2404,"authors":2409,"heroImage":2405,"date":2411,"body":2412,"category":1228,"tags":2413},[2410],"Melissa Ushakov","2024-06-18","In today's fast-paced world, GitLab customers rely on our [Agile planning features](https://about.gitlab.com/solutions/agile-delivery/) to consistently deliver value to their users. By leveraging GitLab's issues, sub-epics, and epics, leaders gain a clear view of organizational activities, enabling them to make strategic decisions that align with their business goals. At GitLab, understanding and adapting to our customers' needs is core to our mission. As our customers' needs evolve, so must our approach, prompting us to enhance our existing functionalities to serve them better.\n\nGitLab has embarked on a journey to advance our [Agile planning](https://about.gitlab.com/blog/categories/agile-planning/) capabilities and unlock a new level of collaboration and shared awareness from tasks to goals. In this article, you'll learn about our approach to Agile planning, what you can expect to change in the next few releases, and our exciting long-term vision.\n\n## The need for a new approach\n\nToday, [epics](https://docs.gitlab.com/ee/user/group/epics/) and [issues](https://docs.gitlab.com/ee/user/project/issues/) exist as separate experiences. For example, epics don’t have assignees and issues are not supported at the group level. These differences create friction for team leaders who work with issues and epics and expect similar functionality to be available for a seamless workflow and effective Agile planning. The lack of uniformity can also cause confusion among team members and ultimately hinder productivity. We understand that these differences make the Agile planning experience in GitLab more challenging than it should be.\n\n![Image of challenges in Agile planning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099086/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099086456.png)\n\n\u003Ccenter>\u003Ci>Inconsistencies between issues and epics can introduce friction to user workflows.\u003C/i>\u003C/center>\n\n\u003Cp>\n\nConsistency is not the only challenge with the current Agile planning experience in GitLab. Our user base feedback and market analysis point to the need for more flexibility to represent an organization’s unique way of working. Many Agile and strategic frameworks in the market inform an organization's processes. Our approach is to provide a flexible solution that can adapt to your needs while supporting common, out-of-the-box frameworks. One example of a widely adopted framework is \"Objectives and Key Results,\" which helps leaders tie operational work to strategic objectives. Epics and issues alone could not support our customers' growing need for more types of planning objects to represent their organization’s workflow.\n\nYour input has been invaluable in shaping our strategy to center on a unified experience; as a result, we created the Work Items framework to reimagine our current issue and epic implementation and pave the way for the future. This new model will allow us to provide a more consistent experience for our existing Agile planning objects, improving the day-to-day experience for Agile teams using GitLab. It will also facilitate the introduction of new features and improvements more rapidly, as the unified architecture simplifies development and maintenance. The Work Items framework is crucial to delivering a more powerful, flexible, and user-friendly Agile planning experience in GitLab.\n\n![Work Items framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099086/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099086457.png)\n\n\u003Ccenter>\u003Ci>The Work Items framework provides a starting point for existing planning objects and sets a foundation for new types.\u003C/i>\u003C/center>\n\n## Iterating while rebuilding\n\nProtecting our users from disruption was a top priority as we rebuilt our Agile planning capabilities. Many users rely on epics and issues for business-critical processes in their organization, so an uninterrupted experience was paramount. We also wanted to keep true to GitLab’s iteration value to ensure and deliver value incrementally. Tasks were introduced and are powered by the Work Items framework, allowing us to provide net new value to our users while we build the capabilities needed for issues and epics over time. Tasks have had incredible adoption and have provided a way for us to get invaluable feedback about the new work items experience.\n\n![Tasks in the Work Items framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099086/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099086459.png)\n\n\u003Ccenter>\u003Ci>Tasks provide a way to decompose issues and were the first item to use the Work Items framework.\u003C/i>\u003C/center>\n\n## Exciting updates coming\n\nWe are excited to announce a refreshed epics and issues experience in GitLab – powered by the Work Items framework – is coming later this year. Existing epic and issue data, APIs, webhooks, and URLs will continue to work as expected. You will not need to do anything to prepare or to take advantage of the new functionality. After the transition, you will notice a refreshed look and feel on the detail page and additional capabilities for epics, such as assignees, health status, and more!\n\n![Issues and epics in the Work Items framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099086/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099086461.png)\n\n\u003Ccenter>\u003Ci>The Work Items framework will drive consistency for issues and epics.\u003C/i>\u003C/center>\n\n \u003Cp>\n\nThis is just the beginning of our journey! Over the next few months, we will release long-awaited functionality, including custom fields and configurable statuses, to provide additional flexibility in your planning workflows. We also plan to update our lists, boards, and roadmaps experience to give you more ways to interact with and visualize your planning data.\n\n![Status and priority fields](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099086/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099086463.png)\n\n\u003Ccenter>\u003Ci>Status and priority are newly planned fields to help streamline planning. Custom fields can meet various use cases like value scores and approval processes. \u003C/i>\u003C/center>\n\n## Getting started with GitLab\n\nWe can’t wait for you to experience these enhancements. They’re designed to take your Agile planning to the next level. Stay tuned for more updates, and get ready to harness the full potential of GitLab’s innovative capabilities!\n\n> The Enterprise Agile Planning add-on is available to GitLab Ultimate subscriptions. Please [contact your GitLab sales representative](https://about.gitlab.com/sales/) for more information.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[1164,9],{"slug":2415,"featured":90,"template":683},"first-look-the-new-agile-planning-experience-in-gitlab","content:en-us:blog:first-look-the-new-agile-planning-experience-in-gitlab.yml","First Look The New Agile Planning Experience In Gitlab","en-us/blog/first-look-the-new-agile-planning-experience-in-gitlab.yml","en-us/blog/first-look-the-new-agile-planning-experience-in-gitlab",{"_path":2421,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2422,"content":2428,"config":2434,"_id":2436,"_type":13,"title":2437,"_source":15,"_file":2438,"_stem":2439,"_extension":18},"/en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"title":2423,"description":2424,"ogTitle":2423,"ogDescription":2424,"noIndex":6,"ogImage":2425,"ogUrl":2426,"ogSiteName":670,"ogType":671,"canonicalUrls":2426,"schema":2427},"From code to production: A guide to continuous deployment with GitLab","Learn how to get started building a robust continuous deployment pipeline in GitLab. Follow these step-by-step instructions, practical examples, and best practices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"From code to production: A guide to continuous deployment with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":2423,"description":2424,"authors":2429,"heroImage":2425,"date":1912,"body":2432,"category":701,"tags":2433},[2430,2431],"Benjamin Skierlak","James Wormwell","Continuous deployment is a game-changing practice that enables teams to deliver value faster, with higher confidence. However, diving into advanced deployment workflows — such as GitOps, container orchestration with Kubernetes, or dynamic environments — can be intimidating for teams just starting out.\n\nAt GitLab, we're committed to making delivery seamless and scalable. By enabling teams to focus on the fundamentals, we empower them to build a strong foundation that supports growth into more complex strategies over time. This guide provides essential steps to begin implementing continuous deployment with GitLab, laying the foundation for your long-term success.\n\n## Start with a workflow plan\n\nBefore diving into the technical implementation, take time to map out your deployment workflow. Success lies in careful planning and a methodical approach.\n\n### Artifact management strategy\n\nIn the context of continuous deployment, artifacts are the packaged outputs of your build process that need to be stored, versioned, and deployed. These could be:\n\n- container images for your applications\n- packages\n- compiled binaries or executables\n- libraries\n- configuration files\n- documentation packages\n- other artifacts\n\nEach type of artifact plays a specific role in your deployment process. For example, a typical web application might generate:\n\n- a container image for the backend service\n- a ZIP archive of compiled frontend assets\n- SQL files for database changes\n- environment-specific configuration files\n\nManaging these artifacts effectively is crucial for successful deployments. Here's how to approach artifact management.\n\n#### Artifacts and releases versioning strategies\n\nA best practice to get you started with a clean structure is to establish a clear versioning strategy for your artifacts. When creating releases:\n\n- Use semantic versioning (major.minor.patch) for release tags\n  - Example: `myapp:1.2.3` for a stable release\n  - Major version changes (2.0.0) for breaking changes\n  - Minor version changes (1.3.0) for new features\n  - Patch version changes (1.2.4) for bug fixes\n- Maintain a 'latest' tag for the most recent stable version\n  - Example: `myapp:latest` for automated deployments\n- Include commit SHA for precise version tracking\n  - Example: `myapp:1.2.3-abc123f` for debugging\n- Consider branch-based tags for development environments\n  - Example: `myapp:feature-user-auth` for feature testing\n\n#### Build artifacts retention\n\nImplement defined retention rules:\n\n- Set explicit expiration timeframes for temporary artifacts\n- Define which artifacts need permanent retention\n- Configure cleanup policies to manage storage\n\n#### Registry access and authentication\n\nSecure your artifacts with proper access controls:\n\n- Implement Personal Access Tokens for developer access\n- Configure CI/CD variables for pipeline authentication\n- Set up proper access scopes\n\n### Environment strategy\n\nConsider your environments early, as they shape your entire deployment pipeline:\n\n- Development, staging, and production environment configurations\n- Environment-specific variables and secrets\n- Access controls and protection rules\n- Deployment tracking and monitoring approach\n\n### Deployment targets\n\nBe intentional as to where and how you'll deploy, these decisions matter and the benefits and drawbacks of each should be consider:\n\n- Infrastructure requirements (VMs, containers, cloud services)\n- Network access and security configurations\n- Authentication mechanisms (SSH keys, access tokens)\n- Resource allocation and scaling considerations\n\nWith our strategy defined and foundational decisions made, we can now translate these plans into a working pipeline. We'll build a practical example that demonstrates these concepts, starting with a simple application and progressively adding deployment capabilities.\n\n## Implementing your CD pipeline\n\n### A step-by-step example\n\nLet's walk through implementing a basic continuous deployment pipeline for a web application. We'll use a simple HTML application as an example, but these principles apply to any type of application. We’re also going to deploy our application as a Docker image on a simple virtual machine. This will allow us to lean on a curated image with minimum dependencies, and to ensure no environment specific requirements are unintentionally brought in. By working on a virtual machine, we won’t be leveraging GitLab’s native integrations, allowing us to work on an easier but less scalable setup to begin with.\n\n#### Prerequisites\n\nIn this example, we’ll aim to containerize an application that we’ll run on a virtual machine hosted on a cloud provider. We’ll also test this application locally on our machine. This list of prerequisites is only needed for this scenario.\n\n##### Virtual machine setup\n\n- Provision a VM in your preferred cloud provider (e.g., GCP, AWS, Azure)\n- Configure network rules to allow access on ports 22, 80, and 443\n- Record the machine's public IP address for deployment\n\n##### Set up SSH authentication:\n\n- Generate a public/private key pair for the machine\n- In GitLab, go to **Settings > CI/CD > Variables**\n- Create a variable called `GITLAB_KEY`\n- Set Type to \"File\" (required for SSH authentication)\n- Paste the private key in the Value field\n- Define a USER variable, this is the user logging in and running the scripts on your VM\n\n##### Configure deployment variables\n\n- Create variables for your deployment targets:\n  - `STAGING_TARGET`: Your staging server IP/domain\n  - `PRODUCTION_TARGET`: Your production server IP/domain\n\n##### Local development setup\n\n- Install Docker on your local machine for testing deployments\n\n##### GitLab Container Registry access\n\n- Locate your registry path:\n  - Navigate to **Deploy > Container Registry**\n  - Copy the registry path (e.g., registry.gitlab.com/group/project)\n- Set up authentication:\n  - Go to **Settings > Access Tokens**\n  - Create a new token with registry access\n  - Token expiration: Maximum 1 year\n  - Save the token securely\n- Configure local registry access:\n\n```\ndocker login registry.gitlab.com\n# The username if you are using a PAT is gitlab-ci-token\n# Password: your-access-token\n```\n\n#### 1. Create your application\n\nStart with a basic web application. For our example, we're using a simple HTML page:\n\n```\n\u003C!-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!-- Your content here -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Containerize your application\n\nCreate a Dockerfile to package your application:\n\n```\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nThis Dockerfile:\n\n- Uses nginx as a base image for serving web content\n- Copies your HTML file to the correct location in the nginx directory structure\n\n#### 3. Set up your CI/CD pipeline\n\nCreate a `.gitlab-ci.yml` file to define your pipeline stages:\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nLet's break it down:\n\n`TAG_LATEST` is made up of three parts:\n\n- `$CI_REGISTRY_IMAGE` is the path to your project's container registry in GitLab\n\nFor example: `registry.gitlab.com/your-group/your-project`\n\n- `$CI_COMMIT_REF_NAME` is the name of your branch or tag\n\nFor example, if you're on main branch: `/main`, and if you're on a feature branch: `/feature-login`\n\n- `:latest` is a fixed suffix\n\nSo if you're on the main branch, `TAG_LATEST` becomes: `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` is almost identical, but instead of `:latest`, it uses: `$CI_COMMIT_SHA` which is the commit identifier, for example: `:abc123def456`.\n\nSo for that same commit on main branch, `TAG_COMMIT` becomes:` registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nThe reason for having both is `TAG_LATEST` gives you an easy way to always get the newest version, and `TAG_COMMIT` gives you a specific version you can return to if needed.\n\n#### 4. Publish to the container registry\n\nAdd the publish job to your pipeline:\n\n```\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nThis job:\n\n- Uses Docker-in-Docker to build images\n- Creates two tagged versions of your image\n- Authenticates with the GitLab registry\n- Pushes both versions to the registry \n\nNow that our images are safely stored in the registry, we can focus on deploying them to our target environments. Let's start with local testing to validate our setup before moving to production deployments.\n\n#### 5. Deploy to your environment\n\nBefore deploying to production, you can test locally. We just published our image to the GitLab repository, which we’ll pull locally. If you’re unsure of the exact path, navigate to **Deploy > Container Registry**, and you should see an icon to copy the path of your image at the end of the line for the container image you want to test.\n\n```\ndocker login registry.gitlab.com \ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nBy doing so you should be able to access your application locally on your localhost address through your web browser.\n\nYou can now add a deployment job to your pipeline:\n\n```\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nThis job:\n\n- Sets up SSH access to your deployment target\n- Pulls the latest image\n- Removes any existing container\n- Deploys the new version\n\n#### 6. Track deployments\n\nEnable deployment tracking by adding environment configuration:\n\n```\ndeploy:\n  environment:\n    name: production\n    url: https://your-application-url.com \n```\n\nThis creates an environment object in GitLab's **Operate > Environments** section, providing:\n\n- Deployment history\n- Current deployment status\n- Quick access to your application\n\nWhile a single environment pipeline is a good starting point, most teams need to manage multiple environments for proper testing and staging. Let's expand our pipeline to handle this more realistic scenario.\n\n#### 7. Set up multiple environments\n\nFor a more robust pipeline, configure staging and production deployments:\n\n```\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nThis setup:\n\n- Deploys to staging from your main branch\n- Uses GitLab tags to trigger production deployments\n- Provides separate tracking for each environment\n\nHere and in our next step, we’re leveraging a very useful GitLab feature: tags. By manually creating a tag in the **Code > Tags** section, the `$CI_COMMIT_TAG` gets created, which allows us to trigger jobs accordingly.\n\n#### 8. Create automated release notes\n\nWe'll be using GitLab's release capabilities through our CI/CD pipeline. First, update your stages in `.gitlab-ci.yml`:\n\n```\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nNext, add the release job:\n\n```\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nYou can enhance this by adding links to your container images:\n\n```\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nFor meaningful automated release notes:\n\n- Use conventional commits (feat:, fix:, etc.)\n- Include issue numbers (#123)\n- Separate subject from body with blank line\n\nIf you want custom release notes with deployment info:\n\n```\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nOnce configured, releases will be created automatically when you create a Git tag. You can view them in GitLab under **Deploy > Releases**.\n\n#### 9. Put it all together\n\nThis is what our final YAML file looks like:\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nThis complete pipeline:\n\n- Publishes images to the registry (main branch)\n- Deploys to staging (main branch)\n- Creates releases (on tags)\n- Versions images with release tags\n- Deploys to production (on tags)\n\nKey benefits:\n\n- Clean reproducible, local development and testing environment\n- Clear path to production environments with structure to build confidence in what is deployed\n- Pattern to recover from unexpected failures, etc.\n- Ready to scale/adopt more complex deployment strategies\n\n### Best practices\n\nThroughout implementation, maintain these principles:\n\n- Document everything, from variable usage to deployment procedures\n- Use GitLab's built-in features (environments, releases, registry)\n- Implement proper access controls and security measures\n- Plan for failure with robust rollback procedures\n- Keep your pipeline configurations DRY (Don't Repeat Yourself)\n\n## Scale your deployment strategy\n\nWhat next? Here are some aspects to consider as your continuous deployment strategy matures.\n\n### Advanced security measures\n\nEnhance security through:\n\n- Protected environments with restricted access\n- Required approvals for production deployments\n- Integrated security scanning\n- Automated vulnerability assessments\n- Branch protection rules for deployment-related changes\n\n### Progressive delivery strategies\n\nImplement advanced deployment strategies:\n\n- Feature flags for controlled rollouts\n- Canary deployments for risk mitigation\n- Blue-green deployment strategies\n- A/B testing capabilities\n- Dynamic environment management\n\n### Monitoring and optimization\n\nEstablish robust monitoring practices:\n\n- Track deployment metrics\n- Set up performance monitoring\n- Configure deployment alerts\n- Establish deployment SLOs\n- Regular pipeline optimization\n\n## Why GitLab?\n\nGitLab's continuous deployment capabilities make it a standout choice for modern deployment workflows. The platform excels in streamlining the path from code to production, offering built-in container registry, environment management, and deployment tracking all within a single interface. GitLab's environment-specific variables, deployment approval gates, and rollback capabilities provide the security and control needed for production deployments, while features like review apps and feature flags enable progressive delivery approaches. As part of GitLab's complete DevSecOps platform, these CD capabilities seamlessly integrate with your entire software lifecycle.\n\n## Get started today\n\nThe journey to continuous deployment is an evolution, not a revolution. Start with the fundamentals, build a solid foundation, and gradually incorporate advanced features as your team's needs grow. GitLab provides the tools and flexibility to support you at every stage of this journey, from your first automated deployment to complex, multi-environment delivery pipelines.\n\n> Sign up for a [free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) to get started with continous deployment today.",[1397,108,9,701,746],{"slug":2435,"featured":6,"template":683},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:en-us:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","en-us/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":2441,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2442,"content":2448,"config":2454,"_id":2456,"_type":13,"title":2457,"_source":15,"_file":2458,"_stem":2459,"_extension":18},"/en-us/blog/fuzz-testing",{"title":2443,"description":2444,"ogTitle":2443,"ogDescription":2444,"noIndex":6,"ogImage":2445,"ogUrl":2446,"ogSiteName":670,"ogType":671,"canonicalUrls":2446,"schema":2447},"How recent acquisitions introduce fuzz testing to GitLab","Learn more about fuzz testing and GitLab's recent acquisitions in the space.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681436/Blog/Hero%20Images/peaches2.jpg","https://about.gitlab.com/blog/fuzz-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How recent acquisitions introduce fuzz testing to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Kerr\"}],\n        \"datePublished\": \"2020-07-17\",\n      }",{"title":2443,"description":2444,"authors":2449,"heroImage":2445,"date":2451,"body":2452,"category":678,"tags":2453},[2450],"Sam Kerr","2020-07-17","\n\n{::options parse_block_html=\"true\" /}\n\nGitLab recently acquired two of the leading companies in the fuzz testing space - [Peach Tech](http://peach.tech/) and\n[Fuzzit](https://fuzzit.dev/)! These two companies bring amazing technology into GitLab. Read on the learn more about the technology and how you can easily integrate fuzz testing into your workflow.\n\n## What is fuzz testing?\nFuzz testing is a powerful way to test your apps to find security issues and\nflaws in business logic that traditional QA methods miss. Fuzz testing works by passing\nrandomly generated inputs to your app, and assesses the results.\n\nWhen the app being tested crashes or behaves in an unexpected way, this is\ncalled a \"fault.\" When a fault is discovered, that means there is a way for a user to provide a\nsimilar, but potentially malicious, input to your app in a production environment to crash or\nexploit it. Discovering faults lets you track down bugs in your code that\nyou wouldn't find otherwise and lets you fix them before an attacker can exploit these weaknesses.\n\nThere are a few different methods for fuzz testing. The two primary\nmethods are what we call \"coverage-guided\" fuzz testing and \"behavioral\"\nfuzz testing. Fuzzit and Peach Tech bring these to Gitlab, respectively. Both methods approach fuzz testing differently.\nCoverage-guided fuzz testing leverages the [source code](/solutions/source-code-management/) and instrumented versions\nof the app to be able to observe the app as it is running and dynamically make\nnew tests during a fuzz testing session to exercise new parts of the app to find bugs. Behavioral fuzzing\ntakes a specification of how the app is _supposed_\nto work and tries random inputs to test how it actually works - which usually\nwill find bugs and security issues. Coverage-guided fuzzing and behavioral fuzzing have unique\nadvantages and disadvantages, which is why GitLab aims to offer our users both options\nso you can choose the right one (or both!) for your use case.\n\n## What makes GitLab’s fuzz testing special?\nTraditionally, fuzz testing has been difficult to set up and hard get results from.\nSome of the challenges with fuzz testing include assembling complex testing harnesses to run the fuzz tests and sorting through large amounts of results, including false positives. These challenges can make it time consuming and challenging to get meaningful results from fuzz testing.\nBringing Peach Tech and Fuzzit fuzz testing techniques into the existing GitLab\nworkflow means users can take advantage of the powerful benefits of fuzz\ntesting without any of the traditional difficulties associated with fuzz testing.\nBy bringing these two technologies into GitLab, we will make it easy for users to integrate fuzz testing into their workflows and present results in a meaningful and actionable way.\n\n![Preview of fuzz testing results in an MR](https://about.gitlab.com/images/blogimages/fuzzing_image.png){: .shadow}\nPreview of fuzz testing results in an MR.\n{: .note.text-center}\n\nGitLab will make fuzz testing part of our existing workflow\nso users do not need to use an external tool or interface. Instead, users simply include\na CI job template to use the fuzz testing engines from Fuzzit and Peach Tech. Results will appear inline for developers, alongside the\nother build and test outputs they use today.\n\n## What about open source?\nOpen source is near and dear to our hearts at GitLab. We recently [moved several\nfeatures](/blog/new-features-to-core/) to\nour open source offering. We’ll continue supporting open source\nwith fuzz testing as well. We have published several of our fuzz testing\nengines as open source, so they are accessible to any user and everyone can contribute. This will\ninclude several of the language-specific coverage-guided [fuzz testing engines](https://gitlab.com/groups/gitlab-org/security-products/analyzers/fuzzers)\nas well as [Peach Tech Community Edition](https://gitlab.com/peachtech/peach-fuzzer-community). In the future, we will consider what\nnew fuzz testing pieces we can open source to the community as we build new\ncapabilities for different use cases. One area we are considering is what we\ncan do as we eventually move into [protocol fuzz testing](https://gitlab.com/gitlab-org/gitlab/-/issues/229275). Watch this space!\n\n## When can I get it?\nGitLab will release the minimal version of fuzz testing [later this year](/direction/maturity/#secure)\nas part of GitLab Ultimate. This release will enable behavioral-guided fuzz testing of\nweb APIs that follow the [OpenAPI](https://swagger.io/specification/) specification standard. We will also be\nenabling coverage-guided fuzz testing on apps written in a variety of languages,\nstarting with Go.\n\n## What’s next?\nGitLab is excited to add fuzz testing to the already large suite of\n[application security scanners](/topics/devsecops/) in GitLab’s [Secure stage](/stages-devops-lifecycle/secure/)\nand make it part of\nthe GitLab workflow that developers use already. This makes it easy to shift security\nleft and take advantage of the benefits of fuzz testing.\n\nAs we mature our fuzz testing offering, we will make\nintegrating fuzz testing results into new parts of the workflow a priority. So GitLab developers\ncan directly view fuzz testing results and fix any issues they find. We will also focus on enabling advanced\nconfiguration options for users who want to customize their fuzz tests.\nFinally, we will be expanding fuzz testing to address\nadditional use cases, beyond just web apps and APIs. You can read more about\nour plans for maturing fuzz testing on our [direction page](/direction/secure/dynamic-analysis/fuzz-testing/).\n\nCover image by [Ian Baldwin](https://unsplash.com/@ianebaldwin) on [Unsplash](https://unsplash.com/photos/f7FwHomDgzg)\n{: .note}\n",[9,1187,704],{"slug":2455,"featured":6,"template":683},"fuzz-testing","content:en-us:blog:fuzz-testing.yml","Fuzz Testing","en-us/blog/fuzz-testing.yml","en-us/blog/fuzz-testing",{"_path":2461,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2462,"content":2468,"config":2475,"_id":2477,"_type":13,"title":2478,"_source":15,"_file":2479,"_stem":2480,"_extension":18},"/en-us/blog/geo-is-available-on-staging-for-gitlab-com",{"title":2463,"description":2464,"ogTitle":2463,"ogDescription":2464,"noIndex":6,"ogImage":2465,"ogUrl":2466,"ogSiteName":670,"ogType":671,"canonicalUrls":2466,"schema":2467},"Why we enabled Geo on the staging environment for GitLab.com","Geo is GitLab's solution for distributed teams and now we can validate and test it at scale.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669656/Blog/Hero%20Images/donald-giannatti-4qk3nQI3WHY-unsplash-small.jpg","https://about.gitlab.com/blog/geo-is-available-on-staging-for-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we enabled Geo on the staging environment for GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Douglas Alexandre\"}],\n        \"datePublished\": \"2020-04-16\",\n      }",{"title":2463,"description":2464,"authors":2469,"heroImage":2465,"date":2472,"body":2473,"category":849,"tags":2474},[2470,2471],"Fabian Zimmer","Douglas Alexandre","2020-04-16","\nWe're testing Geo at scale on GitLab.com – our largest installation of GitLab – because we believe the best way to guarantee that Geo works as expected is to [use it ourselves](/handbook/product/product-processes/#dogfood-everything).\n\nGeo is GitLab's [solution for distributed teams](https://docs.gitlab.com/ee/administration/geo/index.html). We want teams all over the world to have a great user experience - independent of how far away users are from their primary GitLab installation. To accomplish this goal, read-only Geo nodes can be created across the world in close geographical proximity to your teams. These Geo nodes replicate important data, such as projects or LFS files, from the primary GitLab instance and thereby make the data available to users. Geo can also be used as part of a disaster recovery strategy because it adds data redundancy. Geo nodes follow the primary installation closely and allow customers to failover to this node in case the primary node becomes unavailable.\n\nMany of GitLab's customers use Geo on self-managed installations that serve hundreds to thousands of users. Geo is a critical component of GitLab installations and our customers expect Geo to work at any scale. We are testing Geo at scale on our GitLab.com installation because if it works for us, chances are it will work for our worldwide group of users too.\n\nIn this blog post, we'll explain why and how we chose to enable GitLab Geo on our pre-production environment (from now on referred to as \"staging\"), the challenges we encountered, some of the immediate benefits to our customers, and what will be next.\n\n## Why do we need to use Geo at GitLab?\nIn order to build the best product possible, we believe it is imperative to [use GitLab ourselves](/handbook/product/product-processes/#dogfood-everything). Many of our Geo customers have thousands of users actively using GitLab and a major challenge for the team was to test and validate new Geo functionality at scale. Enabling Geo on the GitLab.com staging environment makes this task a lot easier.\n\nWe also used Geo to [migrate GitLab.com from Microsoft Azure to Google Cloud in 2018](/blog/moving-to-gcp/), which allowed us to improve the product by identifying bottlenecks. In the last two years, GitLab has grown dramatically and in order to push Geo forward, we need to enable it (again).\n\n### Test Geo at scale\nWhen the team decides to add new functionalities to Geo, for example [package repository replication](https://gitlab.com/groups/gitlab-org/-/epics/2346), we had to ensure that the feature's performance is as expected. Having Geo available on staging allows us to deploy these changes behind a feature flag first and evaluate the performance before shipping the feature to customers. This is especially relevant to some of Geo's PostgreSQL database queries. On a small test deployment, things may look fine, but at scale these queries can time out, resulting in replication issues.\n\nWe also deploy code to our staging environment twice a week, which means that any regressions surface before a new packaged release.\n\n### Prove that Geo can be deployed as part of our production infrastructure\nA large amount of automation is required to run GitLab.com with millions of users, and our SRE team is constantly improving how we run GitLab.com. The first step bringing Geo into our production environment is to deploy Geo as a part of our staging environment. Without the right monitoring, runbooks, and processes in place, it would not be possible to move Geo into production where it could be used to enable geo-replication and/or as part of our disaster recovery strategy.\n\n## Setting up Geo on staging\n\nSetting up Geo on staging had some unique challenges, you can get a detailed overview in our [Geo on staging documentation](/handbook/engineering/development/enablement/systems/geo/staging.html).\n\nIn order to deploy Geo, we opted for a minimally viable approach that is sufficient for a first iteration. Geo is currently deployed as a single all-in-one box, not yet as a [Geo high-availability configuration](https://docs.gitlab.com/ee/administration/geo/replication/multiple_servers.html). Geo deploys happen automatically via Chef, similar to any other part of the infrastructure.\n\n![Geo staging Diagram](https://about.gitlab.com/images/blogimages/geo-on-staging/geo_staging_diagram.png){: .shadow.medium.center}\n\nWe currently replicate only a subset of data using [Geo's selective synchronization feature](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization), which also allows us to dogfood this feature. Selective synchronization uses a number of complex database queries and this helps us validate those at scale. We chose to replicate the `gitlab-org` group, which contains mostly of GitLab's projects (including [GitLab](https://gitlab.com/gitlab-org/gitlab) itself).\n\nWe also needed to configure Geo to use the same logical [Gitaly shards](https://docs.gitlab.com/ee/administration/repository_storage_paths.html) on the secondary compared to the primary node. We'll [improve our Geo documentation](https://gitlab.com/gitlab-org/gitlab/-/issues/213840) to ensure it is clear when this is required.\n\nA logical Gitaly shard is an entry in the GitLab configuration file that points to a path on the file system and a Gitaly address:\n\n```\n\"git_data_dirs\": {\n  \"default\": {\n    \"path\": \"/var/opt/gitlab/git-data-file01\",\n    \"gitaly_address\": \"unix:/var/opt/gitlab/gitaly/gitaly.socket\"\n  }\n}\n```\n\nIn the example above, we have only one logical shard identified by the key `default`, but we could have as many as needed.\nEvery project on GitLab is associated with a logical Gitaly shard, which means that we know where all relevant data (repositories, uploads, etc.) is stored. A project `example` that is associated with the logical Gitaly shard `default`, would therefore be stored at `/var/opt/gitlab/git-data-file01` and the Gitaly server would be available at `/var/opt/gitlab/git-data-file01`.\n\nThis information is stored in the PostgreSQL database and in order for Geo to replicate projects successfully we needed to create the same Gitaly shard layout. On the Geo secondary node, we are using only one physical shard to store the data for all projects. To allow it to replicate any project from the primary node, we had to point all the logical Gitaly shards to the same physical shard on the secondary node.\n\nGeo on staging is configured to use [cascading streaming replication](https://www.postgresql.org/docs/current/warm-standby.html#CASCADING-REPLICATION), which allows one standby node in the staging [Patroni cluster](https://github.com/zalando/patroni) to act as relay and stream write-ahead logs (WAL) to the Geo secondary. This setup also has the advantage that Geo can't put an additional load onto the primary database node and we are also not using physical replication slots to further reduce the load. [Patroni will likely be supported in Omnibus packages](https://gitlab.com/groups/gitlab-org/-/epics/2588) and we will review these settings to allow our customers to benefit from this setup.\n\nPostgreSQL will automatically fall back on its `restore_command` to pull archived WAL segments using [wal-e](https://github.com/wal-e/wal-e), if it cannot retrieve the segment by streaming replication. This can happen after a failover, or if the replication target has deleted the relevant segment if Geo is lagging behind it.\n\nIn the future, we will use this to experiment with [high-availability configurations of PostgreSQL on a secondary Geo node](https://gitlab.com/groups/gitlab-org/-/epics/2536).\n\n## What we learned and how we can improve\n\nWe opened [23 issues before successfully rolling out Geo on our staging environment](https://gitlab.com/groups/gitlab-org/-/epics/1908) - this is too many. We know that installing and configuring Geo in complex environments is time-consuming and error-prone, and is an area where we can improve. The current process for a self-managed installation requires [more than 70 individual steps](https://gitlab.com/gitlab-org/gitlab-design/issues/731) - this is too much. [Geo should be simple to install](https://gitlab.com/groups/gitlab-org/-/epics/1465) and we aim to reduce the number of steps to below 10. Using Geo ourselves really underscored the importance of improvements in this area.\n\n### Some Geo PostgreSQL queries don't perform well\n\nGeo uses PostgreSQL Foreign Data Wrappers (FDW) to perform some cross-database queries between the secondary replica and the tracking database. FDW queries are quite elegant but have lead to some issues in the past. Specifically, staging is still running PostgreSQL 9.6, and Geo benefits from some FDW improvements available only in PostgreSQL 10 and later, such as join push-down and aggregate push-down.\n\nWhile enabling Geo on staging, some FDW queries timed out during the backfill phase. Until staging is being upgraded to a newer version of PostgreSQL, increasing the statement timeout to 20 minutes on the Geo secondary node was sufficient to allow us to proceed with the backfill.\n\nAs a direct consequence of enabling GitLab on staging, we are working to [improve Geo scalability by simplifying backfill operations](https://gitlab.com/groups/gitlab-org/-/epics/2851), eliminating these cross-database queries, and removing the FDW requirement. We also plan to [upgrade to PostgreSQL 11 in GitLab 13.0](https://gitlab.com/groups/gitlab-org/-/epics/2414).\n\n### Bug fixes\nWe've also discovered and fixed a number of bugs in the process, such as [failing to synchronize uploads with missing mount points](https://gitlab.com/gitlab-org/gitlab/-/issues/209752), [invalid ActiveRecord operations](https://gitlab.com/gitlab-org/gitlab/-/issues/210589), and [excessively re-synchronizing files in some situations](https://gitlab.com/gitlab-org/gitlab/-/issues/207808).\n\n## What's next?\nWe are already providing value to our customers by enabling Geo on staging because the Geo team can test and validate Geo at scale at lot easier. Next up is enabling [automatic runs of our end-to-end test on staging](https://gitlab.com/gitlab-org/quality/team-tasks/issues/385), which would reduce the manual testing burden even further. There are also some other improvements, such as [enabling high-availability configurations of PostgreSQL using Patroni on Geo nodes](https://gitlab.com/groups/gitlab-org/-/epics/2536) that we would like to test on staging.\n\nEven though enabling Geo on staging is already very useful, it is just a step forward to rolling out Geo on GitLab.com in production. We are currently evaluating the business case for enabling Geo on GitLab.com as part of our disaster recovery strategy and for geo replication.\n\nCover image by [Donald Giannatti](https://unsplash.com/photos/4qk3nQI3WHY) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[9,680,1021],{"slug":2476,"featured":6,"template":683},"geo-is-available-on-staging-for-gitlab-com","content:en-us:blog:geo-is-available-on-staging-for-gitlab-com.yml","Geo Is Available On Staging For Gitlab Com","en-us/blog/geo-is-available-on-staging-for-gitlab-com.yml","en-us/blog/geo-is-available-on-staging-for-gitlab-com",{"_path":2482,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2483,"content":2489,"config":2495,"_id":2497,"_type":13,"title":2498,"_source":15,"_file":2499,"_stem":2500,"_extension":18},"/en-us/blog/get-ready-for-new-gitlab-web-ide",{"title":2484,"description":2485,"ogTitle":2484,"ogDescription":2485,"noIndex":6,"ogImage":2486,"ogUrl":2487,"ogSiteName":670,"ogType":671,"canonicalUrls":2487,"schema":2488},"A first look at the new GitLab Web IDE and remote development experience","The next-generation GitLab Web IDE, available to everyone, will enable faster and more efficient contributions right from your browser.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682545/Blog/Hero%20Images/navin-beta-unsplash.jpg","https://about.gitlab.com/blog/get-ready-for-new-gitlab-web-ide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A first look at the new GitLab Web IDE and remote development experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Schurter\"}],\n        \"datePublished\": \"2022-12-15\",\n      }",{"title":2484,"description":2485,"authors":2490,"heroImage":2486,"date":2492,"body":2493,"category":298,"tags":2494},[2491],"Eric Schurter","2022-12-15","\n\nA little while back I wrote about the [future of the GitLab Web IDE](/blog/the-future-of-the-gitlab-web-ide/) and our decision to [rebuild the Web IDE](https://gitlab.com/groups/gitlab-org/-/epics/7683) on top of the open source VS Code project. Our goal: To make it simple for anyone and everyone to contribute, regardless of their development experience. Today, I am happy to announce that we are preparing to launch the new Web IDE experience as a beta, **available to everyone, and enabled by default on GitLab.com.** \n\nDevelopers and non-developers alike need to be able to contribute from anywhere, across multiple projects, and without context switching or the need to manage a local development environment. The new Web IDE is more user-friendly and efficient, combining VS Code's powerful core features with significantly improved performance and the ability to securely connect to a remote development environment directly from the Web IDE.\n\n## Start using the Web IDE Beta December 19\n\nI know you're excited to try it. We've been using it internally and it's fantastic. If you use GitLab.com, expect to see the Web IDE Beta available on December 19, 2022. There's nothing else you have to do, nothing to install, and no configuration necessary. After the launch, the Web IDE Beta will be the default experience across GitLab.\n\n![Screenshot of welcome screen](https://about.gitlab.com/images/blogimages/web-ide-images/ide-welcome-screen.png){: .shadow}\n\n### Available in 15.7 for self-managed users\nFor self-managed users, you'll get the Web IDE Beta as part of the GitLab 15.7 release, which will be available December 22, 2022. It will be behind a [feature flag](https://docs.gitlab.com/ee/user/project/web_ide_beta/index.html#enable-the-web-ide-beta) that admins can enable on an instance-level. \n\n## What can you expect with the new Web IDE? \n\nThe Web IDE Beta introduces a number of new features and improvements over the previous Web IDE, including the following: \n\n- A flexible and customizable interface with collapsible panels and custom themes\n\n![Screenshot of Web IDE interface](https://about.gitlab.com/images/blogimages/web-ide-images/ide-interface.png){: .shadow}\n\n- Contextual actions and drag & drop support in the file panel\n\n![Screenshot of file panel](https://about.gitlab.com/images/blogimages/web-ide-images/ide-file-panel.png){: .shadow}\n\n- Find and replace across all open files\n\n![Screenshot of find and replace](https://about.gitlab.com/images/blogimages/web-ide-images/ide-find-replace.png){: .shadow}\n\n- An interactive document outline and visual history panel\n- Up to 80% reduction in memory usage over the previous Web IDE\n- Improved reliability of tracking changes to files and directories\n- Better support for touchscreen devices such as tablets and (larger) smartphones\n\nThere's much, much more included in the Web IDE Beta, as you'll soon find out. But there's one more big thing to mention... \n\n## Interactive terminal access with remote development\n\nLast but not least, the beta introduces an entirely new category to GitLab by making it possible to securely connect to a remote development environment, run commands in an interactive terminal panel, and get real-time feedback from right inside the Web IDE. See it in action in this short video: \n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/q_xzzY9GT9c\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nThis is the first feature released as part of our new Remote Development category, with much more planned in the near future. By connecting the Web IDE to a cloud runtime environment, you can unlock the full potential of a web-based IDE without having to manage your own local environment. More information about configuring your remote development environment can be found in our [documentation](https://docs.gitlab.com/ee/user/project/remote_development/) and more details about the Remote Development roadmap can be found on our [direction page](/direction/create/ide/remote_development/). Be on the lookout for a lot more about remote development in the coming months.\n\n## What about the previous Web IDE? \n\nThe Web IDE Beta is ready to handle many of the most frequently performed tasks you could tackle in the existing Web IDE, like committing changes to multiple files and reviewing merge request diffs, but in a much more powerful and familiar interface. We hope you'll enjoy working in the Web IDE Beta as much as we do. \n\nIf there's something missing, or for whatever reason you need to use the previous Web IDE experience, don't worry: We've included a [user preference](https://gitlab.com/-/profile/preferences) that allows you to switch back and forth between the two whenever you want. We'll keep both around until we're out of beta, something we have planned for GitLab 16.0 in May 2023, so you can maximize your efficiency while you adopt the new features. \n\n![Screenshot of user preference](https://about.gitlab.com/images/blogimages/web-ide-images/ide-user-preference.png){: .shadow}\n\n## What's next for the GitLab Web IDE? \n\nOf course, we're not done yet! We will be improving the features you see today and introducing some exciting new features before we come out of beta. We're working on adding support for [VS Code extensions](https://gitlab.com/groups/gitlab-org/-/epics/7685) and [enabling project-wide search](https://gitlab.com/groups/gitlab-org/-/epics/9466), but we are making this beta available to everyone because we want to hear from you. What's the most important missing piece for you? How can we make you more productive in the Web IDE? Let us know in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/385787) and we'll keep iterating!\n\nCover image by [Navin Rai](lhttps://unsplash.com/@nicque) on [Unsplash](https://unsplash.com/photos/EgyIbEB7n8Y?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink)\n{: .note}\n",[9,678,701,894],{"slug":2496,"featured":6,"template":683},"get-ready-for-new-gitlab-web-ide","content:en-us:blog:get-ready-for-new-gitlab-web-ide.yml","Get Ready For New Gitlab Web Ide","en-us/blog/get-ready-for-new-gitlab-web-ide.yml","en-us/blog/get-ready-for-new-gitlab-web-ide",{"_path":2502,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2503,"content":2509,"config":2514,"_id":2516,"_type":13,"title":2517,"_source":15,"_file":2518,"_stem":2519,"_extension":18},"/en-us/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1",{"title":2504,"description":2505,"ogTitle":2504,"ogDescription":2505,"noIndex":6,"ogImage":2506,"ogUrl":2507,"ogSiteName":670,"ogType":671,"canonicalUrls":2507,"schema":2508},"Get to know the security and governance updates in GitLab 17, 17.1","Dive deep into the new enhancements that can strengthen your organization's security posture, including how-to videos for SAST, DAST, API security, container registry, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098858/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098857843.jpg","https://about.gitlab.com/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get to know the security and governance updates in GitLab 17, 17.1\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-07-17\",\n      }",{"title":2504,"description":2505,"authors":2510,"heroImage":2506,"date":2511,"body":2512,"category":704,"tags":2513},[2234],"2024-07-17","With every GitLab release we enhance and optimize security and governance solutions to ensure customers have the tools they need to produce secure and compliant software. Our values of [iteration](https://handbook.gitlab.com/handbook/values/#iteration) and [results for customers](https://handbook.gitlab.com/handbook/values/#results) drive our release cycles, and GitLab 17 is no exception. We have been releasing every month for the past 153 months straight!\n\nIn this article, you'll learn my favorite security and governance enhancements released in GitLab 17 and 17.1 and how they can benefit your organization’s security requirements. \n\n- [SAST analyzer streamlining](#sast-analyzer-streamlining)\n- [Android dependency scanning](#android-dependency-scanning)\n- [Custom roles and granular security permissions updates](#custom-roles-and-granular-security-permissions-updates)\n- [Secret detection updates](#secret-detection-updates)\n- [Container registry updates](#container-registry-updates)\n- [API security scanning updates](#api-security-scanning-updates)\n\n## SAST analyzer streamlining\n\nGitLab provides static application security testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) to examine your source code for known vulnerabilities, detecting vulnerabilities such as SQL injections and cross-site scripting. When SAST kicks off, the programming language used is auto-detected and the appropriate scanner is loaded.\n\nIn GitLab 17, SAST scans the same languages, but now with fewer analyzers, [offering a simpler and more customizable experience](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#streamlined-sast-analyzer-coverage-for-more-languages). Language-specific analyzers have been replaced with GitLab-managed rules in the Semgrep-based analyzer for the following languages:\n\n- C/C++\n- Swift (iOS)\n- Java/Kotlin (Android)\n- Node.js\n- PHP\n- Ruby\n\nHaving one analyzer for many different languages makes configurations and writing rules easier than ever. See the [supported languages and frameworks documentation](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) for more information.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/_80z6mZmzek?si=i9yPQttxuwVcb7Ye\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Android dependency scanning\n\nIn modern software development, many applications are built from multiple dependencies that are best at performing their intended function. For example, rather than writing a YAML parser, a developer will use a library that parses YAML. This allows developers to focus on the main goal of their application, rather than spending time on utility functions.\n\nWhile the use of dependencies speeds up efficiency, they can be difficult to manage and could introduce vulnerabilities to your application. For this, GitLab provides [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), which analyzes dependencies for known vulnerabilities. \n\nMany organizations are using dependencies even when creating native mobile applications. In GitLab 17, we introduced [Android dependency scanning](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#dependency-scanning-support-for-android) to bridge the gap. Android dependency scanning can be easily added as a [CI/CD catalog component](https://gitlab.com/explore/catalog/components/android-dependency-scanning) – just include the following code in your `.gitlab-ci.yml`:\n\n```\ninclude:\n  - component: gitlab.com/components/android-dependency-scanning/component@1.0.0\n    inputs:\n      stage: test\n```\n\nThis job will also generate a CycloneDX software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)) report, which may be necessary for compliance. Make sure to scan your Android dependencies as soon as possible, as there are many CVEs out there.\n\nWatch this video to learn more:\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/_80z6mZmzek?si=DdB7j4NAenl-UcrJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Learn more SBOMs and dependencies with [our ultimate guide to SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/).\n\n## Custom roles and granular security permissions updates\n\nGitLab provides [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html) to allow organizations to create user roles with the precise privileges and permissions to meet their needs. This enables organizations to [implement the principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) to adhere to various compliance standards.\n\n![custom roles screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098874/Blog/Content%20Images/Blog/Content%20Images/1_aHR0cHM6_1750098873857.png)\n\nIn GitLab 17, managing custom roles has become easier than ever. You can now [edit a custom role and its permissions directly from the UI](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#edit-a-custom-role-and-its-permissions), whereas, in the past, the role needed to be recreated. Also, for those using GitLab self-managed, [custom roles are now managed at the instance level](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#manage-custom-roles-at-self-managed-instance-level), allowing administrators to create the roles, and group owners to assign them.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/glvvCoc2hkc?si=dl_SwQ7tyVdzirH5\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThere have also been [several UX improvements](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#ux-improvements-to-custom-roles) added to this feature along with the introduction of the following permissions:\n\n- assign security policy links\n- manage and assign compliance frameworks\n- manage webhooks\n- manage push rules\n- manage merge request settings (17.1)\n- manage integrations (17.1)\n- manage deploy tokens (17.1)\n- read CRM contacts (17.1)\n\nGitLab releases usually include new permissions to further enable the implementation of the principle of least privilege. To learn more about the available granular security permissions, [visit the available custom permission documentation](https://docs.gitlab.com/ee/user/custom_roles/abilities.html).\n\n## Secret detection updates\n\nDevelopers may accidentally commit secrets like keys or API tokens to Git repositories from time to time. After a sensitive value is pushed to a remote repository, anyone with access to the repository can impersonate the authorized user of the secret and cause mayhem. When this occurs the exposed secrets must be revoked and replaced to address this risk, which can cause system downtime.\n\nGitLab provides [secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) to address this risk, and in GitLab 17 it’s gotten even better with the following enhancements:\n\n- [Support for remote rulesets when overriding or disabling rules](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#secret-detection-now-supports-remote-rulesets-when-overriding-or-disabling-rules): - Allows you to override or disable rules via a remote configuration. Therefore, you can scale rule configurations across multiple projects using only one [TOML](https://toml.io/en/) file.\n- [Advanced vulnerability tracking](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#introducing-advanced-vulnerability-tracking-for-secret-detection): Detects when the same secret has moved within a file due to refactoring or unrelated changes. This leads to reduced duplicate findings, simplifying vulnerability management.\n\nIn GitLab 17.1, [secret push protection](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#secret-push-protection-available-in-beta) is now in Beta. Secret push protection checks the content of each commit pushed to GitLab. If any secrets are detected, the push is blocked and displays information about the commit. Therefore, a developer does not need to do the extra work of removing and rotating secrets, since they are never committed upstream.\n\n![Push block eue to detected secret](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098874/Blog/Content%20Images/Blog/Content%20Images/2_aHR0cHM6_1750098873858.png)\n\nWhen [push protection occurs](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/), you can see it displays additional information on the commit, including:\n\n- the commit ID that contains the secret\n- the filename and line number that contains the secret\n- the type of secret\n\n**Note:**  [Enabling secret push protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/#enable-secret-push-protection) is as easy as flipping a switch in GitLab Security Configuration.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZNtwXVj3tA8?si=4xJ1rWdThpVjvebv\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Container registry updates\n\nGitLab provides a [built-in container registry](https://docs.gitlab.com/ee/user/packages/container_registry/), making it easy for developers to store and manage container images for each GitLab project without context switching. GitLab 17.1 includes several features to enhance the security and efficiency of using the registry:\n- [Container images linked to signatures](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#container-images-linked-to-signatures): Container images in the registry can now be signed and associated with the signature. This can reduce image tampering by allowing developers to quickly find and validate the signatures that are associated with a container image\n- [Display the last published date for container images](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#display-the-last-published-date-for-container-images): The container registry UI has been updated to include accurate `last_published_at timestamps`, putting critical data at the top of view.\n- [Sort container registry tags by publish date](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#sort-container-registry-tags-by-publish-date): Allows developers to quickly find and validate the most recently published container image.\n\n![Signed container details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098874/Blog/Content%20Images/Blog/Content%20Images/3_aHR0cHM6_1750098873860.png)\n\nAdditionally we’ve introduced [container scanning for the registry](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#container-scanning-for-registry). The container images being used in your application may themselves be based on other container images that contain known vulnerabilities. Since developers heavily make use of the built-in container registry, it is a no-brainer to introduce [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) for the registry.\n\n[Container scanning for the registry](https://docs.gitlab.com/ee/user/application_security/container_scanning/#container-scanning-for-registry) can be easily enabled by flipping a switch in GitLab Security Configuration. Once it’s enabled, whenever a container image is pushed to the container registry in your project, GitLab checks its tag. If the tag is `latest`, then GitLab creates a new pipeline that scans the image and even produces a CycloneDX SBOM.\n\n**Note:** At the moment, a vulnerability scan is only performed when a new advisory is published. We are working to detract all vulnerabilities in the registry itself in future iterations.\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Zuk7Axs-CRw?si=odlgT5HWv_KOnBtq\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## API security scanning updates\n\nWhile SAST does a great job of finding vulnerabilities in static source code, there can still be vulnerabilities present in the running application that cannot be detected in source code, such as broken authentication and security misconfigurations. For these reasons, GitLab provides dynamic application security testing ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)) and [Web API fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/index.html) to help discover bugs and potential security issues that other QA processes may miss. \n\nIn GitLab 17, we’ve introduced [several enhancements](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#api-security-testing-analyzer-updates) to our [dynamic scanners which target Web APIs](https://docs.gitlab.com/ee/user/application_security/api_security_testing/index.html), including:\n- system environment variables are now passed from the CI runner to the custom Python scripts used for certain advanced scenarios (like request signing)\n- API Security containers now run as a non-root user, which improves flexibility and compliance\n- support for servers that only offer TLSv1.3 ciphers, which enables more customers to adopt API security testing.\n- scanner image upgraded to Alpine 3.19, which addresses security vulnerabilities\n\nIn GitLab 17.1, additional configuration variables were added to [API security scanning](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#api-security-testing-analyzer-updates) and [API fuzzing](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#fuzz-testing-analyzer-updates) to allow:\n- creation of a comma-separated list of HTTP success status codes that define whether the job has passed\n- disabling of waiting for the target API to become available before scanning begins\n- specifying the expected status code for the API target availability check\n\nWatch this video to learn more:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/CcyOoBgSPUU?si=hAMQfmUTlLRKhPSg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more about other enhancements\n\nGitLab 17 and 17.1 also introduced several other security and governance features and enhancements, too many to cover in this blog. Some of these features include:\n\n- [Updated filtering on the Vulnerability Report](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#updated-filtering-on-the-vulnerability-report): You can now use the filtered search component to filter the Vulnerability Report by any combination of status, severity, tool, or activity.\n- [Toggle merge request approval policies to fail open or fail closed](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#toggle-merge-request-approval-policies-to-fail-open-or-fail-closed): A new fail open option for merge request approval policies to offer flexibility to teams who want to ease the transition to policy enforcement as they roll out controls in their organization.\n- [Optional configuration for policy bot comment](https://about.gitlab.com/releases/2024/05/16/gitlab-17-0-released/#optional-configuration-for-policy-bot-comment): The security policy bot posts a comment on merge requests when they violate a policy to help users understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them.\n- [Merge request approval policies fail open/closed (policy editor)](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#merge-request-approval-policies-fail-openclosed-policy-editor): Within the policy editor users can now toggle security policies to fail open or fail closed. This enhancement extends the YAML support to allow for simpler configuration within the policy editor view.\n- [Project owners receive expiring access token notifications](https://about.gitlab.com/releases/2024/06/20/gitlab-17-1-released/#project-owners-receive-expiring-access-token-notifications): Both project owners and maintainers with direct membership now receive email notifications when their project access tokens are close to expiring. This helps keep more people informed about upcoming token expiration.\n\nThese are some of the newest security and compliance enhancements provided in GitLab 17 and 17.1 that can be applied to strengthen your organization's security posture! To learn more about GitLab and the other ways we can strengthen your organization's security throughout all parts of the software development lifecycle, check out the following links:\n\n- [GitLab Security and Compliance](https://about.gitlab.com/solutions/security-compliance/)\n- [GitLab Application Security documentation](https://docs.gitlab.com/ee/user/application_security/)\n- [GitLab security and governance overview video](https://youtu.be/Y4RC-SW8Ric)\n- [GitLab Complete DevSecOps demo](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [GitLab Complete DevSecOps tutorial](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/) \n- [Ultimate guide to the principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)\n",[704,701,746,478,9],{"slug":2515,"featured":90,"template":683},"get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1","content:en-us:blog:get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1.yml","Get To Know The Security And Governance Updates In Gitlab 17 17 1","en-us/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1.yml","en-us/blog/get-to-know-the-security-and-governance-updates-in-gitlab-17-17-1",{"_path":2521,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2522,"content":2528,"config":2533,"_id":2535,"_type":13,"title":2536,"_source":15,"_file":2537,"_stem":2538,"_extension":18},"/en-us/blog/getting-started-with-gitlab-how-to-manage-users",{"title":2523,"description":2524,"ogTitle":2523,"ogDescription":2524,"noIndex":6,"ogImage":2525,"ogUrl":2526,"ogSiteName":670,"ogType":671,"canonicalUrls":2526,"schema":2527},"Getting started with GitLab: How to manage users","Learn how to manage users using groups, roles, and permissions. Walk through the setup of secure collaboration with proper project access.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097273/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097273817.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: How to manage users\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-14\",\n      }",{"title":2523,"description":2524,"authors":2529,"heroImage":2525,"date":2530,"body":2531,"category":701,"tags":2532},[1932],"2025-01-14","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nEnsuring a safe, compliant, and collaborative environment starts with the most basic of tasks - managing users. In this tutorial, we show you how to establish project members, assign roles and permissions, and create groups and subgroups.\n\nNote: To follow along with this tutorial, you should have a GitLab account either through GitLab.com or your organization's self-managed instance. If you need help, visit our fundamentals area on [GitLab University](https://university.gitlab.com/).\n\nLet's get started.\n\nWhen you create GitLab users, they only have access to [their private projects, public projects, and projects set with internal visibility](https://docs.gitlab.com/ee/user/public_access.html). For the purposes of this tutorial, your project is super secret and only invited members should have access to it – at varying permissions settings. To ensure this, you can invite users as [members of the project](https://docs.gitlab.com/ee/user/project/members/).\n\n## Project members\n\n![Project members screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097278487.png)\n\nGitLab users can be invited to a project and [assigned a role](https://docs.gitlab.com/ee/user/permissions.html), which determines what they can do in the project. The owner of a project can delegate administrative tasks to other users as maintainers, who can do almost everything an owner does, aside from changes to a project such as deleting, archiving, or transferring a project.\n\n![Invite members screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097278487.png)\n\n[Maintainers](https://docs.gitlab.com/ee/user/permissions.html#roles) of the project can invite other members as developers who have access to all the features to create, build, and deploy software. Users who are not developers but need project management access can be invited to the project as [planners](https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/), reporters, and guests with varying levels of permissions. These roles can also be used to determine who can make changes to certain branches with [protected branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html).\n\nIf you are working with contractors or your use requires user permissions to expire, you can set an expiry date after which the user loses access to the project. Project members can also be identified as direct or indirect members, based on their [membership type](https://docs.gitlab.com/ee/user/project/members/#membership-types). Direct members are invited directly into the project, whereas indirect members are often inherited from a [GitLab group](https://docs.gitlab.com/ee/user/group/) a project belongs to.\n\nNow, let's look at Group memberships.\n\n## Group memberships\n\nGroups in GitLab can be a top level created at the root of a GitLab instance like the [gitlab.com/gitlab-org](http://gitlab.com/gitlab-org). which is a parent group used to organize other subgroups like [gitlab.com/gitlab-org/charts](http://gitlab.com/gitlab-org/charts). Groups are useful even if you only have one project.\n\nGroups can be used for different reasons:\n\n- organizing similar or related projects  \n- organizing users into groups for better team coordination\n\nWhen using groups to organize users, you can organize teams in groups and [invite a group to a project](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html) with a specific role for an entire team. You can have a `dev` group for the developers of the team, `pm` group for the project managers and `leads` for team leads. When inviting the groups, `dev` can be assigned the Developer role, `pm` the Planner role, and `leads` the Maintainer role. \n\n![Invite a group screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097279/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097278488.png)\n\nMembers of each group can be can be added or removed without needing to update project permissions. This is particularly useful when your team has grown to have several projects. However, it is important to [observe best practices](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html#setting-up-a-group-for-collaboration) for using groups for collaboration.\n\nAnother helpful aspect of having users organized in groups is that you can [mention](https://docs.gitlab.com/ee/user/discussions/#mentions) the entire group in issues, merge requests, or comments, which makes keeping an entire team informed easier.\n\n### Create subgroups\n\n[Subgroups](https://docs.gitlab.com/ee/user/group/subgroups/) can be used to further organize users in a group and you can keep adding subgroups up to 20 nested levels. Users in a subgroup inherit the the permissions they have in a parent group. If you want to grant a user in a subgroup a role higher than what they inherited, you will need to [invite them to the subgroup](https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership) with the new higher role. Note: You can not give them a lower role in the subgroup.\n\n### Manage groups\n\nGroup Owners have several management options to determine how users function in a group. For instance, you can set how a user can request access to a group, enable/disable [group mentions](https://docs.gitlab.com/ee/user/group/manage.html#disable-group-mentions), [restrict access](https://docs.gitlab.com/ee/user/group/manage.html#turn-on-restricted-access), or [moderate users](https://docs.gitlab.com/ee/user/group/moderate_users.html), among other options. An exciting new feature, which is still under development at the time of this article's publication, is the [automatic removal of dormant users](https://docs.gitlab.com/ee/user/group/moderate_users.html#automatically-remove-dormant-members) after a minimum of 90 days and a maximum of five years. This will help keep groups clean and better manage the release of license seats.\n\n## Learn more\n\nManaging users on GitLab depends on your use case. If your organization is larger with more advanced workflows and user management, GitLab provides more advanced ways to [manage enterprise users](https://docs.gitlab.com/ee/user/enterprise_user/index.html). You can also explore more options on how to [manage your organization](https://docs.gitlab.com/ee/topics/set_up_organization.html) and with [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/), you get more granularity and compliance features.\n\n> #### Want to take your learning to the next level? [Sign up for GitLab University courses](https://university.gitlab.com/). Or you can get going right away with [a free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## \"Getting started with GitLab\" series\nRead more articles in our \"Getting started with GitLab\" series:\n\n- [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Understanding CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n- [Working with CI/CD variables](https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables/)\n",[478,9,746,1164,701],{"slug":2534,"featured":90,"template":683},"getting-started-with-gitlab-how-to-manage-users","content:en-us:blog:getting-started-with-gitlab-how-to-manage-users.yml","Getting Started With Gitlab How To Manage Users","en-us/blog/getting-started-with-gitlab-how-to-manage-users.yml","en-us/blog/getting-started-with-gitlab-how-to-manage-users",{"_path":2540,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2541,"content":2547,"config":2552,"_id":2554,"_type":13,"title":2555,"_source":15,"_file":2556,"_stem":2557,"_extension":18},"/en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":2542,"description":2543,"ogTitle":2542,"ogDescription":2543,"noIndex":6,"ogImage":2544,"ogUrl":2545,"ogSiteName":670,"ogType":671,"canonicalUrls":2545,"schema":2546},"Getting started with GitLab: Working with CI/CD variables","Learn what CI/CD variables are, why they are important in DevSecOps, and best practices for utilizing them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with GitLab: Working with CI/CD variables\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-05-27\",\n      }",{"title":2542,"description":2543,"authors":2548,"heroImage":2544,"date":2549,"body":2550,"category":701,"tags":2551},[2094],"2025-05-27","*Welcome to our \"Getting started with GitLab\" series, where we help newcomers get familiar with the GitLab DevSecOps platform.*\n\nIn an earlier article, we explored [GitLab CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/). Now, let's dive deeper into the world of **CI/CD variables** and unlock their full potential.\n\n### What are CI/CD variables?\n\nCI/CD variables are dynamic key-value pairs that you can define at different levels within your GitLab environment (e.g., project, group, or instance). These variables act as placeholders for values that you can use in your `.gitlab-ci.yml` file to customize your pipelines, securely store sensitive information, and make your CI/CD configuration more maintainable.\n\n### Why are CI/CD variables important?\n\nCI/CD variables offer numerous benefits:\n\n* **Flexibility** - Easily adapt your pipelines to different environments, configurations, or deployment targets without modifying your core CI/CD script.  \n* **Security** - Securely store sensitive information like API keys, passwords, and tokens, preventing them from being exposed directly in your code.  \n* **Maintainability** - Keep your CI/CD configuration clean and organized by centralizing values in variables, making updates and modifications easier.  \n* **Reusability** - Define variables once and reuse them across multiple projects, promoting consistency and reducing duplication.\n\n### Scopes of CI/CD variables: Project, group, and instance\n\nGitLab allows you to define CI/CD variables with different scopes, controlling their visibility and accessibility:\n\n* **Project-level variables** - These variables are specific to a single project and are ideal for storing project-specific settings, such as:\n  * Deployment URLs: Define different URLs for staging and production environments.  \n  * Database credentials: Store database connection details for testing or deployment.  \n  * Feature flags: Enable or disable features during different stages of your pipeline.  \n  * Example: You have a project called \"MyWebApp\" and want to store the production deployment URL. You create a project-level variable named `DPROD_DEPLOY_URL` with the value `https://mywebapp.com`.  \n* **Group-level variables** - These variables are shared across all projects within a GitLab group. They are useful for settings that are common to multiple projects, such as:\n\n  * API keys for shared services: Store API keys for services like AWS, Google Cloud, or Docker Hub that are used by multiple projects within the group.  \n  * Global configuration settings: Define common configuration parameters that apply to all projects in the group.  \n  * Example: You have a group called \"Web Apps\" and want to store an API key for Docker Hub. You create a group-level variable named `DOCKER_HUB_API_KEY` with the corresponding API key value.  \n* **Instance-level variables** - These variables are available to all projects on a GitLab instance. They are typically used for global settings that apply across an entire organization such as:\n\n  * Default runner registration token: Provide a default token for registering new [runners](https://docs.gitlab.com/runner/).  \n  * License information: Store license keys for GitLab features or third-party tools.  \n  * Global environment settings: Define environment variables that should be available to all projects.  \n  * Example: You want to set a default Docker image for all projects on your GitLab instance. You create an instance-level variable named `DEFAULT_DOCKER_IMAGE` with the value `ubuntu:latest`.\n\n### Defining CI/CD variables\n\nTo define a CI/CD variable:\n\n1. Click on the **Settings > CI/CD** buttons for  your project, group, or instance.  \n2. Go to the **Variables** section.  \n3. Click **Add variable**.  \n4. Enter the **key** (e.g., `API_KEY`) and **value**.  \n5. Optionally, check the **Protect variable** box for sensitive information. This ensures that the variable is only available to pipelines running on protected branches or tags.  \n6. Optionally, check the **Mask variable** box to hide the variable's value from job logs, preventing accidental exposure.  \n7. Click **Save variable**.\n\n### Using CI/CD variables\n\nTo use a CI/CD variable in your `.gitlab-ci.yml` file, simply prefix the variable name with `$`:\n\n```yaml\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n### Predefined CI/CD variables\n\nGitLab provides a set of [predefined CI/CD variables](https://docs.gitlab.com/ci/variables/predefined_variables/) that you can use in your pipelines. These variables provide information about the current pipeline, job, project, and more.\n\nSome commonly used predefined variables include:\n\n* `$CI_COMMIT_SHA`: The commit SHA of the current pipeline.  \n* `$CI_PROJECT_DIR`: The directory where the project is cloned.  \n* `$CI_PIPELINE_ID`: The ID of the current pipeline.  \n* `$CI_ENVIRONMENT_NAME`: The name of the environment being deployed to (if applicable).\n\n### Best practices\n\n* Securely manage sensitive variables: Use protected and masked variables for API keys, passwords, and other sensitive information.  \n* Avoid hardcoding values: Use variables to store configuration values, making your pipelines more flexible and maintainable.  \n* Organize your variables: Use descriptive names and group related variables together for better organization.  \n* Use the appropriate scope: Choose the correct scope (project, group, or instance) for your variables based on their intended use and visibility.\n\n### Unlock the power of variables\n\nCI/CD variables are a powerful tool for customizing and securing your GitLab pipelines. By mastering variables and understanding their different scopes, you can create more flexible, maintainable, and efficient workflows.\n\nWe hope you found it helpful and are now well-equipped to leverage the power of GitLab for your development projects.\n\n> Get started with CI/CD variables today with a [free, 60-day trial of GitLab Ultimate with Duo Enterprise](https://about.gitlab.com/free-trial/).\n\n## \"Getting Started with GitLab\" series\nRead more articles in our \"Getting Started with GitLab\" series:\n\n- [How to manage users](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users/)\n-  [How to import your projects to GitLab](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Mastering project management](https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automating Agile workflows with the gitlab-triage gem](https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Understanding CI/CD](https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd/)\n",[701,746,1396,1397,108,9],{"slug":2553,"featured":90,"template":683},"getting-started-with-gitlab-working-with-ci-cd-variables","content:en-us:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","en-us/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":2559,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2560,"content":2566,"config":2571,"_id":2573,"_type":13,"title":2574,"_source":15,"_file":2575,"_stem":2576,"_extension":18},"/en-us/blog/getting-started-with-value-streams-dashboard",{"title":2561,"description":2562,"ogTitle":2561,"ogDescription":2562,"noIndex":6,"ogImage":2563,"ogUrl":2564,"ogSiteName":670,"ogType":671,"canonicalUrls":2564,"schema":2565},"Getting started with the new GitLab Value Streams Dashboard","Benchmark your value stream lifecycle, DORA, and vulnerabilities metrics to gain valuable insights and uncover patterns for continuous improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671793/Blog/Hero%20Images/16_0-cover-image.png","https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Getting started with the new GitLab Value Streams Dashboard\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2023-06-12\",\n      }",{"title":2561,"description":2562,"authors":2567,"heroImage":2563,"date":2568,"body":2569,"category":849,"tags":2570},[2014],"2023-06-12","\n\n\u003Ci>This is part two of our multipart series introducing you to the capabilities within GitLab Value Stream Management and the Value Streams Dashboard. In part one, [learn about the Total Time Chart](https://about.gitlab.com/blog/value-stream-total-time-chart/) and how to simplify top-down optimization flow with Value Stream Management.\u003C/i>\n\nGetting started with GitLab [Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html), a customizable dashboard that enables decision-makers to identify trends, patterns, and opportunities for digital transformation improvements, is easy. If you're already using GitLab Value Stream Management, simply navigate to your project's or group's Analytics tab, and within [Value stream analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#view-value-stream-analytics), click on the \"Value Streams Dashboard - DORA\" link. This will open a new page with the Value Streams Dashboard.\n\n![image of DORA Metrics console](https://about.gitlab.com/images/blogimages/vsdCover.png){: .shadow}\nDORA metrics comparison panel\n{: .note.text-center}\n\nGitLab Value Stream Management allows customers to visualize their end-to-end DevSecOps workstreams, manage their software development processes, and gain insight into how digital transformation and technological investments are delivering value and driving business results. GitLab Value Stream Management is able to do this because GitLab provides an entire DevOps platform as a single application and, therefore, holds all the data needed to provide end-to-end visibility throughout the entire software development lifecycle. So now your decisions rely on actual data rather than blind estimation or gut feelings. Additionally, because GitLab is the place where work happens, GitLab Value Stream Management insights are also actionable, allowing your users to move from \"understanding\" to \"fixing\" at any time, from within their workflow and without losing context.\n\nThe centralized UI in Value Streams Dashboard acts as the single source of truth (SSOT), where all stakeholders can access and view the same set of metrics that are relevant to the organization. The SSOT views ensure consistency, eliminate discrepancies, and provide a reliable and unified source of data for decision-making and analysis.\n\nThe first iteration of the GitLab Value Streams Dashboard was focused on enabling teams to continuously improve software delivery workflows by benchmarking [value stream lifecycle metrics, DORA metrics, and vulnerabilities metrics](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports). One of the key features is a new DevSecOps metrics comparison panel that displays the metrics for a group or project in the month-to-date, last month, the month before, and the past 180 days.\n\nThis comparison enables managers to track team improvements in the context of the other DevSecOps metrics to find patterns or trends over time. The data is presented in a clear and concise manner, ensuring that you can quickly grasp the significance of the metrics.\n\n![The Value Streams Dashboard helps you get a high-level custom view over multiple DevOps metrics and understand whether they are improving month-over-month](https://about.gitlab.com/images/blogimages/2023-05-18_vsd_1.gif){: .shadow}\nValue Streams Dashboard metrics comparison panel\n{: .note.text-center}\n\nAdditionally, from each metric you can drill down to a detailed report to investigate the underlying data, understand what is affecting the team performance, and identify actionable insights.\n\nWe understand that every organization has its own set of subgroups and projects, each with specific processes and terminology. That's why we designed our dashboard to be flexible and adaptable. Users have the power to [customize](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#customize-the-dashboard-panels) their dashboard by including panels from different subgroups or projects. \n\nTracking and comparing these metrics over a period of time helps teams catch downward trends early, drill down into individual projects/metrics, take remedial actions to maintain their software delivery performance, and track progress of their innovation investments. Value Streams Dashboard's intuitive interface reduces the learning curve and eliminates the need for extensive training. Everyone can now immediately leverage the platform's unified data store power, maximizing their productivity and saving precious time and resources.\n\n## Value Streams Dashboard roadmap\nWe are just getting started with delivering new capabilities in our Value Streams Dashboard. The roadmap includes planned features and functionality that will continue to improve decision-making and operational efficiencies.\n\nSome of the capabilities we plan to focus on next include:\n\n- adding an [executive-level summary](https://gitlab.com/groups/gitlab-org/-/epics/9558) of key metrics related to software performance and flow of value across the organization\n- adding a [\"DORA Performers score\"](https://gitlab.com/groups/gitlab-org/-/epics/10416) panel with the DORA metrics health from all the organization's groups and projects\n- adding [filter by label to the comparison panel](https://gitlab.com/gitlab-org/gitlab/-/issues/388890) - we recognize that every team does not follow the same flow so we are adding them to slice and dice the dashboard views with GitLab labels as filters\n\nTo help us improve the Value Stream Management Dashboard, please share feedback about your experience in this [survey](https://gitlab.fra1.qualtrics.com/jfe/form/SV_50guMGNU2HhLeT4).\n\n## Learn more\n* Find out what's next on the [Value Stream Management direction page](https://about.gitlab.com/direction/plan/value_stream_management/#whats-next-and-why).\n\n* Learn how to use the new dashboard using the [Value Streams Dashboard documentation](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html).\n\n* Watch this short video on Value Streams Dashboards:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/EA9Sbks27g4\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nCheck out part three of this multipart series: \"[GitLab's 3 steps to optimizing software value streams](https://about.gitlab.com/blog/three-steps-to-optimize-software-value-streams/)\".\n\n\u003Ci>Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\u003C/i>\n",[746,9,2018,894,1164],{"slug":2572,"featured":6,"template":683},"getting-started-with-value-streams-dashboard","content:en-us:blog:getting-started-with-value-streams-dashboard.yml","Getting Started With Value Streams Dashboard","en-us/blog/getting-started-with-value-streams-dashboard.yml","en-us/blog/getting-started-with-value-streams-dashboard",{"_path":2578,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2579,"content":2584,"config":2590,"_id":2592,"_type":13,"title":2593,"_source":15,"_file":2594,"_stem":2595,"_extension":18},"/en-us/blog/gitlab-account-security",{"title":2580,"description":2581,"ogTitle":2580,"ogDescription":2581,"noIndex":6,"ogImage":1948,"ogUrl":2582,"ogSiteName":670,"ogType":671,"canonicalUrls":2582,"schema":2583},"GitLab account security: Verify your information for enhanced protection","GitLab users soon will be required to provide a valid email address during login to boost security and prevent credential stuffing.","https://about.gitlab.com/blog/gitlab-account-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab account security: Verify your information for enhanced protection\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jensen Stava\"}],\n        \"datePublished\": \"2023-08-08\",\n      }",{"title":2580,"description":2581,"authors":2585,"heroImage":1948,"date":2587,"body":2588,"category":678,"tags":2589},[2586],"Jensen Stava","2023-08-08","\n\nOur priority at GitLab is to ensure the highest level of security for your accounts and protect your valuable information. As part of our commitment to your security, we will now require users who are not registered with two-factor authentication ([2FA](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html)) to confirm a valid email address during login. Users will be prompted to confirm a code sent to their email if their login attempt meets specific high-risk criteria. This security update will be implemented on August 16, 2023.\n\n### Why we are making this change\nThe rise of cyber threats, such as [credential stuffing](https://www.techtarget.com/whatis/definition/credential-stuffing), has prompted us to take proactive measures to safeguard your accounts. By requiring a valid email address during login, we can effectively verify user identities and add an extra layer of protection against unauthorized access.\n\n### Confirmation process for non-2FA users\nFor users who have not yet registered with 2FA, a brief verification process may follow a login attempt. After entering your username and password, you will be prompted to enter a code sent to your email address. This step ensures that GitLab upholds the highest standards for account security.\n\n![Confirmation prompt](https://about.gitlab.com/images/blogimages/confirmationprompt.png)\n\n\n### Empowering users with one-time email address update\nTo facilitate this security update, we have introduced a special feature the first time verification is required August 16, 2023. Users will have the option to update their email address once to a valid and active email address. This flexibility enables you to provide the most relevant email address for future logins.\n\n![Verification form](https://about.gitlab.com/images/blogimages/validationform.png)\n\n\n### Maintaining a valid email address\nOnce you have updated your email address, it is crucial to maintain a valid email address linked to your account moving forward. This will ensure seamless logins in the future.\n\n### Your security matters most\nAt GitLab, we are wholly committed to providing you with a secure and reliable user experience. This update reflects our ongoing dedication to protecting your accounts and preserving the trust you place in us.\n",[678,701,9,704],{"slug":2591,"featured":6,"template":683},"gitlab-account-security","content:en-us:blog:gitlab-account-security.yml","Gitlab Account Security","en-us/blog/gitlab-account-security.yml","en-us/blog/gitlab-account-security",{"_path":2597,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2598,"content":2604,"config":2610,"_id":2612,"_type":13,"title":2613,"_source":15,"_file":2614,"_stem":2615,"_extension":18},"/en-us/blog/gitlab-advanced-sast-is-now-generally-available",{"title":2599,"description":2600,"ogTitle":2599,"ogDescription":2600,"noIndex":6,"ogImage":2601,"ogUrl":2602,"ogSiteName":670,"ogType":671,"canonicalUrls":2602,"schema":2603},"GitLab Advanced SAST is now generally available","Reduce false positives, shorten remediation time, and improve development velocity with a proprietary solution built into GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665917/Blog/Hero%20Images/blog-advanced-sast-creative-imagery-0390-1800x945-fy25.png","https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Advanced SAST is now generally available\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"},{\"@type\":\"Person\",\"name\":\"Connor Gilbert\"}],\n        \"datePublished\": \"2024-09-19\",\n      }",{"title":2599,"description":2600,"authors":2605,"heroImage":2601,"date":2607,"body":2608,"category":704,"tags":2609},[698,2606],"Connor Gilbert","2024-09-19","We’re excited to announce that our Advanced Static Application Security Testing (SAST) scanner is now generally available for all GitLab Ultimate customers. \n\nAdvanced SAST is a new scanner powered by the technology we [acquired from Oxeye](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/) earlier this year. It uses a proprietary detection engine with rules informed by in-house security research to identify exploitable vulnerabilities in first-party code. It delivers more accurate results so developers and security teams don’t have to sort through the noise of false-positive results.\n\nUnlike other stand-alone security scanners, Advanced SAST is natively built into the GitLab DevSecOps platform, providing a developer experience free from the overhead that comes with integrating multiple point solutions. Using taint analysis, relevant context is surfaced to help developers remediate vulnerabilities within their existing workflow to maximize development velocity and application security. \n\nThis new scanner will work alongside our existing platform capabilities so developers and application security (AppSec) teams have the most comprehensive set of tools to ship more secure software, faster. \n\n## Applications are being developed faster but remain vulnerable \n\nThe pace of application development continues to accelerate, but remains a common attack vector for threat actors. Our recent [Global DevSecOps Report](https://about.gitlab.com/developer-survey/) found that 66% of companies are releasing software twice as fast — or faster — than in previous years, as businesses strive to deliver more value to their customers than competitors.\n\nHowever, speed introduces risk. Last year alone, [80% of the top data breaches](https://www.crowdstrike.com/2024-state-of-application-security-report/) stemmed from attacks at the application layer.\n\nThese two data points paint a clear picture: Application security tools must be built into existing developer workflows so businesses can stay competitive and secure. \n\n## What are SAST and Advanced SAST?  \n\nSAST is a [widely adopted method for improving application security](https://about.gitlab.com/developer-survey/) by scanning first-party source code to identify vulnerabilities, such as SQL injections or cross-site scripting, before they reach production. Unlike its dynamic counterpart, [DAST](https://about.gitlab.com/topics/devsecops/sast-vs-dast/), SAST scans code without executing it and is performed early in the software development lifecycle (SDLC). This proactive approach integrates security into the development process from the outset, significantly lowering the risk of future breaches.\n\n> Check out this [step-by-step tutorial](https://about.gitlab.com/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai/) to put Advanced SAST to work in your environment.\n\n### Fewer false positives with contextual remediation\n\nThe integration of Oxeye’s technology into our platform means we’re able to provide a SAST solution AppSec teams can trust, built into the same GitLab platform developers love. Here’s how we’re able to do that and what it means for our customers: \n\n**Less time triaging vulnerabilities and more time launching features** \n* Our proprietary detection engine uses cross-function, cross-file taint analysis with rules informed by in-house security research to surface truly exploitable vulnerabilities and improve scan accuracy — that means lower false-positive rates. \n\n**Faster remediation with richer context** \n* Advanced SAST helps developers remediate security vulnerabilities by providing important context such as threat details and the path a vulnerability takes through a program. And, it’s integrated with [GitLab Duo Enterprise AI](https://about.gitlab.com/gitlab-duo/) to help developers understand and resolve vulnerabilities faster. AppSec teams can also scale their expertise by integrating third-party security training right into the GitLab platform. \n\n**Security built into developer workflows**\n* *Integrated* into the SDLC is not the same as *built* into the SDLC. Advanced SAST is a native component of our platform, ensuring security is incorporated within existing developer workflows. With a unified solution to manage the entire SDLC, developers can identify, prioritize, and remediate vulnerabilities without disrupting their flow.\n\nHere is an example of the findings of an Advanced SAST scan: \n\n![Advanced SAST - code flow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675850/Blog/Content%20Images/code-flow_dark-mode__1_.png)\n\n## What to know about the Advanced SAST rollout\nIf you’re already using GitLab SAST, we want to ensure you have the chance to coordinate the rollout of Advanced SAST.\n\nHere are key points:\n* Advanced SAST scanning is available in GitLab 17.3 or newer, but it’s disabled by default so you can choose when to make the switch. You can [enable Advanced SAST](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#configuration) for [the languages it supports](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#supported-languages) across projects, groups, or your entire instance.\n* GitLab 17.4 includes helpful features that make it easier to switch to Advanced SAST, including a new [vulnerability code flow view](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-code-flow) and automatic translation from existing vulnerability records.\n* We plan to enable Advanced SAST by default in a future release, no later than GitLab 18.0. We’ll announce the final timeline and details soon.\n\nFor the latest updates on how to upgrade to Advanced SAST, check the [Advanced SAST documentation](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html). We also have a walkthrough in the video below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xDa1MHOcyn8?si=2zVY_rRSu1wpHP__\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## What’s next for SAST  \nLooking ahead, we’re already working on [new features and improvements](https://about.gitlab.com/direction/secure/static-analysis/sast/) to help teams write more secure software together, faster. We’re particularly focused on:\n\n* **Upgrading more languages to Advanced SAST**, like PHP, Ruby, C, and C++, so more teams can benefit from more accurate vulnerability findings and cross-file, cross-function scanning.\n* **Real-time SAST scanning in the IDE**, so developers can write more secure code as they’re programming – before they even commit or push.\n* **Incremental scanning**, analyzing only modified code so developers can quickly identify vulnerabilities without waiting on full-repository scans. \n\n> If you’re an existing GitLab Ultimate customer and would like to learn more about how Advanced SAST can help improve your application security program, visit our [Advanced SAST documentation](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html) where we cover implementation requirements, use cases, and more.  \n\n***Disclaimer:** This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.*\n",[704,678,9,703,701],{"slug":2611,"featured":90,"template":683},"gitlab-advanced-sast-is-now-generally-available","content:en-us:blog:gitlab-advanced-sast-is-now-generally-available.yml","Gitlab Advanced Sast Is Now Generally Available","en-us/blog/gitlab-advanced-sast-is-now-generally-available.yml","en-us/blog/gitlab-advanced-sast-is-now-generally-available",{"_path":2617,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2618,"content":2624,"config":2630,"_id":2632,"_type":13,"title":2633,"_source":15,"_file":2634,"_stem":2635,"_extension":18},"/en-us/blog/gitlab-ai-assisted-features",{"title":2619,"description":2620,"ogTitle":2619,"ogDescription":2620,"noIndex":6,"ogImage":2621,"ogUrl":2622,"ogSiteName":670,"ogType":671,"canonicalUrls":2622,"schema":2623},"GitLab details AI-assisted features in the DevSecOps platform","In a fireside chat, CEO and co-founder Sid Sijbrandij shared demos of AI-assisted features available today in gitlab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669077/Blog/Hero%20Images/ai-fireside-chat.png","https://about.gitlab.com/blog/gitlab-ai-assisted-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab details AI-assisted features in the DevSecOps platform\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n        \"datePublished\": \"2023-05-03\",\n      }",{"title":2619,"description":2620,"authors":2625,"heroImage":2621,"date":2627,"body":2628,"category":806,"tags":2629},[2626],"Sid Sijbrandij","2023-05-03","\nThis morning, GitLab’s Chief Financial Officer Brian Robins and I led a fireside chat focused on [GitLab’s AI strategy](https://ir.gitlab.com/news-releases/news-release-details/gitlab-hold-ai-fireside-chat-sid-sijbrandij), AI’s role in solving customer pain points, and our AI product roadmap.\n\nAI marks a big industry shift that will make it easier to develop, secure, and operate software. We plan to infuse AI throughout the software development lifecycle by incorporating it into our comprehensive enterprise DevSecOps platform.\n\nWe will lead with a customer-centric approach focused on privacy first, where customers know their intellectual property is secured. One way we are accomplishing this is with [our recently announced generative AI partnership with Google](https://about.gitlab.com/press/releases/2023-05-02-gitLab-and-google-cloud-partner-to-expand-ai-assisted-capabilities.html). This will allow GitLab to use Google's generative AI foundation models to provide customers with AI-powered offerings within our cloud infrastructure. We’ll maintain our commitment to protecting user privacy by containing customer intellectual property and source code within GitLab's cloud infrastructure.\n\nWatch the AI fireside chat:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/ejWeMdVz8Nk\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen>\u003C/iframe>\n\n\u003C/figure>\n\u003C!-- blank line -->\n\nDuring the fireside chat, we introduced AI-assisted features available to GitLab customers today on gitlab.com. We provided a live demo of these capabilities that can be utilized by everyone throughout the software development lifecycle. \n\n![List of AI-assisted capabilities](https://about.gitlab.com/images/blogimages/ai-assisted-capabilities-detailed.png){: .shadow}\n\nWe also discussed how these capabilities are focused on three personas: development, security and operations teams, and have features available for all users. Watch the demos for these capabilities available on gitlab.com today:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube-nocookie.com/embed/ILJeqWoVswM\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## AI for Developer Teams \n\n### Code Suggestions\n- Enables developers to write code more efficiently by viewing code suggestions as they type. \nLearn more about [Code Suggestions](/blog/ai-assisted-code-suggestions/).\n\n### Suggested Reviewers\n- Helps customers receive faster and higher quality reviews by automatically finding the right people to review a merge request.\nLearn more about [Suggested Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/data_usage.html).\n\n### Summarize MR Changes\n- Helps merge request authors to drive alignment and action by efficiently communicating the impact of their changes.\nLearn more about [Summarize MR Changes](/blog/merge-request-changes-summary-ai/).\n\n### Summarize My MR Review\n- Enables better handoffs between authors and reviewers and helps reviewers efficiently understand many merge request suggestions. \nLearn more about [Summarize My MR Review](/blog/summarize-my-merge-request-review/).\n\n## AI for Security and Operations\n\n### Explain This Vulnerability\n- Helps developers remediate vulnerabilities more efficiently and uplevel their skills, enabling them to write more secure code.\nLearn more about [Explain This Vulnerability](/blog/explain-this-vulnerability/).\n\n### Generate Tests in MRs\n- Automates repetitive tasks for developers and helps them catch bugs early.\nLearn more about [Generate Tests in MRs](/blog/merge-request-suggest-a-test/).\n\n### Explain This Code\n- Allows DevSecOps teams to get up to speed quickly on code.\nLearn more about [Explain This Code](/blog/explain-this-code/).\n\n## AI for everyone\n\n### Issue Comment Summaries\n- Quickly gets everyone up to speed on lengthy conversations to ensure they are all on the same page.\nLearn more about [Issue Comment Summaries](/blog/summarize-issues/).\n\n### GitLab Chat\n- Helps quickly identify useful information in large volumes like documentation.\nLearn more about [GitLab Chat](https://gitlab.com/groups/gitlab-org/-/epics/10220).\n\n### Value Stream Forecasting\n- Predicts productivity metrics and identifies anomalies across your software development lifecycle.\nLearn more about [Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/).\n\nThese are just the beginning of many features we have in the works leveraging generative AI to provide our customers [AI-assisted features](/topics/devops/the-role-of-ai-in-devops/) across our DevSecOps platform. With our value of iteration at the heart of our work, we are actively improving all the capabilities we announced today as well as introducing new capabilities. [AI is in all we do](/company/yearlies/#fy24-yearlies) and we intend to ship many capabilities throughout the year as they become ready.  \n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)",[678,9,786,703],{"slug":2631,"featured":6,"template":683},"gitlab-ai-assisted-features","content:en-us:blog:gitlab-ai-assisted-features.yml","Gitlab Ai Assisted Features","en-us/blog/gitlab-ai-assisted-features.yml","en-us/blog/gitlab-ai-assisted-features",{"_path":2637,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2638,"content":2644,"config":2651,"_id":2653,"_type":13,"title":2654,"_source":15,"_file":2655,"_stem":2656,"_extension":18},"/en-us/blog/gitlab-ai-cicd-customization-toolkit",{"title":2639,"description":2640,"ogTitle":2639,"ogDescription":2640,"noIndex":6,"ogImage":2641,"ogUrl":2642,"ogSiteName":670,"ogType":671,"canonicalUrls":2642,"schema":2643},"GitLab AI, CI/CD and customization for secure scaled growth","Find out how the latest developments for the GitLab AI-powered DevSecOps Platform help organizations scale to enterprise levels.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679194/Blog/Hero%20Images/duo-blog-post.png","https://about.gitlab.com/blog/gitlab-ai-cicd-customization-toolkit","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Drive secure growth at scale: Your GitLab AI, CI/CD, and customization toolkit\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Flouton\"}],\n        \"datePublished\": \"2023-10-31\",\n      }",{"title":2645,"description":2640,"authors":2646,"heroImage":2641,"date":2648,"body":2649,"category":806,"tags":2650},"Drive secure growth at scale: Your GitLab AI, CI/CD, and customization toolkit",[2647],"Mike Flouton","2023-10-31","\nScaling up to enterprise-level intensifies the demand for rapid, secure software delivery. Large organizations can easily fall into the trap of single-function silos, making collaboration tricky and slowing development. Over the past few months, we've introduced new capabilities for the GitLab AI-powered DevSecOps Platform to help teams address these hurdles, accelerate innovation, ensure compliance, and fortify their digital defenses.\n- [AI capabilities that reshape speed and security](#ai-capabilities-that-reshape-speed-and-security)\n- [A single, enterprise-ready DevSecOps platform](#a-single-enterprise-ready-devsecops-platform) \n- [A customizable solution that fits the way you work](#a-customizable-solution-that-fits-the-way-you-work)\n\nLet’s take a closer look at what we've been working on and how these advancements benefit growing organizations.\n\n> Bring the best practices of industry leaders to your team. Join GitLab and Nasdaq for an exciting discussion about AI, DevSecOps, and developer productivity. [Register for this webinar today!](https://page.gitlab.com/webcast-fy24q3-devsecops-ai-developer-productivity.html)\n\n## AI capabilities that reshape speed and security\nAI will transform the way organizations develop software. Our [State of AI in Software Development](https://about.gitlab.com/developer-survey/#ai) report, released earlier this year, demonstrates this: 83% of DevSecOps professionals surveyed said implementing AI in their software development processes is essential to avoid falling behind competitors. \n\n[GitLab Duo](https://about.gitlab.com/gitlab-duo/) is a powerful set of AI capabilities within GitLab’s DevSecOps Platform that helps to speed up development of code, improve operations, and secure software. Since its debut in June, we’ve been steadily expanding the suite of AI capabilities. These now extend across the entire software development lifecycle – from suggesting code, to finding and explaining vulnerabilities in code, to identifying appropriate code reviewers. As enterprises increase code generation, they can avoid potential bottlenecks, such as security checks, further downstream.\n\nFor example, we recently released our [GitLab Duo Vulnerability Explanation feature into Beta](https://about.gitlab.com/blog/remediating-vulnerabilities-with-insights-and-ai/). Typically, vulnerability discovery and mitigation would require a significant amount of back-and-forth between development and application security teams to agree on severity levels and approaches to fix the vulnerability. Vulnerability Explanation alleviates this inefficiency by summarizing detected vulnerabilities and their implications as well as providing in-depth solutions and suggested mitigation within the developer’s workflow, enabling faster resolution and creation of safer code within the development workflow. \n\n![GitLab Duo Vulnerability Explanation](https://about.gitlab.com/images/blogimages/2023-08-31-solving-vulnerabilities-with-insights-and-ai/ai_explain_this_vulnerability_results.png)\n\n\nFor even more efficiency, [GitLab Duo Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/) (Beta) helps developers create new code and update existing code faster. [GitLab Duo Suggested Reviewers](https://about.gitlab.com/blog/gitlab-duo-suggested-reviewers/) (generally available to all users) helps teams make an informed decision when choosing reviewers that can meet their review criteria.\n\nLearn about [all GitLab Duo capabilities](https://about.gitlab.com/gitlab-duo/).\n\nWatch GitLab Duo capabilities in action.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/LifJdU3Qagw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n## A single, enterprise-ready DevSecOps platform \nEnterprise needs from a software delivery platform are unique. A DevSecOps platform must support the ability to:\n- build for speed with adequate security guardrails right from the start\n- consolidate to a single platform, but still integrate with your existing solution\n- simply adopt and onboard developers, but handle the complexity of scale\n\nGitLab CI/CD is a core way for organizations to meet these requirements. As customers scale their adoption of GitLab, they run millions of CI/CD jobs on a monthly basis. With the efficiency improvements further driven by GitLab Duo, these numbers will likely increase. However, organizations will need to find efficiency opportunities throughout their development and deployment workflows to be able to handle this growth, ensuring that whatever is deploying into production meets their quality, security, and reliability standards.\n\nThe [GitLab CI/CD Component Catalog](https://about.gitlab.com/blog/introducing-ci-components/), which will soon be released into Beta, solves these problems by enabling organizations to standardize their pipelines and create building blocks in a centralized repository that can be easily discovered, reused, and shared across teams. Enterprises can develop base pipeline configurations with the proper compliance, quality, and security checks already built-in for use across their organization. \n\nHere are some more capabilities aimed at improving the enterprise platform experience:\n- The GitLab Runner ecosystem continues to expand as we've recently introduced [GitLab SaaS runners on MacOS](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/#macos-13-ventura-image-for-saas-runners-on-macos), [xlarge and 2xlarge SaaS Runners on Linux](https://about.gitlab.com/releases/2023/08/22/gitlab-16-3-released/#more-powerful-gitlab-saas-runners-on-linux), [increased storage on medium and large SaaS Runners on Linux](https://about.gitlab.com/releases/2023/06/22/gitlab-16-1-released/#increased-storage-for-gitlab-saas-runners-on-linux), and [GPU-enabled SaaS Runners on Linux](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#gpu-enabled-saas-runners-on-linux) for supporting data science workloads.\n- GitLab Duo, which was previously only available for GitLab SaaS, is now extended to GitLab self-hosted. Enterprises that prefer to self-host or must self-host due to compliance and regulatory restrictions can now take advantage of our AI features, starting with [Code Suggestions](https://about.gitlab.com/blog/self-managed-support-for-code-suggestions/).\n- Organizations looking at using GitLab Packages as their consolidated package registry can now [import packages](https://docs.gitlab.com/ee/user/packages/package_registry/supported_functionality.html#importing-packages-from-other-repositories) from their current package registries like Maven Central or Artifactory. GitLab [supports importing](https://docs.gitlab.com/ee/user/packages/package_registry/supported_functionality.html#importing-packages-from-other-repositories) Maven, npm, NuGet, and PyPI package types into GitLab, with many more package formats to follow. \n\n## A customizable solution that fits the way you work\nAs companies grow, there is an increasing need to personalize development and deployment settings and provide distinct visibility into the DevSecOps lifecycle to users beyond the immediate DevSecOps teams. GitLab is designed to function effectively with minimal adjustments, yet it offers the flexibility to be tailored to the requirements of expanding organizations. \n\nOur recent developments, including [changes to product navigation](https://about.gitlab.com/blog/navigation-research-blog-post/), are driven by comprehensive user research. We recognize that each organization and its individual users have unique, preferred workflows. Our updated navigation features, such as pinning frequently accessed items, visualizing work, and simplifying navigation through fewer top-level items, empower DevSecOps teams to align the platform with their optimal environment and workflow.\n\nWatch the new and simplified navigation in action.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/rGTl9_HIpbY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\nHere are some other highlights:\n- In addition to overhauling the navigation, we [introduced the rich text editor](https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/#all-new-rich-text-editor-experience) by providing a “what you see is what you get” editing experience. The rich text editor is now available in all issues, epics, and merge requests.\n- GitLab offers [six out-of-the-box roles](https://docs.gitlab.com/ee/user/permissions.html#roles), but for many enterprises this was not enough. Some roles gave too much permission, while others didn’t grant enough permissions to complete a task. Enterprises needed a way to define their own roles – leading to [customizable roles](https://docs.gitlab.com/ee/user/custom_roles.html), which gives GitLab administrators the ability to define roles with granular permissions suited for their needs.\n- GitLab Value Streams Dashboard ensures that all stakeholders have visibility into the progress and value delivery metrics associated with software development and delivery. To align with customers’ needs to customize the data viewed and the appearance, we introduced [new velocity metrics](https://about.gitlab.com/releases/2023/08/22/gitlab-16-3-released/#new-velocity-metrics-in-the-value-streams-dashboard) and the ability to [customize the appearance and data](https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/#new-customization-layer-for-the-value-streams-dashboard) to adjust metrics based on their areas of interest, filter out irrelevant information, and focus on the data that is most relevant to their analysis or decision-making process.\n\n![New velocity metrics in the Value Streams Dashboard](https://about.gitlab.com/images/16_3/16.3_vsd.mr_iss.png)\n\n\n## The enterprise awaits — get growing today\t\nOrganizations on a growth trajectory need a way to sustain that growth. They'll need to leverage the capabilities of AI to generate code faster — but they can't sacrifice quality or security. Organizations will also need to set standards for development and deployment that extend across the enterprise, and every user will need a clear and customizable view of the DevSecOps lifecycle. As we bring new capabilities into the GitLab DevSecOps Platform, we will continue to support these enterprise-class needs.\n\n> Bring the best practices of industry leaders to your team. Join GitLab and Nasdaq for an exciting discussion about AI, DevSecOps, and developer productivity. [Register for this webinar today!](https://page.gitlab.com/webcast-fy24q3-devsecops-ai-developer-productivity.html)\n\n\n**Disclaimer:** This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\n",[701,108,786,9],{"slug":2652,"featured":6,"template":683},"gitlab-ai-cicd-customization-toolkit","content:en-us:blog:gitlab-ai-cicd-customization-toolkit.yml","Gitlab Ai Cicd Customization Toolkit","en-us/blog/gitlab-ai-cicd-customization-toolkit.yml","en-us/blog/gitlab-ai-cicd-customization-toolkit",{"_path":2658,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2659,"content":2665,"config":2672,"_id":2674,"_type":13,"title":2675,"_source":15,"_file":2676,"_stem":2677,"_extension":18},"/en-us/blog/gitlab-auto-devops-in-action",{"title":2660,"description":2661,"ogTitle":2660,"ogDescription":2661,"noIndex":6,"ogImage":2662,"ogUrl":2663,"ogSiteName":670,"ogType":671,"canonicalUrls":2663,"schema":2664},"GitLab Auto DevOps in action","See how the only single application for the entire DevOps lifecycle helps you deliver better software, faster.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664015/Blog/Hero%20Images/laptop.jpg","https://about.gitlab.com/blog/gitlab-auto-devops-in-action","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Auto DevOps in action\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n        \"datePublished\": \"2018-08-10\",\n      }",{"title":2660,"description":2661,"authors":2666,"heroImage":2662,"date":2668,"body":2669,"category":849,"tags":2670},[2667],"Aricka Flowers","2018-08-10","\n\nBetter and faster. These two words best describe the production goals of the IT leaders and engineers building today’s cutting-edge software. And GitLab [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) can help them hit those goals while improving their overall business outcomes.\n\nAs the only single application for the complete [DevOps](/topics/devops/) lifecycle, GitLab Auto DevOps gives development teams all the tools they need to deliver secure, high-quality software at previously unattainable speeds. The secret sauce that makes Auto DevOps so effective is the way it automatically sets up the required integrations and pipeline needed to get your software out of the door faster. With Auto DevOps, your code is automatically tested for quality, scanned for security vulnerabilities and licensing issues, packaged and then set up for monitoring and deployment, leaving engineers with time to place more attention on creating a better product.\n\nThis may all make sense in theory, but as they say, a picture is worth 1,000 words. And it is [rumored](https://idearocketanimation.com/4293-video-worth-1-million-words/?) that video is worth 1.8 million words. With that being said, why not take a look at GitLab Auto DevOps in action? \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4Uo_QP9rSGM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWant to learn more about GitLab Auto DevOps? Check out our [documentation](https://docs.gitlab.com/ee/topics/autodevops/), [feature](https://docs.gitlab.com/ee/topics/autodevops/) and [product vision](/direction/) pages.\n\n\nCover photo by [Ash Edmonds](https://unsplash.com/photos/Koxa-GX_5zs) on [Unsplash](https://unsplash.com/)\n{: .note}\n\n",[851,680,1124,894,704,2671,9],"production",{"slug":2673,"featured":6,"template":683},"gitlab-auto-devops-in-action","content:en-us:blog:gitlab-auto-devops-in-action.yml","Gitlab Auto Devops In Action","en-us/blog/gitlab-auto-devops-in-action.yml","en-us/blog/gitlab-auto-devops-in-action",{"_path":2679,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2680,"content":2685,"config":2690,"_id":2692,"_type":13,"title":2693,"_source":15,"_file":2694,"_stem":2695,"_extension":18},"/en-us/blog/gitlab-chat-ai",{"title":2681,"description":2682,"ogTitle":2681,"ogDescription":2682,"noIndex":6,"ogImage":906,"ogUrl":2683,"ogSiteName":670,"ogType":671,"canonicalUrls":2683,"schema":2684},"ML experiment: Use a chatbot to answer how-to questions","Learn how GitLab is experimenting with a docs chatbot that you can ask product questions in this latest installment of our ongoing 'AI/ML in DevSecOps' series.","https://about.gitlab.com/blog/gitlab-chat-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Use a chatbot to answer how-to questions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Waldner\"}],\n        \"datePublished\": \"2023-05-04\",\n      }",{"title":2681,"description":2682,"authors":2686,"heroImage":906,"date":2687,"body":2688,"category":806,"tags":2689},[2294],"2023-05-04","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nAt GitLab, [everyone can contribute](/company/mission/). As a platform, GitLab offers a wide variety of features, but it is hard to know everything GitLab is capable of without diligently combing through our documentation, testing out our features, or talking to someone at GitLab who can answer your questions. Reading documentation can send users down a rabbit hole and they may not get their question answered. This can lead to time spent with support, meetings with the Customer Success team, going back and forth with a solutions architect, coordinating with technical account managers, and maybe opting for some professional services hours. What if users had access to all the knowledge they needed at their fingertips 24/7 and could get their complex questions answered immediately?\n        \nIn an experimental feature, the [Global Search team](/handbook/engineering/development/enablement/data_stores/search/) used AI to create a chatbot that answers how-to questions about the GitLab product. It will respond with an explanation and relevant links to our documentation.   \n\n![GitLab Chat answering a simple question](https://about.gitlab.com/images/blogimages/gitlab_chat.gif){: .shadow}\n\nGetting answers on how-to questions while in the product eliminates time lost to context switching. The chat interface overlays the GitLab UI, which enables you to interface with a virtual expert alongside your work. This is especially helpful when you are involved in a complex multi-step task like setting up a gitlab-ci.yml file, configuring security policies, or editing a CODEOWNERS file.\n\nGitLab chat will answer any question that you would utilize our product documentation to answer. It also provides helpful links if the bot's response is not as detailed as you needed - the full documentation is just one click away.\n\n## Be part of our AI-assisted features journey\n\nThis experiment is just the start of the ways we're looking to infuse GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI Assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":2691,"featured":6,"template":683},"gitlab-chat-ai","content:en-us:blog:gitlab-chat-ai.yml","Gitlab Chat Ai","en-us/blog/gitlab-chat-ai.yml","en-us/blog/gitlab-chat-ai",{"_path":2697,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2698,"content":2704,"config":2709,"_id":2711,"_type":13,"title":2712,"_source":15,"_file":2713,"_stem":2714,"_extension":18},"/en-us/blog/gitlab-ci-cd-features-improvements",{"title":2699,"description":2700,"ogTitle":2699,"ogDescription":2700,"noIndex":6,"ogImage":2701,"ogUrl":2702,"ogSiteName":670,"ogType":671,"canonicalUrls":2702,"schema":2703},"GitLab CI/CD's 2018 highlights","We move quickly, always with an eye to the future, but let's take a moment to look back on how GitLab CI/CD has evolved in the past six months.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663779/Blog/Hero%20Images/cicd-2018_blogimage.jpg","https://about.gitlab.com/blog/gitlab-ci-cd-features-improvements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab CI/CD's 2018 highlights\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-01-21\",\n      }",{"title":2699,"description":2700,"authors":2705,"heroImage":2701,"date":2706,"body":2707,"category":298,"tags":2708},[846],"2019-01-21","\nHello everyone, and happy New Year! For those who don't know me, my name is [Jason Yavorska](/company/team/#jyavorska) and I've been the product manager of GitLab CI/CD since around the middle of last year. 2018 was a big year for CI/CD improvements in GitLab, and I'm so proud of our team and what we've been able to deliver in partnership with you, our users. Even just looking back on the last six months of improvements, we've delivered a ton of changes that move our vision for CI/CD forward, address important asks from our users, and build the foundation for an amazing 2019.\n\nBelow are a few of the highlights from my time here so far; be sure to let me know in the comments if I missed something that meant a lot to you.\n\n## Access control for GitLab Pages\n\nOne of the most amazing things about working for an open core company like GitLab is that our community of users can play an outsized role in how our product grows and develops, thanks to their always impressive contributions. Last year we introduced [Access control for Pages (11.5)](https://gitlab.com/gitlab-org/gitlab-ce/issues/33422), a feature with 304 👍 that was actually part of our 2019 vision, and was built thanks to a significant community contribution from MVP [Tuomo Ala-Vannesluoma](https://gitlab.com/tuomoa).\n\nThis was not just a great feature, but also highlights how GitLab and community contributors can work together to do amazing things. It came out shortly after I joined as a new product manager here, and it really opened my eyes to the possibilities inherent in working together transparently and openly with our user community. Now I don't think I could ever go back to any other way of working.\n\n## Feature flags\n\nI'm always looking for ways to expand our horizons and bring more great capabilities into the CI/CD space, and the team achieved that last year with [Allow users to create and manage feature flags for their applications (11.4)](https://gitlab.com/gitlab-org/gitlab-ee/issues/6220). A major piece of our 2018 vision, feature flags are so important to continuous delivery workflows since they allow you to safely isolate delivering your code to production, from the moment users engage with it, giving you more control and better options when it comes to how and when you deliver software.\n\n![CI/CD feature flags](https://about.gitlab.com/images/blogimages/cicd-feature_flags.png){: .shadow.medium.center}\n\n## Pipelines for merge requests\n\nSometimes, what you do in one year may be valuable on its own, but it also helps establish a foundation for more in the future. A common request from the community last year had been to make pipelines more aware of merge requests, so that at runtime, information such as the target branch, merge request name and ID, and other information was available to the pipeline. In 2018 we introduced [`only/except: merge_requests` for merge request pipelines (11.6)](https://gitlab.com/gitlab-org/gitlab-ce/issues/15310), which created this linkage. One great way to take advantage of this feature already is to use it to only create [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) on merge requests, helping to save money on environments versus creating them for every pipeline.\n\nPerhaps even more exciting than this feature on its own, is that it will continue to evolve and grow into the ability to [Run a pipeline on what the merged result will be](https://gitlab.com/gitlab-org/gitlab-ee/issues/7380). I can already say with confidence that this will be a game changer for teams that want to prioritize keeping their `master` branch green. As far as predicting the future outside of GitLab, I'm still accepting merge requests for that 😉\n\n![pipelines for merge requests](https://about.gitlab.com/images/blogimages/cicd-mr_pipelines.png){: .shadow.medium.center}\n\n## Usability improvements for the merge request widget\n\nSpeaking of merge requests, in general the team has made a lot of improvements to how the merge request widget interacts with CI/CD. We added [JUnit XML Test Summary (11.2)](https://gitlab.com/gitlab-org/gitlab-ce/issues/45318), part of our 2018 vision to make testing a more interactive part of the CI pipeline. We also now [Show enhanced information on running deploys (11.5)](https://gitlab.com/gitlab-org/gitlab-ce/issues/25140), and [Link directly to changed pages in Review App (11.5)](https://gitlab.com/gitlab-org/gitlab-ce/issues/33418), which uses [Route Maps](https://docs.gitlab.com/ee/ci/environments/index.html#go-directly-from-source-files-to-public-pages-on-the-environment) to send you directly to the updated content. Both of these changes were welcome improvements that made it much easier to see what was going on, all in one place.\n\n![CI/CD review app link](https://about.gitlab.com/images/blogimages/cicd-reviewapp_link.png){: .shadow.medium.center}\n\n## #movingtogitlab\n\n[#movingtogitlab](https://twitter.com/hashtag/movingtogitlab?src=hash) was an exciting movement in 2018, and I wanted to ensure a great experience for everyone checking us out, even if they were just trying out GitLab CI or other features, and still using GitHub for repositories. One of the challenges that people ran into early on was the way status checks were named by GitLab CI, which didn't play nicely with the way GitHub expected them to work. The team was able to introduce [Name status checks consistently to support GitHub-integrated CI workflow (11.5)](https://gitlab.com/gitlab-org/gitlab-ce/issues/53902) as a change to unblock this, ensuring a valuable experience for everyone, even if you weren't ready to go \"all in\" on GitLab yet.\n\n## Stewardship\n\nHere at GitLab, we take [stewardship of open source](/company/stewardship/) seriously. I was very happy to move the `include:` keyword from paid to free, because I know how important it is for CI/CD users to support proper reuse instead of copy-pasted code. [Move \"include external files in .gitlab-ci.yml\" from Starter to Core (11.4)](https://gitlab.com/gitlab-org/gitlab-ce/issues/42861) (with a grand total of 267 👍 on the issue) achieved this, and opened up new doors, not just for avoiding duplication, but also for more secure ways of implementing common workflows by moving compliance, security, and governance job implementation to a centrally controlled location.\n\n## Honorable mentions\n\nThere wasn't enough time to cover everything in this post without making it a mile long, but there are a few other honorable mentions I want to call out:\n\n- [11.2: Manually stopping environments](https://gitlab.com/gitlab-org/gitlab-ce/issues/25388) (with 245 👍 from our users) added the ability to manually stop your environments, such as review apps, instead of only through pipeline automation.\n- [11.3: Improve handling of includes in `.gitlab-ci.yml` to better enable script reuse/templates](https://gitlab.com/gitlab-org/gitlab-ce/issues/51521) introduced a new way to `extend` your job definitions using templates, including from across different files.\n- [11.4: Run jobs only/except when there are changes for a given path or file](https://gitlab.com/gitlab-org/gitlab-ce/issues/19232) (with a whopping 424 👍) gave you the ability to control whether a job runs or not, based on which files were changed.\n- [11.4: Add support for interactive web terminal to Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/issues/3467) let you connect an interactive to a build/deploy environment and troubleshoot on the live runner host.\n- [11.4: Add timed deployments to AutoDevOps incremental rollouts](https://gitlab.com/gitlab-org/gitlab-ee/issues/7545) enabled new deployment strategies where the rollout was done over time in phases.\n- [11.5: `parallel` job keyword to speed up pipelines](https://gitlab.com/gitlab-org/gitlab-ce/issues/21480) added an easy way to run parallel instances of a job without creating duplicate jobs in your `gitlab-ci.yml`.\n- [11.6: Allow pipelines to be deleted by project owners](https://gitlab.com/gitlab-org/gitlab-ce/issues/41875) (265 👍) gave control over removing old and invalid pipelines, as well as those which may have accidentally included sensitive information in the outputs.\n\n## What's next?\n\nOf course, the mission to improve GitLab CI/CD doesn't stop here. We're bringing [Brendan O'Leary](/company/team/#olearycrew) on board as the full-time product manager for CI (what we call the [Verify stage](/stages-devops-lifecycle/verify/)), freeing me up to focus entirely on CD (what we call [Release](/stages-devops-lifecycle/release/)). We're also significantly growing headcount for the engineering teams supporting us. Having full-time product managers and larger teams dedicated to each of these stages is going to allow us to deliver even more amazing things, even faster.\n\nI've touched on a couple points above, but tried to avoid making this a preview of what's coming for CI/CD in 2019. If you're interested in where Brendan and I are headed, you can visit our direction pages for [Verify (CI)](/direction/verify/) and [Release (CD)](/direction/release/), and feel free to reach out to us directly if you'd like to have a conversation – we'd love to chat about your ideas. Being a transparent, open core company, we also welcome participation in all of our public issues (which you'll find linked to from the above direction pages). For me, the best part of this job is interacting with you, the users of GitLab, so thank you for that opportunity. Here's to another great year of working together to make the job of delivering software fun and rewarding!\n\n## Just one more thing...\n\nI'd be remiss if I didn't mention how great GitLab is as a place to work. If you're interested in joining our all-remote team, we're constantly growing and looking for great PMs and others to join us. Check out [our jobs page](/jobs/) to learn more. I'd encourage you to apply even if you don't see an exact match – GitLab is great at finding the right fit for the right personality, even if that's not exactly listed on our hiring website. If you're really unsure, feel free to reach out to me directly ([@j4yav](https://twitter.com/j4yav)) and I'll help you get in touch with the right person.\n",[1396,266,9,680,1187],{"slug":2710,"featured":6,"template":683},"gitlab-ci-cd-features-improvements","content:en-us:blog:gitlab-ci-cd-features-improvements.yml","Gitlab Ci Cd Features Improvements","en-us/blog/gitlab-ci-cd-features-improvements.yml","en-us/blog/gitlab-ci-cd-features-improvements",{"_path":2716,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2717,"content":2723,"config":2729,"_id":2731,"_type":13,"title":2732,"_source":15,"_file":2733,"_stem":2734,"_extension":18},"/en-us/blog/gitlab-ci-event-workflows",{"title":2718,"description":2719,"ogTitle":2718,"ogDescription":2719,"noIndex":6,"ogImage":2720,"ogUrl":2721,"ogSiteName":670,"ogType":671,"canonicalUrls":2721,"schema":2722},"Event-based CI workflows in GitLab","Learn about a proof of concept to automate more with GitLab CI workflows and share your feedback.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669444/Blog/Hero%20Images/kelly-sikkema-lFtttcsx5Vk-unsplash.jpg","https://about.gitlab.com/blog/gitlab-ci-event-workflows","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Event-based CI workflows in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Grzegorz Bizon\"},{\"@type\":\"Person\",\"name\":\"Jackie Porter\"}],\n        \"datePublished\": \"2022-08-03\",\n      }",{"title":2718,"description":2719,"authors":2724,"heroImage":2720,"date":2726,"body":2727,"category":298,"tags":2728},[2725,1668],"Grzegorz Bizon","2022-08-03","\n\nMaybe you have been in a position where there are specific tasks that must kick off in your software development process based on events in the platform or other systems. Perhaps you are even a GitLab CI user and love the flexibility that pipelines offer for project automation and want to be able to extend this to other types of items. Out of the [July 2022 Verify Stage Hackathon](/blog/verify-week-hackathon/), a proof of concept for CI workflows has been released and we are looking for feedback on ways this feature can help make your life easier. \n\n## What are CI worfklows?\n\nThe idea behind the [proof of concept](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91244) is to instrument an event-based service to trigger pipelines. The current instrumentation features a definition of this service in the `.gitlab-ci.yml` and a hook into the existing [webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html) GitLab provides today. These components make up the `workflow` definition. \n\n## What can CI workflows do?\n\nThe possibilities for CI workflows are endless. If you wanted to triage issues, a workflow can be set on issue creation. Let’s say you want to automatically run pipelines based on merge request state changes - just use a workflow even in `.gitlab-ci.yml` to start a pipeline when a merge request is made “ready” or someone approved your code in it. \n\nHere is a brief overview of the proof of concept in action: \n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/cwfRI9m3rRs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## What’s next?\n\nGitLab CI workflows are one component of a broader [GitLab workflow](https://gitlab.com/groups/gitlab-org/-/epics/8349) and automation goals. Up next, we are looking to [formally instrument CI workflows via GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/363384). We also are looking ahead to [Platform Events](https://gitlab.com/gitlab-org/gitlab/-/issues/355658) or [Cloud Events](https://gitlab.com/gitlab-org/gitlab/-/issues/335095), which help extend the number of events to trigger various automations from beyond the existing webhooks/system hooks. \n\nIs this something that you are interested in or have feedback on? Tag `@dhershkovitch` on our [GitLab CI Workflows Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/363384). \n\nCover image by [Kelly Sikkema](https://unsplash.com/photos/lFtttcsx5Vk) on [Unsplash](https://unsplash.com)\n{: .note}\n",[9,701,1164],{"slug":2730,"featured":6,"template":683},"gitlab-ci-event-workflows","content:en-us:blog:gitlab-ci-event-workflows.yml","Gitlab Ci Event Workflows","en-us/blog/gitlab-ci-event-workflows.yml","en-us/blog/gitlab-ci-event-workflows",{"_path":2736,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2737,"content":2743,"config":2749,"_id":2751,"_type":13,"title":2752,"_source":15,"_file":2753,"_stem":2754,"_extension":18},"/en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized",{"title":2738,"description":2739,"ogTitle":2738,"ogDescription":2739,"noIndex":6,"ogImage":2740,"ogUrl":2741,"ogSiteName":670,"ogType":671,"canonicalUrls":2741,"schema":2742},"GitLab Dedicated for Government now FedRAMP-authorized","Learn how our single-tenant SaaS solution empowers public sector customers to securely accelerate their modernization initiatives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662023/Blog/Hero%20Images/display-dedicated-for-government-article-image-0679-1800x945-fy26.png","https://about.gitlab.com/blog/gitlab-dedicated-for-government-now-fedramp-authorized","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Dedicated for Government now FedRAMP-authorized\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Deepa Mahalingam\"},{\"@type\":\"Person\",\"name\":\"Elisabeth Burrows\"}],\n        \"datePublished\": \"2025-05-19\",\n      }",{"title":2738,"description":2739,"authors":2744,"heroImage":2740,"date":2746,"body":2747,"category":701,"tags":2748},[2745,952],"Deepa Mahalingam","2025-05-19","We're excited to announce that GitLab Dedicated for Government has achieved FedRAMP Authorization at the Moderate Impact Level, marking a significant milestone in our commitment to serving public sector organizations. GitLab Dedicated for Government is now listed as \"Authorized\" on the [FedRAMP Marketplace](https://marketplace.fedramp.gov/products/FR2411959145). Our single-tenant solution provides all the benefits of an enterprise DevSecOps platform with enhanced data residency, isolation, and private networking capabilities to meet the most stringent compliance requirements. GitLab Dedicated for Government provides the flexibility and scalability of a SaaS solution, enabling government agencies to modernize and secure their software supply chain from code to cloud. \n\nThe [Federal Risk and Authorization Management Program](https://www.fedramp.gov/) (FedRAMP) is the gold standard for cloud security across US government agencies. As a mandatory security framework for federal cloud adoption since its 2011 launch, it provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. \n\n## Meeting the growing demand for secure cloud solutions\n\nAs more public sector organizations move away from costly legacy systems and migrate their mission-critical workloads to the cloud, cloud-native development and multi-cloud adoption will grow significantly. At GitLab, we serve a wide variety of customers in the public sector – from federally-funded research and development centers, service providers, and contractors working on behalf of the government, to the largest government agencies across the globe. We understand that no single deployment model will serve the needs of all of our customers. \n\nOur customers have told us they need a SaaS offering that provides additional deployment control and data residency to meet stringent compliance requirements. We see this need with large enterprises and companies in regulated industries that are coming under increased scrutiny, facing global internet policy fragmentation, and dealing with the expanding complexity of data governance. GitLab has consistently observed that security is a top priority for organizations and our [2024 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) showed that this trend continued, with security remaining the primary investment area.\n\nGitLab Dedicated for Government was specifically designed to address these needs – enabling organizations to accelerate their digital transformation initiatives with confidence.\n\n## Key benefits of GitLab Dedicated for Government\n\n**1. Toolchain consolidation**\n\nToolchain management continues to be a significant challenge for DevSecOps teams. According to our 2024 Global DevSecOps Survey, 64% of respondents expressed the need to consolidate their toolchains, with security professionals particularly affected – 63% reported using six or more tools.\n\nThis proliferation of tools results in unnecessary expenditure and introduces complexities and vulnerabilities that increase the risk of cyber attacks. GitLab Dedicated for Government unites DevSecOps teams on a single platform with a unified workflow, eliminating the need to purchase or maintain multiple tools. Organizations can strengthen security, improve efficiency, and accelerate collaboration by consolidating their complex toolchains. Additionally, consolidation supports zero trust architecture implementation by centralizing access control, making it easier to enforce consistent security policies and authentication requirements across the entire development lifecycle. GitLab also enables flexibility by allowing you to utilize existing critical tools through our integration capabilities.\n\n**2. Data residency and protection**\n\nGitLab Dedicated for Government is built on FedRAMP-authorized infrastructure that meets U.S. data sovereignty requirements, including access restricted to U.S. citizens. To further enhance data protection, our solution supports secure, private connections between the customer's virtual private cloud network and GitLab, ensuring users, data, and services have secure access to isolated instances without direct internet exposure. All data is [encrypted at rest](https://docs.gitlab.com/subscriptions/gitlab\\_dedicated/\\#data-encryption) and in transit using the latest encryption standards, with the option to use your own AWS Key Management Service encryption key for data at rest, giving you full control over stored data. GitLab Dedicated for Government also ensures CVEs are patched continuously. It is an ideal platform for teams to build a centralized DevSecOps platform while offboarding compliance burdens to GitLab.\n\n**3. Managed and hosted by GitLab**\n\nOur solution is single-tenant (providing physical isolation from other customers), U.S.-based, privately connected, and fully managed and hosted by GitLab. Organizations can quickly realize the value of a comprehensive DevSecOps platform with the advanced flexibility and customization of a self-managed instance – without requiring staff to build and manage infrastructure.\n\nThis approach delivers all the benefits of GitLab – shorter cycle times, lower costs, stronger security, and more productive developers – with a lower total cost of ownership and quicker time-to-value compared to self-hosting.\n\n**4. Comprehensive native security capabilities**\n\nOur 2024 Global DevSecOps Survey revealed that 60% of public sector security professionals report vulnerabilities are mostly discovered after code is merged into test environments, and only 51% consider their DevSecOps practices mature and well-ingrained. GitLab's comprehensive security scanning capabilities, built into the DevSecOps platform,  provide superior control and protection throughout the entire software development lifecycle, helping public sector organizations address these issues. These features eliminate the need for third-party security tools that could potentially compromise compliance. \n\nFor example, organizations gain access to a complete suite of native security scanners including API Security, Container Scanning, Dynamic Application Security Testing, and Fuzz Testing. This integrated approach ensures federal security standards are met without disrupting development workflows.\n\nWith the GitLab DevSecOps unified platform, public sector organizations avoid the painful scenario of discovering security limitations mid-implementation and having to choose between compromising on security features or implementing non-compliant solutions. \n\n## How to get started with GitLab Dedicated for Government\n\nGitLab Dedicated for Government provides the efficiencies of the cloud combined with infrastructure-level isolation and data residency controls. To learn more about how GitLab Dedicated for Government can help secure your software supply chain, reach out to our [sales team](https://about.gitlab.com/sales/). Whether you are a new customer or looking to migrate from your existing GitLab instance, we will ensure a smooth transition with comprehensive [migration support](https://about.gitlab.com/services/) tailored to your needs. \n\n**Note:** GitLab has also achieved the [Texas Risk and Authorization Management Program Certification](https://dir.texas.gov/resource-library-item/tx-ramp-certified-cloud-products) (TX_RAMP), which allows us to work with Texas state agencies.",[478,9,678,701,183],{"slug":2750,"featured":90,"template":683},"gitlab-dedicated-for-government-now-fedramp-authorized","content:en-us:blog:gitlab-dedicated-for-government-now-fedramp-authorized.yml","Gitlab Dedicated For Government Now Fedramp Authorized","en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized.yml","en-us/blog/gitlab-dedicated-for-government-now-fedramp-authorized",{"_path":2756,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2757,"content":2761,"config":2768,"_id":2770,"_type":13,"title":2771,"_source":15,"_file":2772,"_stem":2773,"_extension":18},"/en-us/blog/gitlab-duo-agent-platform-public-beta",{"noIndex":6,"title":2758,"description":2759,"ogImage":2760},"GitLab Duo Agent Platform goes public beta","Introducing the DevSecOps orchestration platform designed to unlock asynchronous collaboration between developers and AI agents.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg",{"tags":2762,"category":806,"date":2763,"heroImage":2760,"authors":2764,"description":2759,"title":2766,"body":2767},[786,701,9,678],"2025-07-17",[2765],"Bill Staples","GitLab Duo Agent Platform Public Beta: Next-gen AI orchestration and more","**We're building the future of software development.**\n\nAt GitLab, we are [reimagining the future of software engineering](https://about.gitlab.com/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/) as a human and AI collaboration. Where developers focus on solving technical, complex problems and driving innovation, while AI agents handle the routine, repetitive tasks that slow down progress. Where developers are free to explore new ideas in code at much lower cost, bug backlogs are a thing of the past, and users of the software you build enjoy a more usable, reliable, and secure experience. This isn't a distant dream. We're building this reality today, and it is called the GitLab Duo Agent Platform.\n\n## What is GitLab Duo Agent Platform?\n\nGitLab Duo Agent Platform is our next-generation DevSecOps orchestration platform designed to unlock asynchronous collaboration between developers and AI agents. It will transform your development workflow from isolated linear processes into dynamic collaboration where specialized AI agents work alongside you and your team on every stage of the software development lifecycle; it will be like having an unlimited team of colleagues at your disposal.\n\nImagine delegating a complex refactoring task to a Software Developer Agent while simultaneously having a Security Analyst Agent scan for vulnerabilities and a Deep Research Agent analyze progress across your repository history. This all happens in parallel, orchestrated seamlessly within GitLab.\n\nToday, we are announcing the launch of the [first public beta of the GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/agent-platform/) for GitLab.com and self-managed GitLab Premium and Ultimate customers. This is just the first in a series of updates that will improve how software gets planned, built, verified, and deployed as we amplify human ingenuity through intelligent automation.\n\nThis first beta focuses on unlocking the IDE experience through the GitLab VS Code extension and JetBrains IDEs plug-in; next month, we plan on bringing the Duo Agent Platform experience to the GitLab application and expand our IDE support. Let me share a bit more about our vision for the roadmap between now and general availability, planned for later this year. You can find details about the first beta down below.\n\nWatch this video or read on for what's available now and what's to come. Then, if you're ready to get started with Duo Agent Platform, [find out how with the public beta](#get-started-now).\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLab's unique position as an orchestration platform\n\nGitLab sits at the heart of the development lifecycle as the system of record for engineering teams, orchestrating the entire journey from concept to production for over 50 million registered users, including half of the Fortune 500 across geographies. This includes over 10,000 paying customers across all segments and verticals, including public institutions.\n\nThis gives GitLab something no competitor can match: a comprehensive understanding of everything it takes to deliver software. We bring together your project plans, code, test runs, security scans, compliance checks, and CI/CD configurations to not only power your team but also orchestrate collaboration with AI agents you control.\n\nAs an intelligent, unified DevSecOps platform, GitLab stores all of the context about your software engineering practice in one place. We will expose this unified data to AI agents via our knowledge graph. Every agent we build has automatic access to this SDLC-connected data set, providing rich context so agents can make informed recommendations and take actions that adhere to your organizational standards.\n\n**Here's an example of this advantage in action.** Have you ever tried to figure out exactly how a project is going across dozens, if not hundreds, of stories and issues being worked on across all the developers involved? Our Deep Research Agent leverages the GitLab Knowledge Graph and semantic search capabilities to traverse your epic and all related issues, and explore the related codebase and surrounding context. It quickly correlates information across your repositories, merge requests, and deployment history. This delivers critical insights that standalone tools can't match and that would take human developers hours to uncover. \n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Our strategic evolution from AI features to agent orchestration\n\nGitLab Duo started as an add-on, bringing generative AI to developers through Duo Pro and Enterprise. With GitLab 18.0, it's now built into the platform. We've unlocked [Duo Agentic Chat](https://about.gitlab.com/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) and Code Suggestions for all Premium and Ultimate users, and now we're providing immediate access to the Duo Agent Platform.\n\nWe've ramped up engineering investment and are accelerating delivery, with powerful new AI features landing every month. But we're not just building another coding assistant. GitLab Duo is becoming an agent orchestration platform, where you can create, customize, and deploy AI agents that work alongside you and interoperate easily with other systems, dramatically increasing productivity. \n\n> **“GitLab Duo Agent Platform enhances our development workflow with AI that truly understands our codebase and our organization. Having GitLab Duo AI agents embedded in our system of record for code, tests, CI/CD, and the entire software development lifecycle boosts productivity, velocity, and efficiency. The agents have become true collaborators to our teams, and their ability to understand intent, break down problems, and take action frees our developers to tackle the exciting, innovative work they love.”** - Bal Kang, Engineering Platform Lead at NatWest\n\n### Agents that work out of the box\n\nWe are introducing agents that mirror familiar team roles. These agents can search, read, create, and modify existing artifacts across GitLab. Think of these as agents you can interact with individually, that also act as building blocks that you can customize to create your own agents. Like your team members, agents have defined specializations, such as software development, testing, or technical writing. As specialists, they're tapping into the right context and tools to consistently accomplish the same types of tasks, wherever they're deployed.\n\nHere are some of the agents we're building today:\n\n- **Chat Agent (now in beta):** Takes natural language requests to provide information and context to the user. Can perform general development tasks, such as reading issues or code diffs. As an example, you can ask Chat to debug a failed job by providing the job URL.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953504?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-in-web-ui-demo_Update V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n- **Software Developer Agent (now in beta):** Works on assigned items by creating code changes in virtual development environments and opening merge requests for review.\n\n- **Product Planning Agent:** Prioritizes product backlogs, assigns work items to human and agentic team members, and provides project updates over specified timelines.\n\n- **Software Test Engineer Agent:** Tests new code contributions for bugs and validates if reported issues have been resolved. \n\n- **Code Reviewer Agent:** Performs code reviews following team standards, identifies quality and security issues, and can merge code when ready.\n\n- **Platform Engineer Agent:** Monitors GitLab deployments, including GitLab Runners, tracks CI/CD pipeline health, and reports performance issues to human platform engineering teams.\n\n- **Security Analyst Agent:** Finds vulnerabilities within codebases and deployed applications, and implements code and configuration changes to help resolve security weaknesses.\n\n- **Deployment Engineer Agent:** Deploys updates to production, monitors for unusual behavior, and rolls back changes that impact application performance or security.\n\n- **Deep Research Agent:** Conducts comprehensive, multi-source analysis across your entire development ecosystem.\n\nWhat makes these agents powerful is their native access to GitLab's comprehensive toolkit. Today, we have over 25 tools, from issues and epics to merge requests and documentation, with more to come. Unlike external AI tools that operate with limited context, our agents work as true team members with full platform privileges under your supervision.\n\nIn the coming months, you'll also be able to modify these agents to meet the needs of your organization. For example, you'll be able to specify that a Software Test Engineer Agent follows best practices for a particular framework or methodology, deepening its specialization and turning it into an even more valuable team member.\n\n## Flows orchestrate complex agent tasks\n\nOn top of individual agents, we are introducing agent Flows. Think of these as more complex workflows that can include multiple agents with pre-built instructions, steps, and actions for a given task that can run autonomously. \n\nWhile you can create Flows for basic tasks common to individuals, they truly excel when applied to complex, specialized tasks that would normally take hours of coordination and effort to complete. Flows will help you finish complex tasks faster and, in many cases, asynchronously without human intervention.\n\nFlows have specific triggers for execution. Each Flow contains a series of steps, and each step has detailed instructions that tell a specialized agent what to do. This granular approach allows  you to give precise instructions to agents in the Flow. By defining instructions in greater detail and establishing structured decision points, Flows can help solve for the inherent variability in AI responses while eliminating the need to repeatedly specify the same requirements, unlocking more consistent and predictable outcomes without user configuration.\n\nHere are some examples of out-of-the-box Flows that we are building:\n\n- **Software Development Flow (now in beta):** Orchestrates multiple agents to plan, implement, and test code changes end-to-end, helping transform how teams deliver features from concept to production.\n\n- **Issue-to-MR Flow:** Automatically converts issues into actionable merge requests by coordinating agents to analyze requirements, prepare comprehensive implementation plans, and generate code.\n\n- **Convert CI File Flow:** Streamlines migration workflows by having agents analyze existing CI/CD configurations and intelligently convert them to GitLab CI format with full pipeline compatibility.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n- **Search and Replace Flow:** Discovers and transforms code patterns across codebases by systematically analyzing project structures, identifying optimization opportunities, and executing precise replacements.\n\n- **Incident Response & Root Cause Analysis Flow:** Orchestrates incident response by correlating system data, coordinating specialized agents for root cause analysis, and executing approved remediation steps while keeping human stakeholders informed throughout the resolution process.\n\nThis is where GitLab Duo Agent Platform is taking a truly unique approach versus other AI solutions. We won't just give you pre-built agents. We'll also give you the power to create, customize, and share agent Flows that perfectly match your individual and organization's unique needs. And with Flows, you will then be able to give agents a specific execution plan for common and complex tasks.\n\nWe believe this approach is more powerful than building purpose-built agents like our competitors do, because every organization has different workflows, coding standards, security requirements, and business logic. Generic AI tools can't understand your specific context, but GitLab Duo Agent Platform will be able to be tailored to work exactly how your team works.\n\n## Why build agents and agent Flows in the GitLab Duo Agent Platform?\n\n**Build fast.** You can build agents and complex agent Flows in the Duo Agent Platform quickly and easily using a fast, declarative extensibility model and UI assistance.\n\n**Built-in compute.** With Duo Agent Platform, you no longer have to worry about the hassle of standing up your own infrastructure for agents: compute, network, and storage are all built-in.\n\n**SDLC events.** Your agents can be invoked automatically on common events: broken pipeline, failed deployment, issue created, etc.\n\n**Instant access.** You can interact with your agents everywhere in GitLab or our IDE plug-in: assign them issues, @mention them in comments, and chat with them everywhere Duo Chat is available.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**Built-in and custom models supported.** Your agents will have automatic access to all of the models we support, and users will be able to choose specific models for specific tasks. If you want to connect Duo Agent Platform to your own self-hosted model, you will be able to do that too!\n\n**Model Context Protocol (MCP) endpoints.** Every agent and Flow can be accessed or triggered via native MCP endpoints, allowing you to connect to and collaborate with your agents and Flows from anywhere, including popular tools like Claude Code, Cursor, Copilot, and Windsurf.\n\n**Observability and security.** Finally, we provide built-in observability and usage dashboards, so you can see exactly who, where, what, and when agents took actions on your behalf.\n\n## A community-driven future\n\nCommunity contributions have long fueled GitLab's innovation and software development. We're excited to partner with our community with the introduction of the AI Catalog. The AI Catalog will allow you to create and share agents and Flows within your organization and across the GitLab Ecosystem in our upcoming beta.\n\nWe believe that the most valuable AI applications are likely to emerge from you, our community, thanks to your daily application of GitLab Duo Agent Platform to solve numerous real-world use cases. By enabling seamless sharing of agents and Flows, we're creating a network effect where each contribution enhances the platform's collective intelligence and value. Over time, we believe that the most valuable use cases from Agent Platform will come from our thriving GitLab community. \n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## Available today in the GitLab Duo Agent Platform in public beta\n\nThe GitLab Duo Agent Platform public beta is available now to Premium and Ultimate customers with these capabilities:\n\n**Software Development Flow:** Our first Flow orchestrates agents in gathering comprehensive context, clarifying ambiguities with human developers, and executing strategic plans to make precise changes to your codebase and repository. It leverages your entire project, including its structure, codebase, and history, along with additional context like GitLab issues or merge requests to amplify developer productivity.\n\n**New Agent tools available:** Agents now have access to multiple tools to do their work, including:\n\n  - File System (Read, Create, Edit, Find Files, List, Grep)\n  - Execute Command Line*\n  - Issues (List, Get, Get Comments, Edit*, Create*, Add/Update Comments*)\n  - Epics (Get, Get Comments)\n  - MR (Get, Get Comments, Get Diff, Create, Update)\n  - Pipeline (Job Logs, Pipeline Errors)\n  - Project (Get, Get File)\n  - Commits (Get, List, Get Comments, Get Diff)\n  - Search (Issue Search)\n  - Secure (List Vulnerabilities)\n  - Documentation Search\n  \n*=Requires user approval\n\n**GitLab Duo Agentic Chat in the IDE:** Duo Agentic Chat transforms the chat experience from a passive Q&A tool into an active development partner directly in your IDE.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953477?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-ai-launch-video_Updated V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n- **Iterative feedback and chat history:** Duo Agentic Chat now supports chat history and iterative feedback, transforming the agent into a stateful, conversational partner. This fosters trust, enabling developers to delegate more complex tasks and offer corrective guidance.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n- **Streamlined delegation with slash commands:** Expanded, more powerful slash commands, such as /explain, /tests, and /include, create a “delegation language” for quick and precise intent. The /include command allows the explicit injection of context from specific files, open issues, merge requests, or dependencies directly into the agent's working memory, making the agent more powerful and teaching users how to provide optimal context for high-quality responses.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n- **Personalization through custom rules:** New Custom Rules enables developers to tailor agent behavior to individual and team preferences using natural language, for example, development style guides. This foundational mechanism shapes the agent's persona into a personalized assistant, evolving toward specialized agents based on user-defined preferences and organizational policies.\n    \n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n- **Support for GitLab Duo Agentic Chat in JetBrains IDE:** To help meet developers where they work, we have expanded Duo Agentic Chat support to the JetBrains family of IDEs, including IntelliJ, PyCharm, GoLand, and Webstorm. This adds to our existing support for VS Code. Existing users get agentic capabilities automatically, while new users can install the plugin from the JetBrains Marketplace.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n    \n- **MCP client support:** Duo Agentic Chat can now act as an MCP client, connecting to remote and locally running MCP servers. This capability unlocks the agent's ability to connect to systems beyond GitLab like Jira, ServiceNow, and ZenDesk to gather context or take actions. Any service that exposes itself via MCP can now become part of the agent's skill set. The official GitLab MCP Server is coming soon!\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n    \n- **GitLab Duo Agentic Chat in GitLab Web UI.** Duo Agentic Chat is also now available directly within the GitLab Web UI. This pivotal step evolves the agent from a coding assistant to a true DevSecOps agent, as it gains access to rich non-code context, such as issues and merge request discussions, allowing it to understand the \"why\" behind the work. Beyond understanding context, the agent can make changes directly from the WebUI, such as automatically updating issue statuses or editing merge request descriptions.\n\n## Coming soon to GitLab Duo Agent Platform\n\nOver the coming weeks, we'll release new capabilities to Duo Agent Platform, including more out-of-the-box agents and Flows. These will bring the platform into the GitLab experience you love today and enable even greater customization and extensibility, amplifying productivity for our customers:\n\n![GitLab Duo Agent Platform public beta roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform public beta roadmap\")\n\n\n- **Integrated GitLab experience:** Building on the IDE extensions available in 18.2, we're expanding agents and Flows within the GitLab platform. This deeper integration will expand the ways you can collaborate synchronously and asynchronously with agents. You will be able to assign issues directly to agents, @mention them within GitLab Duo Chat, and seamlessly invoke them from anywhere in the application while maintaining MCP connectivity from your developer tool of choice. This native integration transforms agents into true development team members, accessible across GitLab.\n\n- **Agent observability:** As agents become more autonomous, we're building comprehensive visibility into their activity as they progress through Flows, enabling you to monitor their decision-making processes, track execution steps, and understand how they're interpreting and acting on your development challenges. This transparency into agent behavior builds trust and confidence while allowing you to optimize workflows and identify bottlenecks, and helps ensure agents are performing exactly as intended.\n\n- **AI Catalog:** Recognizing that great solutions come from community innovation, we will soon introduce the public beta of our AI Catalog — a marketplace which will allow you to extend Duo Agent Platform with specialized Agents and Flows sourced from GitLab, and over time, the broader community.  You'll be able to quickly deploy these solutions in GitLab, leveraging context across your projects and codebase.\n\n- **Knowledge Graph:** Leveraging GitLab's unique advantage as the system of record for source code and its surrounding context, we're building a comprehensive Knowledge Graph that not only maps files and dependencies across the codebase but also makes that map navigable for users while accelerating AI query times and helping increase accuracy. This foundation enables GitLab Duo agents to quickly understand relationships across your entire development environment, from code dependencies to deployment patterns, unlocking faster and more precise responses to complex questions.\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n- **Create and edit agents and Flows:** Understanding that every organization has unique workflows and requirements, we're developing powerful agent and Flow creation and editing capabilities that will be introduced as the AI Catalog matures. You'll be able to create and modify agents and Flows to operate precisely the way your organization works, delivering deep customization across the Duo Agent Platform that enables higher quality results and increased productivity. \n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n- **Official GitLab MCP Server:** Recognizing that developers work across multiple tools and environments, we're building an official GitLab MCP server that will enable you to access all of your agents and Flows via MCP. You'll be able to connect to and collaborate with your agents and Flows from anywhere MCP is supported, including popular tools like Claude Code, Cursor, Copilot, and Windsurf, unlocking seamless AI collaboration regardless of your preferred development environment.\n\n- **GitLab Duo Agent Platform CLI:** Our upcoming CLI will allow you to invoke agents and trigger Flows on the command line, leveraging GitLab's rich context across the entire software development lifecycle—from code repositories and merge requests to CI/CD pipelines and issue tracking. \n\n## Get started now\n\n- **GitLab Premium and Ultimate customers** in GitLab.com and self-managed environments using GitLab 18.2 can use Duo Agent Platform immediately (beta and experimental features for GitLab Duo [must be enabled](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)). GitLab Dedicated customers will be able to use the Duo Agent Platform with the release of GitLab 18.2 for Dedicated next month.\n\n- Users should download the [VS Code extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) or the [JetBrains IDEs plugin](https://plugins.jetbrains.com/plugin/22857-gitlab) and follow our [guide to using GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat), including Duo Chat [slash commands](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands). \n\n**New to GitLab?** See GitLab Duo Agent Platform in action at our Technical Demo, offered in two timezone-friendly sessions: [Americas and EMEA](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html) and [Asia-Pacific](https://page.gitlab.com/webcasts-jul24-gitlab-duo-agentic-ai-apac.html). To get hands-on with GitLab Duo Agent Platform yourself, sign up for a [free trial](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F) today.\n\n\n\u003Csmall>*This blog post contains “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in the forward-looking statements contained in this blog post are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to be materially different from any future results or outcomes expressed or implied by the forward-looking statements.*\n\n*Further information on risks, uncertainties, and other factors that could cause actual outcomes and results to differ materially from those included in or contemplated by the forward-looking statements contained in this blog post are included under the caption “Risk Factors” and elsewhere in the filings and reports we make with the Securities and Exchange Commission. We do not undertake any obligation to update or release any revisions to any forward-looking statement or to report any events or circumstances after the date of this blog post or to reflect the occurrence of unanticipated events, except as required by law.*\u003C/small>\n",{"featured":90,"template":683,"slug":2769},"gitlab-duo-agent-platform-public-beta","content:en-us:blog:gitlab-duo-agent-platform-public-beta.yml","Gitlab Duo Agent Platform Public Beta","en-us/blog/gitlab-duo-agent-platform-public-beta.yml","en-us/blog/gitlab-duo-agent-platform-public-beta",{"_path":2775,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2776,"content":2782,"config":2787,"_id":2789,"_type":13,"title":2790,"_source":15,"_file":2791,"_stem":2792,"_extension":18},"/en-us/blog/gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements",{"title":2777,"description":2778,"ogTitle":2777,"ogDescription":2778,"noIndex":6,"ogImage":2779,"ogUrl":2780,"ogSiteName":670,"ogType":671,"canonicalUrls":2780,"schema":2781},"GitLab Duo Chat: Get to know productivity-boosting AI enhancements","Learn about Chat's new capabilities, including migration to Claude 3.5 Sonnet, new slash command helpers, and the integration of Root Cause Analysis and Explain Vulnerability features.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098629/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_77JeTV9gAmbXM0224acirV_1750098628882.png","https://about.gitlab.com/blog/gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Chat: Get to know productivity-boosting AI enhancements\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jannik Lehmann\"},{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-10-03\",\n      }",{"title":2777,"description":2778,"authors":2783,"heroImage":2779,"date":2784,"body":2785,"category":806,"tags":2786},[1993,1994],"2024-10-03","At GitLab, we [continuously strive to enhance your experience with GitLab Duo Chat]((https://gitlab.com/gitlab-org/gitlab/-/issues/430124)), our AI-powered assistant designed to streamline your development workflows. In this article, we share a series of significant updates that bring even more power, precision, and functionality to GitLab Duo Chat. \n\n## Migration to Claude 3.5 Sonnet\n\nWe are thrilled to announce a major upgrade for GitLab Duo Chat: [the migration of its underlying Large Language Model from Claude 3 Sonnet to the more advanced Claude 3.5 Sonnet](https://gitlab.com/gitlab-org/gitlab/-/issues/468334). This new model brings substantial performance enhancements, offering superior accuracy, context-awareness, and efficiency in AI-driven conversations.\n\nWith Claude 3.5 Sonnet powering GitLab Duo Chat, users can expect more precise and relevant responses. This upgrade ensures Chat remains at the forefront of AI technology, helping your team work more effectively in their daily workflows.\n\n![Screenshot of Chat in VS Code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098636/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098636137.png)\n\nNotice the [code block syntax highlighting](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1435) in Chat in VS Code.\n\n## Bringing the Slash Command Picker to Chat in the GitLab UI\n\nTo further improve the discovery of GitLab Duo Chat slash commands and make them more quickly accessible to our users, [we’ve introduced the Slash Command Picker UI](https://gitlab.com/gitlab-org/gitlab/-/issues/470703). Now, when you start typing a prompt with `/` in Chat in the GitLab UI, the available slash commands relevant to your current context will be automatically displayed. \n\nThis feature enhances your workflow and acts as the foundation for a growing platform of AI-powered capabilities that we plan to expand in the near future.\n\n![GitLab Duo Chat Slash Command Picker](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098636/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098636138.png)\n\n## Root Cause Analysis integration\n\nGitLab Duo Chat is gaining another powerful feature: [Root Cause Analysis](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#troubleshoot-failed-cicd-jobs-with-root-cause-analysis). \n\nThis integration allows you to maintain context within Chat while investigating failed pipeline jobs, making it easier to ask follow-up questions and explore the root causes of problems.\n\nYou can access Root Cause Analysis by clicking the \"Troubleshoot\" button at the end of the job log, or you can select the job log portions and then ask Chat with the `/troubleshoot` slash command. With this seamless integration, you have the tools you need to resolve issues more efficiently.\n\n![Root Cause Analysis example in Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098636/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098636140.png)\n\n## Fix code in the IDE\n\nOne of the latest enhancements to GitLab Duo Chat is the ability to ask it to [fix selected code](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#fix-code-in-the-ide) within your IDE. This feature, introduced in GitLab 17.3, is available in the Web IDE, VS Code, and JetBrains IDE. It allows you to make specific code fixes by selecting portions of code and using the /fix slash command.\n\nFor example, you can instruct Chat to:\n- Fix grammar mistakes and typos with `/fix grammar mistakes and typos`.\n- Address performance issues using `/fix performance problems`.\n- Solve specific bugs or algorithm-related issues with commands like `/fix duplicate database inserts` or `/fix race conditions`.\n- Resolve code compilation errors with `/fix the build`.\n\nThis feature is designed to help developers quickly resolve common coding issues and improve the quality of their code, all while staying within their familiar IDE environment.\n\nHere is an example for fixing grammar mistakes and improving the language of (code) comments.\n\n![An example for fixing grammar mistakes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098636/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098636142.png)\n\nHere is an example for fixing C code to print the disk usage. Chat correctly suggests missing header includes and provides more help to avoid additional bugs. The source code is available in [the GitLab Duo challenge project](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/fix-c-cli-perf).\n\n![Chat enhancements - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098636/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098636144.png)\n\n## Explain Vulnerability now in GitLab Duo Chat\n\nAnother highly popular AI-powered feature, [Explain Vulnerability, has been integrated into GitLab Duo Chat](https://gitlab.com/groups/gitlab-org/-/epics/13309). This addition allows you to explore vulnerability details in depth while keeping your Chat context intact. You can ask follow-up questions and engage in more comprehensive discussions directly within the chat environment. You can access this feature by viewing a SAST vulnerability in your project’s Vulnerability Report.\n\nCurrently, this feature supports results from SAST scanners, including [Advanced SAST](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html), with plans to extend support to additional scanners soon.\n\n![Sample Vulnerability Report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098636/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098636148.png)\n\n## What's next?\n\nWe're continuously improving GitLab Duo Chat. Some areas we're exploring include:\n- Context is important. We’re prioritizing the integration of [commits](https://gitlab.com/gitlab-org/gitlab/-/issues/468460), [pipeline jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/468461), and [merge requests](https://gitlab.com/gitlab-org/gitlab/-/issues/464587) into Chat’s contextual scope. Additionally, we are looking into [terminal assistance with Chat](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/1423). This expansion will allow Chat to provide more informed and relevant responses based on a broader range of data.\n- Introduce the `/help` slash command. To make navigating Chat’s AI-powered features even more intuitive, we started development on [a /help slash command](https://gitlab.com/gitlab-org/gitlab/-/issues/462122). This new feature will guide users through the available commands and capabilities for easier and faster access to the tools you need.\n- Make Chat available in [supported IDEs](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#supported-editor-extensions). You can follow the development work for Visual Studio in [this epic](https://gitlab.com/groups/gitlab-org/editor-extensions/-/epics/22). \n\nWe look forward to [hearing your feedback on these enhancements](https://gitlab.com/gitlab-org/gitlab/-/issues/430124). Stay tuned for more updates as we continue to evolve [GitLab Duo Chat](https://about.gitlab.com/gitlab-duo/).\n\n> Get started with GitLab Duo Chat today by [signing up for a free 60-day trial](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?toggle=gitlab-duo-pro).",[786,703,9,701],{"slug":2788,"featured":6,"template":683},"gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements","content:en-us:blog:gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements.yml","Gitlab Duo Chat Get To Know Productivity Boosting Ai Enhancements","en-us/blog/gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements.yml","en-us/blog/gitlab-duo-chat-get-to-know-productivity-boosting-ai-enhancements",{"_path":2794,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2795,"content":2801,"config":2806,"_id":2808,"_type":13,"title":2809,"_source":15,"_file":2810,"_stem":2811,"_extension":18},"/en-us/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"title":2796,"description":2797,"ogTitle":2796,"ogDescription":2797,"noIndex":6,"ogImage":2798,"ogUrl":2799,"ogSiteName":670,"ogType":671,"canonicalUrls":2799,"schema":2800},"GitLab Duo Chat gets agentic AI makeover  ","Our new Duo Chat experience, currently an experimental release, helps developers onboard to projects, understand assignments, implement changes, and more.","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","https://about.gitlab.com/blog/gitlab-duo-chat-gets-agentic-ai-makeover","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Chat gets agentic AI makeover  \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Torsten Linz\"}],\n        \"datePublished\": \"2025-05-29\",\n      }",{"title":2796,"description":2797,"authors":2802,"heroImage":2798,"date":2803,"body":2804,"category":806,"tags":2805},[1414],"2025-05-29","Generative AI chat assistants have become standard in software development, helping create and fix code just to start. But what if your chat assistant could understand the artifacts of your entire development process, not just your code? What if that chat assistant could help you work through issues and project documentation before it helps you write code, and could access CI/CD pipelines and merge requests to help you finish coding tasks properly? \n\n**Meet the next generation of GitLab Duo Chat – GitLab Duo Agentic Chat, a significant evolution in AI-native development assistance and the newest addition to our platform, now in [experimental release](https://docs.gitlab.com/policy/development_stages_support/#experiment).** GitLab Duo Agentic Chat is currently available as an experimental feature in VS Code to all users on GitLab.com that have any one of these add-ons: Duo Core, Duo Pro, or Duo Enterprise.\n\nAgentic Chat transforms chat from traditional conversational AI to a chat experience that takes action on your behalf, breaking down complex problems into discrete tasks that it can complete. Instead of simply responding to questions with the context you provide, Agentic Chat can:\n\n* **Autonomously determine** what information it needs to answer your questions  \n* **Execute a sequence of operations** to gather that information from multiple sources  \n* **Formulate comprehensive responses** by combining insights from across your project  \n* **Create and modify files** to help you implement solutions\n\nAnd all of this is done while keeping the human developer within the loop.\n\nAgentic Chat is built on the Duo Workflow architecture, which is [currently in private beta](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/). The architecture comprises agents and tools that take on specific tasks like finding the right context for a given question or editing files. \n\n**Use cases for GitLab Duo Agentic Chat**\n\nHere are some real-world and common use cases for Agentic Chat:\n\n* Onboard to new projects faster by having AI help you familiarize yourself with a new codebase.\n\n* Jump into assigned work immediately, even when issue descriptions are unclear, because Agentic Chat can help you connect the dots between requirements and existing implementations.\n\n* When it's time to make changes, Agentic Chat can handle the implementation work by creating and editing multiple files across your project.\n\n* At release time, Agentic Chat can help you verify that your solution actually addresses the original requirements by analyzing your merge requests against the initial issue or task.\n\n![agentic chat - example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099210/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099210429.png)\n\n\u003Ccenter>\u003Ci>Agentic Chat making code edits\u003C/i>\u003C/center>\n\n## From learning to shipping: A complete workflow demonstration in four steps\n\nTo show how Agentic Chat transforms the development experience, let's walk through a real scenario from our engineering teams. Imagine you're a new team member who's been assigned an issue but knows nothing about the codebase. You can follow along with this video demonstration:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Step 1: Understand the project**\n\nInstead of manually exploring files and documentation, you can prompt Agentic Chat:\n\n```unset\nI am new to this project. Could you read the project structure and explain it to me?\n```\n\nAgentic Chat provides a comprehensive project overview by:  \n- Exploring the directory structure  \n- Reading README files and documentation  \n- Identifying key components and applications\n\n**Step 2: Understand your assigned task**\n\nNext, you need to understand your specific assignment, so you can enter this prompt:\n\n```unset\nI have been assigned Issue 1119. Could you help me understand this task, specifically where do I need to apply the refactoring?\n```\n\nAgentic Chat explains the task and proposes a refactoring approach by:\n- Retrieving and analyzing the issue details from the remote GitLab server  \n- Examining relevant project files  \n- Identifying the specific locations requiring changes\n\n**Step 3: Implement the solution**\n\nRather than doing the work manually, you can request:\n\n```unset\nCould you make the edits for me? Please start with steps one, two, three.\n```\n\nAgentic Chat then:  \n- Creates new directories and files as needed \n- Extracts and refactors code across multiple locations  \n- Ensures consistency across all modified files  \n- Provides a summary of all changes made\n\n**Step 4: Verify completion**\n\nFinally, after creating your merge request, you can verify your work:\n\n```unset\nDoes my MR fully address Issue 1119? \n```\n\nAgentic Chat confirms whether all requirements have been met by analyzing both your merge request and the original issue.\n\n## Try it today and share your feedback\n\nGitLab Duo Agentic Chat is currently available as an experimental feature in VS Code to all users on GitLab.com that have any one of these add-ons: Duo Core, Duo Pro, or Duo Enterprise. See our [setup documentation](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) for prerequisites and configuration steps.\n\nAs an experimental feature, Agentic Chat has some known limitations we're actively addressing, including slower response times due to multiple API calls, keyword-based rather than semantic search, and limited support for new local folders or non-GitLab projects. **Your feedback is crucial in helping us prioritize improvements and bring Agentic Chat to general availability so please share your experience in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/542198).**\n\n## What's next?\n\nWe are fully focused on improving Agentic Chat, including bringing it to general availability. In the meantime, we are aiming to improve response times and are adding capabilities that GitLab Duo Chat currently has, such as using self-hosted models or supporting JetBrains and Visual Studio in addition to VS Code. Once we have switched Duo Chat to this new architecture we plan to also bring Agentic Chat to the chat in the GitLab web application. We also plan to add a lot more functionality, such as editing GitLab artifacts, supporting context from custom Model Context Protocol, or MCP, servers, and offering commands to run in the terminal.\n\n> Ready to experience autonomous development assistance but not yet a GitLab customer? Try Agentic Chat today as part of [a free, 60-day trial of GitLab Ultimate with Duo Enterprise](https://about.gitlab.com/free-trial/) and help shape the future of AI-powered development. Follow these [setup steps for VS Code](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code).\n>\n> And make sure to join the GitLab 18 virtual launch event to learn about our agentic AI plans and more. [Register today!](https://about.gitlab.com/eighteen/)\n\n***Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.***\n\n## Learn more\n\n- [GitLab Duo Workflow: Enterprise visibility and control for agentic AI](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [What is agentic AI?](https://about.gitlab.com/topics/agentic-ai/)\n- [Agentic AI guides and resources](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)\n",[786,678,9,478,701,746],{"slug":2807,"featured":90,"template":683},"gitlab-duo-chat-gets-agentic-ai-makeover","content:en-us:blog:gitlab-duo-chat-gets-agentic-ai-makeover.yml","Gitlab Duo Chat Gets Agentic Ai Makeover","en-us/blog/gitlab-duo-chat-gets-agentic-ai-makeover.yml","en-us/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"_path":2813,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2814,"content":2820,"config":2824,"_id":2826,"_type":13,"title":2827,"_source":15,"_file":2828,"_stem":2829,"_extension":18},"/en-us/blog/gitlab-duo-code-suggestions-python",{"title":2815,"description":2816,"ogTitle":2815,"ogDescription":2816,"noIndex":6,"ogImage":2817,"ogUrl":2818,"ogSiteName":670,"ogType":671,"canonicalUrls":2818,"schema":2819},"How GitLab Duo Code Suggestions helped me make long car rides fun","AI-powered Gitlab Duo Code Suggestions coupled with Remote Development workspaces helped me create a Python-based guessing game application to keep my daughter entertained.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679869/Blog/Hero%20Images/carride.jpg","https://about.gitlab.com/blog/gitlab-duo-code-suggestions-python","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab Duo Code Suggestions helped me make long car rides fun\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2023-08-03\",\n      }",{"title":2815,"description":2816,"authors":2821,"heroImage":2817,"date":1310,"body":2822,"category":806,"tags":2823},[1769],"\nOn long car rides with my daughter I have two options: Let her watch a movie or continuously play a game with her where she tries to guess a random number in my head. I often opt to play the game, but recently, my energy and patience weren't at their peak. This led to a moment of inspiration. Why not develop a simple application that my daughter could play on her own? The only hurdle was that I haven't developed an application in years, and, since then, new languages such as Python have emerged. \n\nWith the help of the AI-powered feature [GitLab Duo Code Suggestions (Beta)](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html), I was able to quickly develop a Python application, despite having no prior knowledge of the programming language.\n\n## How I built the guessing game application\nMy application development journey began by launching the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) powered by VS Code. From there, I navigated to Preferences and [activated Code Suggestions](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#enable-code-suggestions-for-an-individual-user), paving the way for my AI-assisted coding session.\n\nThanks to Code Suggestions, I had the flexibility to input code or compose comments in plain text English, and receiving automated code suggestions while typing. For instance, I included only these three comments, ultimately utilizing them to construct the entire application:\n- store a random number between 0 to 10 \n- print a welcome message to Yael, ask to guess a number between 0 to 10 \n- create a loop that will continue until the user guesses the number \n\nTo my surprise, not only did the code suggestions align with my comments, but they also grasped the underlying concept of my application, offering additional code without explicit comments. After making a few minor adjustments, here is the final code for the game:\n\n```python\nimport random\n\n# Store a random number between 0 to 10\nnumber = random.randint(0, 10)\ncounter = 0\n# Print a welcome message to Yael, ask to guess a number between 0 to 10\n\nprint(\"Welcome to the guessing game, Yael!\")\nprint(\"I am thinking of a number between 0 and 10, can you guess what it is?\")\n\n# Create a loop that will continue until the user guesses the number\n\nwhile True:\n   # Get the user's guess\n   guess = int(input(\"Guess my number: \"))\n   counter += 1\n\n\n  # Check if the user's guess is correct\n   if guess == number:\n       # If the guess is correct, print a message and break out of the loop\n       print(\"You guessed it! My number was\", number, \"and it took you\", counter, \"guesses.\")\n       break\n  \n   elif    guess \u003C number:\n       print(\"Your guess is too low.\")\n   else:\n       print(\"Your guess is too high.\")\n\n```\n\nWith the assistance of Code Suggestions, I was able to navigate the intricacies of Python coding, step by step. The suggested code not only aligned perfectly with my intentions, but also expanded my understanding of the programming language, enabling me to build a functional game. \n\nAfter thoroughly testing the guessing game application using the debugging tool in VS Code, I was delighted to find that it worked flawlessly! However, a new challenge arose: How could I make this game accessible to my daughter while in the car?\n\n## How to leverage GitLab Remote Development workspaces Beta\nIf you have young children, you're likely familiar with their constant need for instant gratification. To satisfy my daughter's desire to play the new game on her iPad right away, I needed a solution.\n\nSince the game wasn't available as a mobile or web application, I decided to utilize the power of [GitLab Remote Development workspaces](/blog/quick-start-guide-for-gitlab-workspaces/) to create a mobile environment for her.\n\nThe workspace is a temporary development environment hosted in the cloud, which offers a simple setup process and numerous advantages for developers. Now, you might wonder how this is relevant to our topic. Well, Remote Development workspaces provides a link to access the environment. This became my workaround to allow her to start playing the game immediately within that development environment directly from her iPad.\n\nThis strategy turned out to be the perfect workaround, not only allowing her to enjoy the game but also exposing her to the captivating world of programming.\n\n## Understanding beta features\nWhile my journey of developing a game in Python, with the help of Code Suggestions, has been incredibly valuable, it's important to acknowledge that the feature is currently in its beta phase. As is common with beta features, there are certain considerations to keep in mind. Due to the high demand and ongoing improvements, there may be occasional unscheduled downtime and potential delays in receiving Code Suggestions within IDEs. Additionally, it's worth noting that the suggestions generated by Code Suggestions may occasionally be of lower quality or incomplete. As Beta users, it is crucial to familiarize yourself with the [documented limitations](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html).\n\n## Demo\nThis [click-through demo](https://go.gitlab.com/HplUKw) showcases how I used Code Suggestions to develop the guessing game application. I encourage you to give Code Suggestions a try today as you will have a lot of fun.\n\n## We are looking for your feedback! \nFeedback from Beta users of Code Suggestions is invaluable. The GitLab team eagerly awaits your input, which will play an important role in further enhancing this feature and refining its capabilities. Together, we can shape the future of Code Suggestions and make it even more powerful and reliable. To send feedback, or report on issues, use the [Code Suggestions feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/405152). \n\n",[678,9,786,703],{"slug":2825,"featured":6,"template":683},"gitlab-duo-code-suggestions-python","content:en-us:blog:gitlab-duo-code-suggestions-python.yml","Gitlab Duo Code Suggestions Python","en-us/blog/gitlab-duo-code-suggestions-python.yml","en-us/blog/gitlab-duo-code-suggestions-python",{"_path":2831,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2832,"content":2838,"config":2844,"_id":2846,"_type":13,"title":2847,"_source":15,"_file":2848,"_stem":2849,"_extension":18},"/en-us/blog/gitlab-duo-enterprise-is-now-available",{"title":2833,"description":2834,"ogTitle":2833,"ogDescription":2834,"noIndex":6,"ogImage":2835,"ogUrl":2836,"ogSiteName":670,"ogType":671,"canonicalUrls":2836,"schema":2837},"GitLab Duo Enterprise is now available","Organizations have an end-to-end AI partner for faster, more secure software development. Learn how GitLab Duo Enterprise supports the entire DevSecOps lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665660/Blog/Hero%20Images/Untitled__1800_x_945_px_.png","https://about.gitlab.com/blog/gitlab-duo-enterprise-is-now-available","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Enterprise is now available\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-09-03\",\n      }",{"title":2833,"description":2834,"authors":2839,"heroImage":2835,"date":2841,"body":2842,"category":806,"tags":2843},[2840],"David DeSanto, Chief Product Officer, GitLab","2024-09-03","[GitLab Duo Enterprise]( https://about.gitlab.com/gitlab-duo/), now available, is an end-to-end AI partner designed for the entire software development lifecycle. This powerful suite of AI tools is designed to boost developer productivity, enhance security, streamline collaboration, and accelerate your DevSecOps processes.\n\nKey features at a glance:\n- Intelligent code assistance across 25+ programming languages\n- AI-powered security vulnerability details and resolution\n- Automated test generation and root cause analysis\n- Team collaboration enhancements with AI-driven summaries\n- ROI quantification through an AI Impact Dashboard\n\n## Why we developed GitLab Duo Enterprise\n\nAs organizations aim to deliver better software faster and create customer value, they encounter significant challenges that slow their progress. [Our research](http://about.gitlab.com/developer-survey/2024/ai) shows that 95% of organizations are either evaluating or using AI in the software development lifecycle. However, 55% of survey respondents said they feel using AI for software development is risky.\n\nCommon pain points in the enterprise include suboptimal developer experience and productivity, increasing security and compliance demands, inefficient collaboration across teams, and difficulty in assessing the ROI of AI technology investments. GitLab Duo Enterprise addresses these challenges head-on, providing a secure, efficient, and powerful AI partner for your development teams. \n\n**Let's explore how GitLab Duo Enterprise can transform the way your company creates and deploys software.**\n\n## Boost developer productivity with intelligent code assistance\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252678?h=83f35171b6&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Suggestions clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nOne of the primary hurdles in software development is the time-consuming nature of routine coding tasks. Get to the most impactful work faster with:\n\n- __Code Suggestions__ supports more than 25 programming languages. This AI-powered tool accelerates code creation, improves code quality, and reduces the time spent on boilerplate tasks.\n\nBut it's not just about writing new code. \n\n- GitLab Duo Enterprise's __Code Explanation__ capability enables developers to quickly understand complex or unfamiliar code, while \n\n- **Code Refactoring** enables developers to [improve and modernize existing code](https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/). \n\n- __Test Generation__ automates the creation of comprehensive unit tests. The result? Developers can focus on high-value tasks that drive innovation, leading to faster development cycles and improved software quality.\n\n> See how [European tech company Cube](https://about.gitlab.com/customers/cube/) uses Code Suggestions, Test Generation, and other GitLab Duo features to achieve improvements in speed and efficiency. \n\n## Enhance team collaboration and communication\n\nEffective collaboration is the cornerstone of successful software development, yet it's often hindered by lengthy discussions, complex merge requests, and time-consuming code reviews. GitLab Duo Enterprise addresses these challenges with its suite of summarization and templating tools:\n- __Discussion Summary:__ Allows team members to quickly get up to speed on lengthy conversations in issues\n- __Merge Request Summaries:__ Provide clear, concise overviews of proposed changes. \n- __Code Review Summaries:__ Streamline the review process, enabling better handoffs between authors and reviewers. \n\nBy facilitating clearer communication and faster decision-making, GitLab Duo Enterprise helps teams work more efficiently and deliver results more quickly.\n\n## Streamline troubleshooting and debugging\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252688?h=fc6c048bfd&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Root Cause Analysis clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nWhen development pipelines fail, the impact on project timelines can be significant. GitLab Duo Enterprise's __Root Cause Analysis__ feature is a game-changer here. By automatically analyzing logs and providing detailed explanations of failures along with potential fixes, Root Cause Analysis significantly reduces the time spent on troubleshooting.\n\nThe benefits extend beyond just time savings. With [faster resolution of CI/CD build issues](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/), teams can maintain momentum, reduce downtime, and ultimately deliver software updates more frequently and reliably.\n\n## Elevate security across the development lifecycle\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252706?h=73e568b89c&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Vulnerability Explanation and Resolution clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nCybersecurity threats are ever-present, so robust application security is a necessity. GitLab Duo Enterprise rises to this challenge with its __Vulnerability Explanation__ and __Vulnerability Resolution__ features. These AI-powered tools help [developers fully understand security vulnerabilities](https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/) and then automatically generate merge requests with suggested fixes.\n\n## Quantify AI impact for strategic decision-making\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252663?h=d35106288b&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"AI Impact Dashboard clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nDemonstrating the ROI of technology investments is crucial. GitLab Duo Enterprise addresses this need head-on with its __AI Impact Dashboard__. This analytics tool, built on top of Value Stream Analytics and DORA4 metrics, provides clear metrics on cycle time improvements and increased deployment frequencies, allowing organizations to quantify the tangible benefits of AI adoption in their development processes.\n\nBy offering insights into how AI usage correlates with key productivity metrics, the [AI Impact Dashboard](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) empowers leadership to make data-driven decisions about resource allocation and strategic technology investments.\n\n## Embrace the future of AI-powered DevSecOps\n\nAs we unveil GitLab Duo Enterprise, we're proud to announce that GitLab has been recognized as a Leader in the inaugural [Gartner® Magic Quadrant™ for AI Code Assistants](https://about.gitlab.com/gartner-mq-ai-code-assistants/). This recognition underscores our commitment to delivering AI solutions that drive real business value.\n\nThe future of software development is here, and it's powered by AI. We're here to help you incorporate intelligent, scalable AI throughout the DevSecOps lifecycle so you can deliver results faster for your customers.\n\n> [Get started today with GitLab Duo Enterprise with a free 60-day trial!](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)\n",[786,701,478,9,678],{"slug":2845,"featured":90,"template":683},"gitlab-duo-enterprise-is-now-available","content:en-us:blog:gitlab-duo-enterprise-is-now-available.yml","Gitlab Duo Enterprise Is Now Available","en-us/blog/gitlab-duo-enterprise-is-now-available.yml","en-us/blog/gitlab-duo-enterprise-is-now-available",{"_path":2851,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2852,"content":2858,"config":2863,"_id":2865,"_type":13,"title":2866,"_source":15,"_file":2867,"_stem":2868,"_extension":18},"/en-us/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"title":2853,"description":2854,"ogTitle":2853,"ogDescription":2854,"noIndex":6,"ogImage":2855,"ogUrl":2856,"ogSiteName":670,"ogType":671,"canonicalUrls":2856,"schema":2857},"GitLab Duo Self-Hosted: Enterprise AI built for data privacy","Customers in regulated industries can now deploy GitLab Duo on self-managed infrastructure, leveraging the power of generative AI while helping to address data residency and privacy concerns.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097840/Blog/Hero%20Images/Blog/Hero%20Images/Self-Hosted%201800x945_1dL1II2ITh2PteObA9DBLD_1750097839679.png","https://about.gitlab.com/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Self-Hosted: Enterprise AI built for data privacy\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"},{\"@type\":\"Person\",\"name\":\"Aathira Nair\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":2853,"description":2854,"authors":2859,"heroImage":2855,"date":1730,"body":2861,"category":806,"tags":2862},[2075,2860],"Aathira Nair","We are excited to announce the general availability of GitLab Duo Self-Hosted for Code Suggestions and Chat. An optional capability for self-managed customers with a GitLab Duo Enterprise subscription, GitLab Duo Self-Hosted supports deployment flexibility across multiple platforms, including on-premises infrastructure or in private clouds and secure cloud environments through AWS Bedrock and Azure OpenAI. GitLab Duo Self-Hosted empowers teams to innovate with AI while helping them maintain control over sensitive data and intellectual property. \n\nSecurity concerns have been a major barrier to AI adoption in regulated industries. In our [Global DevSecOps Survey](http://about.gitlab.com/developer-survey/2024/ai), more than half of the respondents said that introducing AI into the software development lifecycle is risky. With [GitLab Duo](https://about.gitlab.com/gitlab-duo/), we gave organizations a way to ship more secure software faster with AI throughout the entire software development lifecycle.\n\nGitLab Duo Self-Hosted expands the availability of GitLab Duo AI features to organizations with stringent data privacy requirements, offering flexibility in both AI large language model (LLM) selection and deployment options. The earliest adopters of GitLab Duo Self-Hosted include organizations in the public sector and regulated industries  – e.g., financial services, automotive, and healthcare. These organizations seek to gain the competitive advantage of AI by integrating AI-powered development tools into their environments, while also giving security teams the control they need.\n\nAs one U.S. government agency says: “After selecting GitLab as the cornerstone of our agency-wide DevSecOps platform, we chose GitLab Duo Self-Hosted to further advance our software factory capabilities. GitLab Duo’s ability to operate in air-gapped environments and provide granular control over our data was crucial to delivering secure AI-powered features. This unified approach streamlines our workflow and strengthens security, allowing us to leverage AI for increased productivity while meeting strict compliance requirements.” \n\n![GitLab Duo Self-Hosted models](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097848329.png)\n\n## Architect secure AI deployments\n\nGitLab Duo Self-Hosted enables GitLab Duo features that leverage a curated selection of leading AI LLMs, including those from Anthropic, Mistral, and OpenAI. Here are the LLMs supported by GitLab today:\n\n* On-premises - Mistral models with the vLLM serving platform  \n* AWS - Mistral and Anthropic Claude 3.5 Sonnet via AWS Bedrock  \n* Microsoft Azure - OpenAI GPT models via Azure AI\n\nWe are evaluating more models to support in the near future. [Learn more about the LLMs we support.](https://docs.gitlab.com/ee/administration/self_hosted_models/supported_models_and_hardware_requirements.html#approved-llms)\n\nGitLab Duo Self-Hosted deployment options include on-premises installations powered by the open-source vLLM framework, as well as private-cloud deployments via services like AWS Bedrock and Microsoft Azure AI. This flexibility helps organizations to architect AI solutions that align with their unique security, compliance, and performance requirements.\n\n## Simplify AI/ML implementation\n\nGitLab Duo's AI abstraction layer standardizes and simplifies the integration of the chosen LLM to a feature, mitigating the burden of implementing AI/ML technologies. This enables companies to streamline their AI adoption efforts and enhance the developer experience, free from the complexities of integrating and maintaining multiple tools.\n\n![GitLab Duo Self-Hosted AI-powered features](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097848330.png)\n\n## Maintain control of sensitive data\n\nBy isolating your GitLab instance, AI gateway, and LLMs in your own environment or country of choice, GitLab Duo Self-Hosted makes it possible that sensitive data and intellectual property remain within your designated perimeter. Granular control over data locality helps enable adherence to strict data residency regulations, while adopting AI capabilities in secure settings. Whether you use GitLab Duo Self-Hosted in a completely air-gapped environment with vLLM or leverage a supported private cloud, you can control all aspects of the deployment to include the geographic location of components. By eliminating the reliance on external APIs and providing full visibility into all request and response logs, GitLab Duo Self-Hosted helps even the most regulated organizations confidently adopt AI capabilities and meet the most stringent compliance obligations.\n\n**Start an interactive tour of GitLab Self-Hosted by clicking on the image below:**\n\n[![GitLab Duo Self-Hosted tour screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-20_at_7.00.34_AM_aHR0cHM6_1750097848332.png)](https://gitlab.navattic.com/gitlab-duo-self-hosted)\n\n## Get started with GitLab Duo Self-Hosted today\n\nIf you're ready to advance your AI journey while addressing security and data privacy, [reach out to us](https://about.gitlab.com/sales/) to help set up GitLab Duo Self-Hosted in your environment today.",[786,9,478,701,678],{"slug":2864,"featured":90,"template":683},"gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","content:en-us:blog:gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","Gitlab Duo Self Hosted Enterprise Ai Built For Data Privacy","en-us/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","en-us/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"_path":2870,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2871,"content":2877,"config":2883,"_id":2885,"_type":13,"title":2886,"_source":15,"_file":2887,"_stem":2888,"_extension":18},"/en-us/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"title":2872,"description":2873,"ogTitle":2872,"ogDescription":2873,"noIndex":6,"ogImage":2874,"ogUrl":2875,"ogSiteName":670,"ogType":671,"canonicalUrls":2875,"schema":2876},"GitLab Duo with Amazon Q: Agentic AI optimized for AWS generally available","The comprehensive AI-powered DevSecOps platform combined with the deepest set of cloud computing capabilities speeds dev cycles, increases automation, and improves code quality.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659604/Blog/Hero%20Images/Screenshot_2024-11-27_at_4.55.28_PM.png","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo with Amazon Q: Agentic AI optimized for AWS generally available\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2025-04-17\",\n      }",{"title":2872,"description":2873,"authors":2878,"heroImage":2874,"date":2880,"body":2881,"category":806,"tags":2882},[2879],"Emilio Salvador","2025-04-17","Today, we're excited to announce the general availability of [GitLab Duo with Amazon Q](https://about.gitlab.com/partners/technology-partners/aws/), delivering agentic AI throughout the software development lifecycle for AWS customers. GitLab Duo with Amazon Q, based on GitLab Ultimate, includes many familiar features such as code completion, code explanation, code generation, chat, and vulnerability explanation and resolution – all of which are now powered by Amazon Q. It is available with a Self-Managed deployment model for customers on Amazon Web Services (AWS).\n\nWith Amazon Q's agents directly embedded into GitLab's DevSecOps platform, developers maintain their familiar development environment while gaining powerful AI capabilities. The result is a frictionless experience that helps accelerate development cycles, reduce manual effort, and enhance code quality.\n\n“Participating in the early access program for GitLab Duo with Amazon Q has given us a glimpse into its transformative potential for our development workflows,” said Osmar Alonso, DevOps Engineer, Volkswagen Digital Solutions. “Even in its early stages, we saw how the deeper integration with autonomous agents could streamline our process, from code commit to production. We're excited to see how this technology empowers our team to focus on innovation and accelerate our digital transformation.\"\n\n## Agentic AI comes to complex customer environments\n\nBy combining agentic AI with secure, reliable cloud infrastructure, GitLab and AWS bring built-in security, scale, and reliability to complex customer environments, enabling them to realize the following benefits:\n\n__Unified developer experience for streamlined development__\n\nDevelopers can interact with Amazon Q through the GitLab Duo Chat interface from their preferred IDE or the GitLab web interface. This eliminates the need for context switching in other tools and helps developers stay focused on the project that they’re working on.\n\n__One solution for the entire software development lifecycle__\n\nCode suggestions and optimizations leverage AWS-specific patterns and practices, while testing tools understand AWS service interactions and dependencies. A common data store across all stages provides essential context to AI agents, enabling complete visibility and traceability for relevant actions.\n\n__Secure development with enterprise-grade guardrails__\n\nEnd-to-end security and compliance are built directly into the development platform with guardrails that help reduce risk without impeding velocity. This secure software development approach enforces transparency and auditability through AI agents while seamlessly integrating with AWS security services and compliance frameworks.\n\n## How to start using GitLab Duo with Amazon Q\n\nHere are five initial use cases we’re targeting to help teams build secure software faster with agentic AI: \n\n1. **Feature development acceleration** - Create issue descriptions, generate implementation plans based on your existing codebase, and produce complete merge requests ready for review. This drives feature delivery acceleration while maintaining consistency with internal development standards.  \n2. **Legacy application modernization** - Analyze your legacy Java codebase, create a comprehensive upgrade plan, and generate a merge request with all necessary code changes. This unlocks faster Java upgrade time, while providing a clear audit trail of all code transformations. Support for .NET and other languages is planned for future releases.  \n3. **Quality assurance enhancement** - Analyze code and automatically create comprehensive unit tests that understand your application logic and AWS service interactions. This increases test coverage, reduces manual test writing effort, and helps ensure consistent test quality across applications.  \n4. **Code review optimization** - Provide inline feedback on code changes, suggesting improvements based on development standards, highlighting security and performance considerations. This enables reduced code review cycles and delivery of higher-quality code merges for deployment.  \n5. **Vulnerability remediation** - Explain detected vulnerabilities in clear, detailed terms and one-click remediation based on recommended code changes, helping to significantly reduce the time from detection to remediation.\n\nWatch GitLab Duo with Amazon Q in action:\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> #### Get the benefits of GitLab Duo with Amazon Q today\n> GitLab's unified, AI-powered DevSecOps platform with Amazon Q's advanced AI capabilities provides AWS customers with a solution that transforms how teams build and deploy software. To learn more about GitLab Duo with Amazon Q visit us at an upcoming [AWS Summit in a city near you](https://about.gitlab.com/events/aws-summits/) or [reach out to your GitLab representative](https://about.gitlab.com/partners/technology-partners/aws/#form).",[786,478,872,701,9,678],{"slug":2884,"featured":90,"template":683},"gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","content:en-us:blog:gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","Gitlab Duo With Amazon Q Agentic Ai Optimized For Aws","en-us/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","en-us/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"_path":2890,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2891,"content":2897,"config":2903,"_id":2905,"_type":13,"title":2906,"_source":15,"_file":2907,"_stem":2908,"_extension":18},"/en-us/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"title":2892,"description":2893,"ogTitle":2892,"ogDescription":2893,"noIndex":6,"ogImage":2894,"ogUrl":2895,"ogSiteName":670,"ogType":671,"canonicalUrls":2895,"schema":2896},"GitLab Duo Workflow: Enterprise visibility and control for agentic AI","Secure, autonomous, context-aware AI agents take on complex tasks, freeing developers to ship innovative software faster. Private beta waitlist now open.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660174/Blog/Hero%20Images/Workflow_1800x945.png","https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflow: Enterprise visibility and control for agentic AI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pini Wietchner\"}],\n        \"datePublished\": \"2025-02-24\",\n      }",{"title":2892,"description":2893,"authors":2898,"heroImage":2894,"date":2900,"body":2901,"category":806,"tags":2902},[2899],"Pini Wietchner","2025-02-24","Today, we're excited to announce the opening of the waitlist for the [private beta of GitLab Duo Workflow](https://about.gitlab.com/gitlab-duo/workflow): **agentic AI built on top of the most comprehensive DevSecOps platform.** The next step in our AI roadmap, GitLab Duo Workflow will help development teams navigate everything from project bootstrapping to deployment processes, from debugging issues to cross-team coordination, all within the IDE. \n\nGitLab Duo Workflow leverages the GitLab platform's structure for collaboration, continuous integration, continuous deployment, security, and compliance to help organizations as they accelerate their development process with AI agents. \n\nUse GitLab Duo Workflow to help you:   \n* [bootstrap a new development project](#from-slow-project-setup-to-a-running-start)  \n* [modernize code](#from-legacy-code-to-modern-applications)  \n* [perform contextual tasks](#from-context-switching-to-flow-state) \n* [create documentation](#from-stale-docs-to-dynamic-knowledge)\n* [enhance test coverage](#from-patchy-to-comprehensive-testing) \n* and more  \n\nThis is just the beginning. With GitLab’s unified data store, the more you use GitLab, the more context GitLab Duo Workflow has about your code, configurations, security findings, and deployment practices. The result: an increasingly powerful development experience that's tailored to your organization.\n\n## The promise and challenge of AI agents\n\nSoftware has fundamentally changed the world, but only a tiny fraction of the world's population has the skills to build software today. Yet, these developers reach billions of people with smartphones and internet connections. Just imagine a world where *more* people can build, secure, and deliver production-ready software – there will be an explosion of innovation as more people can create software that impacts billions. **Agentic AI will make that happen.**\n\nAI agents understand context, maintain knowledge of entire codebases, and actively collaborate on complex software projects across development, security, and operations. With AI agents, developers can create software at a scale previously unimaginable for individuals or even teams.\n\nBut this shift raises important questions about visibility, control, and how AI will impact developers' work. Organizations need to ensure AI enhances their developers' capabilities while enabling them to maintain oversight of their development process. The key to success isn't just adopting AI – it's adopting it in a way that empowers developers while preserving security, compliance, and governance.\n\n## AI's success depends on your platform, not more add-on tools\n\nWhen you're working with more developers, code, and potential security risks, adding separate tools for each new challenge only creates more complexity. Our most recent [DevSecOps Survey](https://about.gitlab.com/the-source/platform/devops-teams-want-to-shake-off-diy-toolchains-a-platform-is-the-answer/) shows just how serious this problem is: DevSecOps teams are juggling up to 14 different tools, with professionals spending up to 80% of their time on non-coding tasks. For AI to be truly effective, it also needs high-quality, unified data. That's hard to achieve with disparate tools.\n\n**The GitLab DevSecOps platform combined with GitLab AI agents** brings everything together in a single data model that encapsulates source code, merge requests, epics, users, access rights, and more. The agents we're building use context about users and projects to standardize how teams work and automate the non-coding tasks that absorb developer time, such as scanning for security issues and enforcing compliance rules. When AI is built directly into the platform, these capabilities become even more powerful, turning AI agents into development partners while keeping you in control of how AI enhances the process.\n\n**This isn't a far-off future — it's what we're building right now with GitLab Duo Workflow.**\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1059060959?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Workflow, the future of secure agentic AI software development\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>`\n\n## GitLab Duo Workflow: AI agents on the most comprehensive DevSecOps platform\n\nLeveraging GitLab's end-to-end DevSecOps platform, GitLab Duo Workflow helps developers work at their highest potential. While AI coding assistants help with individual pieces of code, GitLab Duo Workflow will understand your entire development lifecycle – automating routine tasks so developers can focus on strategic innovation and creative problem-solving. As we develop GitLab Duo Workflow, here’s what it will be able to help teams achieve: \n\n### From slow project setup to a running start\n\nDevelopers spend precious time configuring new projects, managing dependencies, and setting up basic infrastructure instead of building new features. With GitLab Duo Workflow, you can **automate project bootstrapping directly in the IDE**, providing the right configurations from the start so you can focus on innovation sooner.\n\n### From legacy code to modern applications\n\nModernizing legacy code is more than just updating syntax — it requires understanding dependencies, tests, CI/CD pipelines, and documentation. GitLab Duo Workflow helps **modernize your codebase by handling code refactoring** – from code to tests.\n\n### From context switching to flow state\n\nToday, developers constantly switch between tools, docs, and codebases to solve problems. GitLab Duo Workflow will help **resolve tasks with the full context of your codebase-related issues and merge requests**, letting developers stay in their flow.\n\n### From stale docs to dynamic knowledge\n\nDocumentation becomes stale quickly, making codebases harder to understand and maintain. GitLab Duo Workflow **supports developers in generating and updating documentation**, including README files, code flow diagrams, and architecture documentation.\n\n### From patchy to comprehensive testing\n\nAs codebases grow, maintaining comprehensive test coverage becomes increasingly challenging. GitLab Duo Workflow **can generate tests for entire sections of your codebase** while integrating with your existing test infrastructure, ensuring more reliable software with less effort.\n\n## Sign up for the private beta waitlist\n\n[Sign up for the GitLab Duo Workflow private beta waitlist](https://about.gitlab.com/gitlab-duo/workflow) to see the next step in our vision for secure agentic AI – from project setup to deployment. Built on GitLab's DevSecOps platform, these agents understand your entire software lifecycle while maintaining the enterprise-grade security and control organizations require.\n\n*Disclaimer: This page contains information about upcoming products, features, and functionality. This information is for informational purposes only and should not be relied upon for purchasing or planning. All items are subject to change or delay, and the development, release, and timing remain at GitLab Inc.'s sole discretion.*",[478,786,9,701,678,894],{"slug":2904,"featured":90,"template":683},"gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","content:en-us:blog:gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","Gitlab Duo Workflow Enterprise Visibility And Control For Agentic Ai","en-us/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","en-us/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"_path":2910,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2911,"content":2916,"config":2921,"_id":2923,"_type":13,"title":2924,"_source":15,"_file":2925,"_stem":2926,"_extension":18},"/en-us/blog/gitlab-eks-integration-how-to",{"title":2912,"description":2913,"ogTitle":2912,"ogDescription":2913,"noIndex":6,"ogImage":1926,"ogUrl":2914,"ogSiteName":670,"ogType":671,"canonicalUrls":2914,"schema":2915},"How to create a Kubernetes cluster on Amazon EKS in GitLab","A Kubernetes tutorial: Create clusters in a few clicks with GitLab and Amazon EKS.","https://about.gitlab.com/blog/gitlab-eks-integration-how-to","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to create a Kubernetes cluster on Amazon EKS in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2020-03-09\",\n      }",{"title":2912,"description":2913,"authors":2917,"heroImage":1926,"date":2918,"body":2919,"category":849,"tags":2920},[1932],"2020-03-09","Kubernetes has created a whole new world for running infrastructure at scale. With the right setup, an application can go from serving a few users to millions effortlessly. Setting up Kubernetes can be tasking and can require a lot of expertise to put all the pieces together. You’ll need to set up virtual or bare metal machines to use as nodes and manage SSL certificates, networking, load balancers, and many other moving parts.\n\nThe introduction of Amazon Elastic Kubernetes Service (EKS) was widely applauded as it streamlines the abstraction of the complexities in an environment most organizations are already familiar with and on a provider they already trust. Amazon EKS makes creating and managing Kubernetes clusters easier with more granular controls around security and straightforward policies of how resources are used.\n\nGitLab strives to increase developer productivity by automating repetitive tasks and allowing developers to focus on business logic. We recently introduced support for auto-creating Kubernetes clusters on Amazon EKS. In a few clicks with the right permissions, you’ll have a fully functional Kubernetes cluster on Amazon EKS. It doesn’t stop there however – GitLab also gives you the power to achieve the following use cases and more :\n\n* [Highly scalable CI/CD system using GitLab Runner](https://docs.gitlab.com/runner/): There are times like holidays when little to no changes to code are pushed to production, so why keep resources tied down? With the Amazon EKS integration with GitLab, you can install GitLab Runner with just a click and your CI/CD will run effortlessly without worrying about running out of resources.\n* Shared Cluster: Maintaining multiple Kubernetes clusters can be a pain and capital intensive. With Amazon EKS, GitLab allows you to setup a cluster at [Instance](https://docs.gitlab.com/ee/user/instance/clusters/index.html), [Group](https://docs.gitlab.com/ee/user/group/clusters/index.html) and [Project](https://docs.gitlab.com/ee/user/project/clusters/) levels. Kubernetes Namespaces are created for each GitLab project when the Amazon EKS is integrated at Instance and Project level, allowing isolation and ensuring security.\n* [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html): Reviewing changes to code or design can be tricky, you’ll need to check out your branch and run the code in a test environment. GitLab integrated with Amazon EKS deploys your app with new changes to a dynamic environment and all you need to do is click on a “View App“ button to review changes.\n* [AutoDevOps](https://docs.gitlab.com/ee/topics/autodevops/cloud_deployments/auto_devops_with_gke.html) takes DevOps to a whole new level. AutoDevOps detects, builds, tests, deploys, and monitors your applications, leveraging the Amazon EKS integration. All you have to do is push your code and the magic happens. In this tutorial, we will deploy a sample application to the Amazon EKS cluster we will be creating using AutoDevOps.\n\nTo show you how easy it is to create an Amazon EKS cluster from GitLab, the rest of this tutorial will walk you through the steps of the integration, starting with a one-time setup of necessary resources on AWS.\n\n## One-time setup on AWS to access resources\n\nFirst, we need to create a “provision\" role and a “service” role on AWS to grant GitLab access to your AWS resources and set up the necessary permissions to create and manage EKS clusters. You only need to perform these steps once and you can reuse them anytime you want to perform another integration or create more clusters.\n\n### Step 1 - Create Provision Role\n\nTo grant GitLab access to your AWS resources, a “provision role” is required. Let’s create one:\n\n1. Access GitLab Kubernetes Integration Page by clicking on the ”Kubernetes” menu for groups and Operations > Kubernetes menu for projects and click the “Add Kubernetes Cluster” button.\n2. Select “Amazon EKS” in the options provided under the “Create new cluster on EKS” tab.\n3. You are provided with an Account and External ID  to use for authentication. Make note of these values to be used in a later step.\n\n    ![Gitlab EKS Integration Page](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/gitlab_eks_integration_page.png)\n\n4. Open IAM Management Console in another tab and click on “Create Role”\n5. Click on the “Another AWS account” tab and provide the Account and External ID obtained from GitLab and click Next to set permissions as shown below:\n\n    ![AWS Provision Role](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/provision_role.png)\n\n6. On the permissions page, click on “Create policy.” This will open a new tab where you can set either of the permissions below using JSON:\n\n    ```json\n    {\n        \"Version\": \"2012-10-17\",\n        \"Statement\": [\n            {\n                \"Effect\": \"Allow\",\n                \"Action\": [\n                    \"autoscaling:*\",\n                    \"cloudformation:*\",\n                    \"ec2:*\",\n                    \"eks:*\",\n                    \"iam:*\",\n                    \"ssm:*\"\n                ],\n                \"Resource\": \"*\"\n            }\n        ]\n    }\n    ```\n\n    This gives GitLab full access to create and manage resources, as seen in the image below:\n\n    ![AWS Role Policy](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/create_role_policy.png)\n\n    If you prefer limited permission, you can give GitLab the ability to create resources, but not delete them with the JSON snippet below. The drawback here is if an error is encountered during the creation process, changes will not be rolled back and you must remove resources manually. You can do this by deleting the relevant CloudFormation stack.\n\n    ```json\n    {\n        \"Version\": \"2012-10-17\",\n        \"Statement\": [\n            {\n                \"Effect\": \"Allow\",\n                \"Action\": [\n                    \"autoscaling:CreateAutoScalingGroup\",\n                    \"autoscaling:DescribeAutoScalingGroups\",\n                    \"autoscaling:DescribeScalingActivities\",\n                    \"autoscaling:UpdateAutoScalingGroup\",\n                    \"autoscaling:CreateLaunchConfiguration\",\n                    \"autoscaling:DescribeLaunchConfigurations\",\n                    \"cloudformation:CreateStack\",\n                    \"cloudformation:DescribeStacks\",\n                    \"ec2:AuthorizeSecurityGroupEgress\",\n                    \"ec2:AuthorizeSecurityGroupIngress\",\n                    \"ec2:RevokeSecurityGroupEgress\",\n                    \"ec2:RevokeSecurityGroupIngress\",\n                    \"ec2:CreateSecurityGroup\",\n                    \"ec2:createTags\",\n                    \"ec2:DescribeImages\",\n                    \"ec2:DescribeKeyPairs\",\n                    \"ec2:DescribeRegions\",\n                    \"ec2:DescribeSecurityGroups\",\n                    \"ec2:DescribeSubnets\",\n                    \"ec2:DescribeVpcs\",\n                    \"eks:CreateCluster\",\n                    \"eks:DescribeCluster\",\n                    \"iam:AddRoleToInstanceProfile\",\n                    \"iam:AttachRolePolicy\",\n                    \"iam:CreateRole\",\n                    \"iam:CreateInstanceProfile\",\n                    \"iam:CreateServiceLinkedRole\",\n                    \"iam:GetRole\",\n                    \"iam:ListRoles\",\n                    \"iam:PassRole\",\n                    \"ssm:GetParameters\"\n                ],\n                \"Resource\": \"*\"\n            }\n        ]\n    }\n    ```\n\n    The image below visualizes what permissions are granted:\n\n    ![Limited Role Policy](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/limited_role_policy.png)\n\n7. Once the policy is created, return to the “Create Role” browser tab and refresh to see the policy we created listed. Select the policy and click “Next.”\n8. In the Tags section, we don’t need to set any Tags, except if it’s required in your organization. Let’s proceed to Review.\n9. Specify a Name for your new Role. You will see the policy we created listed under policies and click “Create Role” to complete the process.\n10. Click on the new Role you created in the list of Roles to view its details. You may have to search for it in the list of Roles if it’s not listed in the first view. Copy the Role ARN provided – we will need it on the GitLab Kubernetes Integration page.\n\n### Step 2 - Create Service Role\n\nThe Service Role is required to allow Amazon EKS and the Kubernetes control plane to manage AWS resources on your behalf.\n\n1. In the IAM Management Console, click on “Create Role” and select the “AWS service” tab.\n2. Select EKS in the list of services and Use Cases as shown below and click Next.\n\n    ![Service Role](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/service_role.png)\n\n3. You will notice the “AmazonEKSClusterPolicy” and “AmazonEKSServicePolicy” permissions are selected; these are all we need. Click through the Tags step and create if necessary, then click Next to get to the Review step. Click “Create Role” to complete the process.\n\n    ![Role Summary](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/role_summary.png)\n\n## GitLab EKS Integration\n\nThis is the easy part! As mentioned earlier, you only need to create the Provision and Service role once if you don’t already have them in your organization’s AWS setup. You can reuse the roles for other integrations or cluster creations.\n\n1. Return to the GitLab Kubernetes Integration page and provide the Role ARN of the Provision Role we created earlier and click “Authenticate with AWS.”\n\n    ![Gitlab EKS Integration Page](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/gitlab_eks_integration_page.png)\n\n2. Once authenticated, you’ll have a page to set the parameters needed to set up your cluster as shown in the image below and click on “Create Kubernetes Cluster” to let GitLab do its magic!\n\n    The parameters you’ll need to provide are:\n    * **Kubernetes cluster name** - The name you wish to give the cluster.\n    * **Environment scope** - The [GitLab environment](https://docs.gitlab.com/ee/user/project/clusters/index.html#setting-the-environment-scope) associated with this cluster; `*` denotes the cluster will be used for deployments to all environments.\n    * **Kubernetes version** - The Kubernetes version to use. Currently, the only version supported is 1.14.\n    * **Role name** - The service role we created earlier.\n    * **Region** - The [AWS region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in which the cluster will be created.\n    * **Key pair name** - Select the [key pair](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) that you can use to connect to your worker nodes if required.\n    * **VPC** - Select a [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) to use for your EKS Cluster resources.\n    * **Subnets** - Choose the [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) in your VPC where your worker nodes will run.\n    * **Security group** - Choose the [security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) to apply to the EKS-managed Elastic Network Interfaces that are created in your worker node subnets. AWS provides a default group, which can be used for the purpose of this guide. However, you are advised to setup up the right rules required for your resources.\n    * **Instance type** - The AWS [instance type](https://aws.amazon.com/ec2/instance-types/) of your worker nodes.\n    * **Node count** - The number of worker nodes.\n    * **GitLab-managed cluster** - Leave this checked if you want [GitLab to manage namespaces and service accounts](https://docs.gitlab.com/ee/user/project/clusters/index.html#gitlab-managed-clusters) for this cluster.\n\n    ![Gitlab EKS Integration Page](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/gitlab_eks_integration_post_auth.png)\n\n3. The cluster creation process will take approximately 10 minutes. Once done you can proceed to install some predefined applications. At the very least, you need to install the following:\n    - **Helm Tiller**: This is required to install the other applications.\n    - **Ingress**: This provides SSL termination, load balancing and name-based virtual hosting you your applications. It acts as a web proxy for your application, which is useful when using AutoDevOps or deploying your own apps.\n    - **Cert Manager**: This is a native Kubernetes certificate management controller, which helps in issuing certificates using Let’s Encrypt. You don’t need this if you want to use a custom Certificate issuer.\n    - **Prometheus**: GitLab uses the Prometheus integration for automatic monitoring of your applications to collect metrics from Kubernetes containers allowing you to understand what is going on from within the GitLab UI.\n\n    ![Gitlab EKS Integration Page](https://about.gitlab.com/images/blogimages/gitlab-eks-integration/gitlab_eks_integration_post_cluster.png)\n\n4. To make use of Auto Review Apps and Auto Deploy stages of [AutoDevOps](https://docs.gitlab.com/ee/topics/autodevops/quick_start_guide.html), you will need to specify a Base Domain name with a wild card DNS pointing to the Ingress Endpoint generated when you Install Ingress in the list of predefined apps.\n\n## Summary\n\nIn this tutorial, we looked at how GitLab integrates with Amazon EKS, allowing Kubernetes clusters to be created easily from the GitLab UI after setting the right permissions. As we’ve seen, developer productivity is greatly improved by no longer having to manually set up clusters. Also, the same cluster can be used for multiple projects when Amazon EKS is integrated with GitLab at the Group and Instance levels, thus making onboarding new projects a breeze. After integration, the possibilities of what developers can achieve is enormous.\n\nIn the next part of this tutorial, we will look at how to deploy your applications on an Amazon EKS cluster using AutoDevOps.\n",[1936,9,976],{"slug":2922,"featured":6,"template":683},"gitlab-eks-integration-how-to","content:en-us:blog:gitlab-eks-integration-how-to.yml","Gitlab Eks Integration How To","en-us/blog/gitlab-eks-integration-how-to.yml","en-us/blog/gitlab-eks-integration-how-to",{"_path":2928,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2929,"content":2935,"config":2942,"_id":2944,"_type":13,"title":2945,"_source":15,"_file":2946,"_stem":2947,"_extension":18},"/en-us/blog/gitlab-for-agile-portfolio-planning-project-management",{"title":2930,"description":2931,"ogTitle":2930,"ogDescription":2931,"noIndex":6,"ogImage":2932,"ogUrl":2933,"ogSiteName":670,"ogType":671,"canonicalUrls":2933,"schema":2934},"How to use GitLab for Agile portfolio planning and project management","GitLab provides features that are flexible enough to be used for scaled Agile portfolio planning and project management, regardless of the framework you choose.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669575/Blog/Hero%20Images/agilemultipleteams.jpg","https://about.gitlab.com/blog/gitlab-for-agile-portfolio-planning-project-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use GitLab for Agile portfolio planning and project management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Hernandez\"},{\"@type\":\"Person\",\"name\":\"Julie Byrne\"}],\n        \"datePublished\": \"2020-11-11\",\n      }",{"title":2930,"description":2931,"authors":2936,"heroImage":2932,"date":2939,"body":2940,"category":849,"tags":2941},[2937,2938],"Victor Hernandez","Julie Byrne","2020-11-11","\nMany organizations using GitLab want to understand how to best apply the various features to support [Agile project and portfolio management](/solutions/agile-delivery/) processes (PPM) at scale. These organizations use different Agile frameworks. In a previous blog post, we outlined [an approach for using GitLab for Agile software development](/blog/gitlab-for-agile-software-development/). Since the original post, we've continued to enhance functionality for lean/Agile portfolio planning and Agile project management. In this blog post, we’re updating recommendations for using Agile based on these enhancements and we describe how these features can be utilized for a variety of different scaling frameworks.\n\n## Agile software development at scale\n\nFirst, let’s take a look at a typical scaling model of [Agile software development](/topics/agile-delivery/) beyond the individual team level. Whether you’ve adopted a specific scaling framework such as the [Scaled Agile Framework (SAFe)](https://www.scaledagileframework.com/), [Disciplined Agile (DA)](https://www.pmi.org/disciplined-agile), [Large Scale Scrum (LeSS)](https://less.works/), or [Spotify](https://medium.com/scaled-agile-framework/exploring-key-elements-of-spotifys-agile-scaling-model-471d2a23d7ea), most scaling models have similarities in their approach, organizing Agile teams into teams of teams, and even into teams of teams of teams.\n\n![](https://about.gitlab.com/images/blogimages/team-teams2.png){: .medium.center}\n\nTypically, scaling frameworks use these types of labels to describe each level:\n\n| **Level** | **Common Names** | **Description** |\n| ----- | ----- | ----- |\n| Team | Scrum team, Kanban team, Squad | A cross functional group (including BA, Dev, Test, and other supporting roles) implementing stories and bug fixes for an application or set of applications|\n| Team of Teams | Program, Release Train, Tribe | A set of teams who plan together and coordinate efforts to implement features for a system involving one or more applications |\n| Team of Teams of Teams | Portfolio, Business Unit, Alliance | One or more programs with a shared set of strategic goals and themes, typically funded with a single budget |\n\nNow that we've reviewed the different levels of Agile at scale, let’s next think about what types of data and visibility are required for agility at each level.\n\nThe scrum master/project manager/tribe lead, product owner, and team members are part of the Team level that is focused on short-term planning, typically weekly to monthly. They will want:\n\n- A board view to show flow of work\n- Current and upcoming iteration plan\n- A task list for each work item\n- Visibility into team progress\n- Team predictability\n\nThe program manager/release train engineer, product manager/product area lead, and design lead guide the Team of Teams, with a focus is on mid-range planning, monthly to quarterly (or potentially a bit longer). They will want visibility into:\n\n- A prioritized feature list with anticipated business value captured\n- Feature roadmap\n- View of mid-range plan\n- Epic health\n- Progress against plan\n- Program predictability\n\nFinally, portfolio managers, business leaders, and chief architects perform strategic long-term planning, typically quarterly to annually or longer, at the Team of Teams of Teams level. They will want to see:\n\n- A list of long-term epics/initiatives/business projects, categorized by theme and/or strategic goals\n- The long-term strategic roadmap\n\n## How can we best support these needs using GitLab?\n\nFirst, we need to understand what GitLab object types to use for support the appropriate visibility at each level.\n\n| **GitLab Structure** | **Team** | **Team of Teams** | **Team of Teams of Teams** |\n| ----- | ----- | ----- | -----  |\n| Org structure | Project or sub-sub-group | Sub-group | Top level group |\n| Work items | Issue | Child epic | Parent epic |\n| Time boxes | Iteration | Milestone | Roadmap across milestones |\n\nIn GitLab, epics can be defined in a hierarchy to break down long-term epics into a set of shorter-term epics that can each be delivered by a single Team-of-Teams. While we will use a single parent-child epic hierarchy in this blog to keep things simple, you can use more levels of nesting. The lowest level of epic in the hierarchy would be linked to a set of issues to define the work each team will do in order to implement that epic. GitLab is very flexible and does not enforce a hierarchy. For example, when there are cases when an epic should be tracked at the portfolio level but be decomposed directly into issues, with no features in between, GitLab will allow you to do that linking directly without having to create dummy features in the middle.\n\n![](https://about.gitlab.com/images/blogimages/epic_hierarchy2.png){: .medium.center}\n\nWe recommend using [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to define epic types, e.g., you might define long-term epics to be portfolio epics, and decompose them into shorter-term features. Using _epic::portfolio-epic_ and _epic::feature_ will allow you to appropriately categorize and filter a list of epics and make sure that each epic exists in the appropriate location.\n\nA [group](https://docs.gitlab.com/ee/user/group/) can be used to organize projects. And groups can be nested, e.g., a parent group can contain multiple child groups, and each child group can have its own subgroups, etc. A GitLab [project](https://docs.gitlab.com/ee/user/project/) contains a single source code repository, issue tracker, and associated tools and functionality in order to collaborate on software development for that repository.\n\n![](https://about.gitlab.com/images/blogimages/group_project2.png){: .medium.center}\n\nNote: Group permissions are propagated down the tree from the top-level, so, e.g., a maintainer in the top-level group will have maintainer permissions in the entire group hierarchy.\n\nWe recommend that you use a nested group hierarchy to define your scaled organizational structure for Team of Teams of Teams, Team of Teams, and Teams. For example, consider an electronic banking program that is part of the digital services portfolio for a financial services provider. The electronic banking program might have separate teams that work on web, mobile, backend, and middleware. You would use a parent group for the digital services portfolio, a sub-group for the electronic banking program, and a separate project within the sub-group for each team.\n\n![](https://about.gitlab.com/images/blogimages/group_project_example.png){: .medium.center}\n\nGenerally speaking, parent epics would be defined within the top-level group since they define work that can span the sub-groups. Each parent epic would be broken down into multiple child epics, each of which is defined within the appropriate child group (representing a Team-of-Teams).\n\nThe example above is simple in that each Agile team is working on a single repository. But what if that’s not the case?\n\n- If a single team works exclusively on multiple repositories (but no other team works on the them), then create a sub-group for the team, and include each repo as a project.\n- If multiple teams work on a collection of repositories, use the Team of Teams group for collaboration across all Teams in all projects, and use individual scoped labels for each team to track their issues on filtered boards.\n\nGitLab provides an [issue tracker](https://docs.gitlab.com/ee/user/project/issues/) for any types of issues you want to manage and track. Typically, for Agile software development teams, these would be things like user stories and defects. We recommend that you use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to define the different issue types, for ease of filtering and reporting. The great news is that you can have as many or as few issue types as you see fit. GitLab does not provide the ability to define a custom schema for each issue type as that tends to complicate both administration and usage of issues and gets in the way of software development. Instead, use [custom issue templates](https://docs.gitlab.com/ee/user/project/description_templates.html#creating-issue-templates) to provide guidance to the end user on what types of information should be captured for each issue type, and even to set labels automatically on the issue as it is created.\n\nGitLab makes project status reporting easy with the issue [health status](https://docs.gitlab.com/ee/user/project/issues/#health-status). Each issue can have a status of `On Track`, `Needs Attention`, or `At Risk`. The health statuses of all issues for an epic are reported within the epic details for a quick snapshot of the health of the overall epic.\n\nFinally, we have to define timeboxes to use for our planning cadences. We tend to use [milestones](https://docs.gitlab.com/ee/user/project/milestones/) for our mid-range planning, i.e., a quarterly development plan. Define the milestone at the highest group level that will be using that cadence, e.g., if the entire portfolio plans on a quarterly basis, then the planning milestone should be defined at the top-level group level. If each team of teams plans on a different mid-range cadence, then you would want to define separate milestones at each child group level. Note that milestones get added directly to issues, so the projects that will use the milestones must be within the group hierarchy where the milestone is defined. One other consideration is that an issue can only have a single milestone associated with it, so it’s a good idea to align on the best use of milestones across the Team of Teams before starting to use them.\n\nWe recently released our [iterations MVC](https://gitlab.com/groups/gitlab-org/-/epics/4012) in GitLab! This allows you to define, at the group or individual project level, short-term cadences that a team or set of teams uses for planning and tracking their work. While, as an MVC, iteration functionality is not yet as robust as milestones, we do have plans for enhancements including using iterations on boards, filtering issue lists by iteration, and burnup/burndown charts. You can view the epic [Iterations in GitLab](https://gitlab.com/groups/gitlab-org/-/epics/2422) to learn more about planned enhancements. And that doesn’t mean Kanban teams are out of luck. We innately support Kanban in GitLab, too, with issue boards, so you can have a mix of iteration based teams and continuous flow teams working together.\n\n## Agile PPM: putting it all together\n\nHere’s how the GitLab features come together to support Agile at scale to allow planning from the highest level down to the individual team, and to provide visibility, traceability, and reporting at each level:\n\n![](https://about.gitlab.com/images/blogimages/epic_hierarchy.png){: .medium.center}\n\nYou can also check out the video below to see how the structure comes together in GitLab.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/5J0bonGoECs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Read more about Agile at GitLab\n\n- [See more information about our Agile delivery solution](/solutions/agile-delivery/)\n- [Build your Agile roadmap in GitLab](https://docs.gitlab.com/ee/user/group/roadmap/)\n- [Learn how to create iterations](https://docs.gitlab.com/ee/user/group/iterations/)\n\nCover image by [Martin Sanchez](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/MD6E2Sv__iA)\n{: .note}\n",[1164,9,894,829],{"slug":2943,"featured":6,"template":683},"gitlab-for-agile-portfolio-planning-project-management","content:en-us:blog:gitlab-for-agile-portfolio-planning-project-management.yml","Gitlab For Agile Portfolio Planning Project Management","en-us/blog/gitlab-for-agile-portfolio-planning-project-management.yml","en-us/blog/gitlab-for-agile-portfolio-planning-project-management",{"_path":2949,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2950,"content":2956,"config":2962,"_id":2964,"_type":13,"title":2965,"_source":15,"_file":2966,"_stem":2967,"_extension":18},"/en-us/blog/gitlab-for-agile-software-development",{"title":2951,"description":2952,"ogTitle":2951,"ogDescription":2952,"noIndex":6,"ogImage":2953,"ogUrl":2954,"ogSiteName":670,"ogType":671,"canonicalUrls":2954,"schema":2955},"How to use GitLab for Agile software development","How Agile artifacts map to GitLab features and how an Agile iteration looks in GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use GitLab for Agile software development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2018-03-05\",\n      }",{"title":2951,"description":2952,"authors":2957,"heroImage":2953,"date":2958,"body":2959,"category":1228,"tags":2960,"updatedDate":2961},[1550,1225],"2018-03-05","Ever wondered if GitLab supports [Agile methodology](https://about.gitlab.com/solutions/agile-delivery/)? If you're considering using GitLab it might not be obvious how the DevSecOps platform's features correspond with Agile artifacts, so we've broken it down for you.\n\nAgile is one of the most important and transformative methodologies introduced to the software engineering discipline in recent decades. While not everyone can agree on the detailed terminology of Agile concepts, it has nonetheless made a significant positive impact on software development teams efficiently creating customer-centric products through [Agile software development](https://about.gitlab.com/topics/agile-delivery/) and delivery processes.\n\nGitLab is designed to be flexible enough to adapt to your software development methodology, whether Agile or influenced by it. In this post, we'll show a simple mapping of Agile artifacts to GitLab features, and explain how customers have successfully run high-performing [Agile software delivery teams](https://about.gitlab.com/solutions/agile-delivery/) with GitLab.\n\n## Mapping Agile artifacts to GitLab features\n\n### Agile artifact → GitLab feature\n\n- User story –> [Issues](https://docs.gitlab.com/ee/user/project/issues/)\n- Task –> [Tasks](https://docs.gitlab.com/ee/user/tasks.html)\n- Epic –> [Epics](https://docs.gitlab.com/ee/user/group/epics/)\n- Points and estimation –> [Issue weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html)\n- Product backlog –> [Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Sprint/iteration –> [Iterations](https://docs.gitlab.com/ee/user/group/iterations/)\n- Agile board –> [Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Team workload –> [Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Burndown chart –> [Burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## An Agile iteration with GitLab\n\n### User stories → GitLab Issues\n\nIn Agile software development methodology, you often start with a user story that captures a single feature to deliver business value for users. In GitLab, an [issue](https://docs.gitlab.com/ee/user/project/issues/) serves this purpose with ease. GitLab Issues are essential for Agile teams, providing an effective method to manage tasks and projects. Software developers can create, assign, and track issues, ensuring clear accountability and progress visibility. Issues come with robust metadata such as assignee, iteration, weight, and labels, which enhances task prioritization and workflow management throughout the software development process. Additionally, team collaboration on issues is streamlined with discussion threads, attachments, and real-time updates, enabling effective communication and teamwork.\n\n![screenshot of a GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nThe GitLab Issue has a title and a description area in the middle, providing a space to document any details, such as the business value and relevant personas in a user story. The sidebar at the right provides integration with other Agile-compatible features like the epic parent that the issue belongs to, the iteration in which the issue is to be worked on, and the weight of the issue, reflecting the estimated effort.\n\n### Task → Tasks\n\nOften, a user story is further separated into individual tasks. GitLab [Tasks](https://docs.gitlab.com/ee/user/tasks.html) streamline project management by allowing Agile teams to break down user stories into discrete pieces of work. This feature supports the Agile framework by enabling software developers to create, assign, and track tasks within their projects. By integrating task management directly into GitLab, teams can maintain a cohesive workflow, ensuring all software development project activities are easily tracked and managed.\n\n![screenshot showing precise task management and project tracking using GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nEnhance user value by enabling precise task management and project tracking using GitLab. Tasks are equipped with the same metadata as issues, including assignee, iteration, weight, labels, time tracking, and collaboration features. This comprehensive feature set allows Agile teams and project managers to manage workloads effectively, prioritize tasks, and ensure seamless collaboration among software developers.\n\n### Epics → GitLab Epics\nIn the other direction, some Agile practitioners specify an abstraction above user stories, often called an epic, that indicates a larger user flow consisting of multiple features. In GitLab, an [epic](https://docs.gitlab.com/ee/user/group/epics/) also contains a title and description, much like an issue, but it allows you to attach multiple child issues to it to indicate that hierarchy.\n\n![screenshot of nested GitLab Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nGitLab Epics allows Agile teams to organize and manage large projects efficiently by nesting epics up to nine layers deep. This hierarchical structure provides a clear view of the project's roadmap, helping software developers and project managers break down complex initiatives into manageable components. By utilizing child and [linked epics](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html), teams can better track progress, dependencies, and project milestones, enhancing collaboration and ensuring cohesive agile delivery.\n\n### Product backlog → GitLab Issue Boards\n\nThe product or business owners typically create these user stories to reflect the needs of the business and customers. They are prioritized in a product backlog to capture urgency and desired order of development. The product owner communicates with stakeholders to determine the priorities and constantly refines the backlog.  In GitLab, an [issue board](https://docs.gitlab.com/ee/user/project/issue_board.html) organized with iterations as lists offers a drag-and-drop workflow experience that allows you to effortlessly prioritize your backlog and assign stories to an upcoming sprint.\n\n![Gif of GitLab Issue Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\n### Sprints → GitLab iterations\n\nA sprint represents a finite time period in which the work is to be completed, which may be a week, a few weeks, or perhaps a month or more. The product owner and the development team meet to decide the work that is in scope for the upcoming sprint. GitLab's [iterations](https://docs.gitlab.com/ee/user/group/iterations/) feature supports this: Assign iterations a start date and a due date to capture the time period of the iteration. The team then puts issues into the sprint by assigning them to that particular iteration.\n\nBy using iterations, you leverage GitLab’s enhanced capabilities for Agile project management, providing better visibility and control over your Agile planning and delivery.\n\n### Points and estimation → GitLab issue weight\n\nAlso in this meeting, user stories are communicated, and the level of technical effort is estimated for each in-scope user story. In GitLab, issues have a [weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) attribute, which you would use to indicate the estimated effort.\n\nIn this meeting (or in subsequent ones), user stories are further broken down to technical deliverables, sometimes documenting technical plans and architecture. In GitLab, this information can be documented in the issue, or in the [merge request description](https://docs.gitlab.com/ee/user/project/merge_requests/), as the merge request is often the place where technical collaboration happens.\n\nDuring the sprint (GitLab iteration), software development team members pick up user stories to work on, one by one. In GitLab, issues have assignees. So you would [assign](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html) yourself to an issue to reflect that you are now working on it. We'd recommend that you [create an empty and linked-to-issue merge request](https://docs.gitlab.com/ee/user/project/issues/) right away to start the technical collaboration process, even before creating a single line of code.\n\n### Agile board → GitLab Issue Boards\n\nThroughout the sprint, issues move through various stages, such as `Ready for dev`, `In dev`, `In QA`, `In review`, `Done`, depending on the workflow in your particular organization. Typically these are columns in an Agile board. In GitLab, [issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html) allow you to define your stages and enable you to move issues through them. The team can [configure the board](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration) with respect to the iteration and other relevant attributes. During daily stand-ups, the team looks at the board together, to see the status of the sprint from a workflow perspective.\n\n![screenshot of GitLab Issue Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\n\nThe GitLab Issue Board also pulls in issues dynamically, similar to the GitLab issue list. But it allows for more flexible workflows. You can set up individual lists in the board, to reflect Agile board stages. Your team can then control and track user stories as they move from for example, `Ready for dev`, all the way to `Released to production`.\n\n### Team workload → GitLab Issue Boards\n\nAgile teams can optimize their workflows by creating issue boards with lists scoped to assignees in GitLab. This feature allows you to visualize the distribution of tasks among team members, enhancing Agile delivery. To set it up, navigate to your project or group, create a new board in the \"Boards\" section, and [add lists](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) for each assignee. Assign issues to team members, and they will automatically appear in the corresponding lists. This dynamic view empowers balanced workloads and effective task management.\n\n![Screenshot of organized GitLab Issue Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097468380.png)\n\nOrganize an issue board by assignee or by squad using [scoped labels]. GitLab’s Issue Board is incredibly diverse and supports workflows across the software development lifecycle.\n\n### Burndown charts → GitLab Burndown Charts\n\nThe development team wants to know if they are on track in real time, and mitigate risks as they arise. GitLab provides [burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), allowing the team to visualize the work scoped in the current sprint \"burning down\" as they are being completed.\n\nToward the end of the sprint, the development team demos completed features to various stakeholders. With GitLab, this process is made simple using [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) so that even code not yet released to production, but in various testing, staging or UAT environments can be demoed. Review Apps and [CI/CD features](https://docs.gitlab.com/ee/ci/) are integrated with the merge request itself.\n\nThese same tools are useful for Developers and QA roles to maintain software quality, whether through automated testing with CI/CD, or manual testing in a Review App environment.\n\n![Screenshot of GitLab Burndown Chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097468381.png)\n\nThe GitLab Burndown Chart allows a team to track scoped work \"burning down,\" as they are being completed in a sprint. This allows you to react to risks sooner and adapt accordingly, for example, informing your business stakeholders that certain features are anticipated to be delayed to a future sprint.\n\nTeam retrospectives at the end of the sprint can be documented in GitLab’s [wiki](https://docs.gitlab.com/ee/user/project/wiki/index.html), so that lessons learned and action items are tracked over time. During the actual retrospective, the team can look at the [iteration report](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report), which displays the burndown chart and other statistics of the completed sprint.\n\n## Start your Agile journey with GitLab\nReady to elevate your Agile project management? GitLab offers a comprehensive suite of features tailored to Agile teams, software developers, and project managers, ensuring seamless collaboration and efficient workflows. Explore our pricing options, start a free trial and discover how GitLab can transform your Agile delivery processes.\n\n> [Learn more about GitLab Agile planning](https://about.gitlab.com/pricing/) and get started on your journey today!\n",[1164,9,894,829],"2024-07-09",{"slug":2963,"featured":6,"template":683},"gitlab-for-agile-software-development","content:en-us:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","en-us/blog/gitlab-for-agile-software-development.yml","en-us/blog/gitlab-for-agile-software-development",{"_path":2969,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2970,"content":2975,"config":2981,"_id":2983,"_type":13,"title":2984,"_source":15,"_file":2985,"_stem":2986,"_extension":18},"/en-us/blog/gitlab-helm-package-registry",{"title":2971,"description":2972,"ogTitle":2971,"ogDescription":2972,"noIndex":6,"ogImage":1055,"ogUrl":2973,"ogSiteName":670,"ogType":671,"canonicalUrls":2973,"schema":2974},"Introducing the GitLab Helm Package Registry","Develop and deploy cloud native applications with a built-in Helm registry.","https://about.gitlab.com/blog/gitlab-helm-package-registry","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing the GitLab Helm Package Registry\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"William Chia\"}],\n        \"datePublished\": \"2021-07-26\",\n      }",{"title":2971,"description":2972,"authors":2976,"heroImage":1055,"date":2978,"body":2979,"category":678,"tags":2980},[2977],"William Chia","2021-07-26","\n\nCloud native application architectures use containerization, microservices, and Kubernetes to run reliably at cloud-scale. With a built-in container registry and Kubernetes integration, GitLab is the best way to develop and deploy cloud native applications. [GitLab version 14.1](/releases/2021/07/22/gitlab-14-1-released/) also includes a Helm registry, which allows users to publish, install, and share Helm charts and packages from within our single application for the entire DevOps lifecycle.\n\n### What is Helm?\n\nHelm is a package manager for Kubernetes. A Chart is a Helm package that contains the resource definitions required to run an application inside a Kubernetes cluster. Helm allows you to manage complex applications by storing the application definition in a chart that can be versioned, shared, and collaborated on.\n\n### The differences between Helm Registry and Git\n\nWhy not simply store your Helm charts in a Git repository? After all, charts are YAML files that can be stored, versioned, and collaborated on like code.\n\nFor small projects and simple applications, it can be convenient to store the Helm chart in the same Git repository as the application code. However, this method starts to become unruly as the code scales. Applying this model with microservices architecture means you'd have many different charts spread out across many different repositories. Cluster-wide upgrades would certainly be a challenge. And sharing charts with other teams would require you to also grant permission to the code repository.\n\n### Comparing Helm registry and container registry\n\nAnother option for storing Helm charts is to use an OCI registry, like the GitLab Container Registry. However, this feature is new to Helm 3 and requires running Helm in experimental mode. Many organizations, especially those in highly regulated environments, prefer not to expose themselves to the additional risk of an experimental feature.\n\n### A built-in, dedicated Helm registry\n\nA Helm registry offers a centralized repository to store and share charts so large organizations can manage many complex applications in a controlled manner. The main benefits of having a dedicated registry are the security, efficiency, and reliability.\n\nWhen it comes to security, having all of the charts in one central location means they can be [systematically scanned for vulnerabilities](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). This is much more difficult to manage if your charts are stored in multiple locations. Similarly, user account and permission management is much easier to manage from a single location.\n\nA central registry also makes it much easier to distribute charts throughout your organization. Large organizations will often have a center of excellence that is responsible for creating, maintaining, and distributing charts to many different teams throughout the organization. Enabling a safe way to share charts and control access is critical.\n\nGitLab users can host all Helm charts from one central project, allowing users to control user access with SSO/SAML and authorization with deploy tokens, job tokens, or personal access tokens. Not to mention, the GitLab.com Package stage is 99.95% available.\n\n### How to get started\n\nThe new Helm Registry is currently at \"viable\" maturity. We do not recommended using it for production but it can be used for testing and planning. Visit the [Helm Repository docs](https://docs.gitlab.com/ee/user/packages/helm_repository/) for step-by-step commands to authenticate the registry and publish and install packages.\n\n### Contribute to the Helm Registry\n\nThe first iteration of the Helm registry was contributed to GitLab by community member [Mathieu Parent](https://gitlab.com/sathieu). We'd love your input and feedback and we continue to improve and mature the Helm registry capabilities. This [GitLab Epic outlines the path to make the Helm chart registry complete](https://gitlab.com/groups/gitlab-org/-/epics/6366). Comment in the epic and associated issues with your thoughts and feedback. As always, [code contributions](/community/contribute/development/) are welcome.\n",[829,851,9,1936],{"slug":2982,"featured":6,"template":683},"gitlab-helm-package-registry","content:en-us:blog:gitlab-helm-package-registry.yml","Gitlab Helm Package Registry","en-us/blog/gitlab-helm-package-registry.yml","en-us/blog/gitlab-helm-package-registry",{"_path":2988,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":2989,"content":2994,"config":2999,"_id":3001,"_type":13,"title":3002,"_source":15,"_file":3003,"_stem":3004,"_extension":18},"/en-us/blog/gitlab-incident-timelines",{"title":2990,"description":2991,"ogTitle":2990,"ogDescription":2991,"noIndex":6,"ogImage":1055,"ogUrl":2992,"ogSiteName":670,"ogType":671,"canonicalUrls":2992,"schema":2993},"How to leverage GitLab incident timelines","What actually happened before, during, and after the incident? Now it's easier to keep track.","https://about.gitlab.com/blog/gitlab-incident-timelines","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to leverage GitLab incident timelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2022-10-18\",\n      }",{"title":2990,"description":2991,"authors":2995,"heroImage":1055,"date":2996,"body":2997,"category":1513,"tags":2998},[2114],"2022-10-18","\n\n_When you're working on an incident, every second counts._ Team members and leadership are looking for updates. Any interruption can make you lose track of where you were. Finding the root cause or working on a code change to resolve the incident requires time and focus. After the incident is resolved, you'll need to provide a summary of what happened during the post-incident review. How can you provide updates and keep track of important events while working on the incident?\n\n## Incident timelines with GitLab\n\nGitLab recently launched [incident timelines](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html).  Incident timelines are the single source of truth (SSoT) for key updates and events that happen during an incident. They typically include things like when the incident was declared, who is actively working on the incident, and other important events during the incident; i.e. \"Disabling Canary to test a hot fix.\"\n\nUpdating the timeline needs to be done quickly and efficiently. Use GitLab quick actions to add multiple timeline items programmatically.\n\n![quick_action](https://about.gitlab.com/images/blogimages/incident-mgmt/incident_timeline_quick_actions.png)\n\nOr [add any comment from the incident to the timeline](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html#from-a-comment-on-the-incident) by clicking on the clock icon. This helps avoid the unnecessary shoulder taping for updates so users can focus on firefighting.  \n\nWhen you're at the end of your on-call shift, you can share the timeline as you hand off the incident to summarize what's happened so far. If you've missed adding something important to the timeline, you can always add the event retroactively and post-date it to the correct time. When you wake up for your next shift, you can review what happened while you were away.\n\n## Keeping a record with incident timelines\n\nOnce an incident has been resolved, it can be hard to piece together what actually happened. Sometimes, post-incident reviews don't happen until days after you've worked on the incident. _Did the incident originate from an alert or was it from a customer email?_ _Did we meet our Service Level Agreement (SLA)?_ Since you've kept track along the way, incident timelines can be a quick way to refresh your memory on what happened during the incident.  \n\nEstablishing incident timelines as a SSoT minimizes the time spent on incident \"paperwork.\" This gives you time to focus on resolving the incident. Once the incident resolves you can review with team members to minimize the chance of the same incident occurring again.\n\nThe [GitLab Infrastructure Team](/handbook/engineering/infrastructure/#dogfooding) has been testing [dogfooding](https://www.urbandictionary.com/define.php?term=Dog%20fooding) and using incident timelines. We'd love to hear about how you are constructing and recording what happens during an incident. You can also take a look at [Improving the Incident Timeline](https://gitlab.com/groups/gitlab-org/-/epics/8256) and help influence what we build next.\n",[701,829,9],{"slug":3000,"featured":6,"template":683},"gitlab-incident-timelines","content:en-us:blog:gitlab-incident-timelines.yml","Gitlab Incident Timelines","en-us/blog/gitlab-incident-timelines.yml","en-us/blog/gitlab-incident-timelines",{"_path":3006,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3007,"content":3012,"config":3017,"_id":3019,"_type":13,"title":3020,"_source":15,"_file":3021,"_stem":3022,"_extension":18},"/en-us/blog/gitlab-jetbrains-neovim-plugins",{"title":3008,"description":3009,"ogTitle":3008,"ogDescription":3009,"noIndex":6,"ogImage":906,"ogUrl":3010,"ogSiteName":670,"ogType":671,"canonicalUrls":3010,"schema":3011},"GitLab plugins for JetBrains and Neovim now available in Beta","GitLab plugins for JetBrains IDEs and Neovim are now available in Beta, bringing GitLab Duo Code Suggestions to more software development environments.","https://about.gitlab.com/blog/gitlab-jetbrains-neovim-plugins","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab plugins for JetBrains and Neovim now available in Beta\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2023-07-25\",\n      }",{"title":3008,"description":3009,"authors":3013,"heroImage":906,"date":3014,"body":3015,"category":806,"tags":3016},[2370],"2023-07-25","\n\n_This blog post is the latest in an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). Start with the first blog post: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab._\n\nIn June, we shared our plans to [extend AI-powered code suggestions](/blog/extending-code-suggestions/) to more IDEs, thereby continuing to help enhance developer productivity. A few weeks ago, we [announced](/blog/gitlab-visual-studio-extension/) the availability of our [extension for Visual Studio](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio). Now, we're adding support for JetBrains and Neovim with official plugins to further extend the reach of GitLab Duo Code Suggestions and help enhance developer productivity across even more development environments.\n\nThese new GitLab plugins for both JetBrains and Neovim support [GitLab Duo](https://about.gitlab.com/gitlab-duo/) Code Suggestions for both [GitLab SaaS](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#enable-code-suggestions-on-gitlab-saas) and [GitLab self-managed](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#enable-code-suggestions-on-self-managed-gitlab).\n\n## GitLab for JetBrains IDEs\nYou can download the GitLab for JetBrains plugin from the [JetBrains Plugin Marketplace](https://plugins.jetbrains.com/plugin/22325-gitlab) or from directly within your IDE by visiting `Settings` -> `Plugins` and then searching for `GitLab`. Once you've installed the plugin, follow the [setup instructions](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin#setup) to configure authentication and get started.\n\n![JetBrains GitLab Duo Code Suggestions Settings](https://about.gitlab.com/images/blogimages/jetbrains-code-suggestions-settings.png)\n\nYou can verify if the extension is connected and working by checking the status bar icon. If everything looks good, you're ready to start receiving code suggestions as you work. Just start typing and GitLab Duo will automatically provide you suggestions inline. Press `Tab` to accept the suggestions or keep typing to receive new suggestions.\n\n![JetBrains GitLab Duo Code Suggestions](https://about.gitlab.com/images/blogimages/jetbrains-code-suggestions-ghost-text.png)\n\nWe look forward to hearing from you about this initial release! You can provide feedback or report any issues you're having in our [feedback issue](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/38).\n\n## GitLab for Neovim\nThe [GitLab for Neovim plugin](https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim) can be found on GitLab and you can [follow the instructions to get started](https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim#getting-started). Once you've downloaded the plugin, there are [configuration options](https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim#configuration) available to help customize your experience.\n\nOnce you've configured the plugin you'll be able to receive suggestions directly within the UI. Check out our demo video below to learn more about the plugin.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/PRSPQvbFquU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWe're continuing to iterate on our Neovim plugin. You can provide feedback or report any issues you're having in our [feedback issue](https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim/-/issues/22).\n\n## Iterating on AI/ML features\nThese new additions to our family of editor extensions join our existing extensions for [Visual Studio](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio) and [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow). We plan to continue iterating to make the GitLab Duo Code Suggestions experience even better.\n\nWe're also continuing our work on a [GitLab Language Server for Code Suggestions](https://gitlab.com/gitlab-org/editor-extensions/gitlab-language-server-for-code-suggestions), which will allow us to standardize and iterate faster on our IDE extensions, and will enable users of IDEs and code editors to use GitLab Duo Code suggestions even if an official extension isn't available. We look forward to providing more documentation and working with the community on this project in the future.\n\nThese efforts are just the start of how we're incorporating GitLab Duo capabilities throughout the [software development lifecycle](/blog/what-the-ml-ai/) to help GitLab users become more efficient and effective. As we continue to identify painful and time-consuming tasks that are ideal for AI-assisted features, we'll continue to share updates, tutorials, and demos through this blog series.\n\nCheckout GitLabs 16.2 release to see what's new with [Code Suggestions](https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/#gitlab-duo-code-suggestions-improvements-powered-by-google-ai).\n\nInterested in using GitLab Duo features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and we'll keep you updated.\n\nContinue reading our \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":3018,"featured":6,"template":683},"gitlab-jetbrains-neovim-plugins","content:en-us:blog:gitlab-jetbrains-neovim-plugins.yml","Gitlab Jetbrains Neovim Plugins","en-us/blog/gitlab-jetbrains-neovim-plugins.yml","en-us/blog/gitlab-jetbrains-neovim-plugins",{"_path":3024,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3025,"content":3031,"config":3037,"_id":3039,"_type":13,"title":3040,"_source":15,"_file":3041,"_stem":3042,"_extension":18},"/en-us/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost",{"title":3026,"description":3027,"ogTitle":3026,"ogDescription":3027,"noIndex":6,"ogImage":3028,"ogUrl":3029,"ogSiteName":670,"ogType":671,"canonicalUrls":3029,"schema":3030},"GitLab native secrets manager boosts supply chain security","GitLab is building a secrets manager that is key to providing an end-to-end, cloud-agnostic approach to the management of sensitive information.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664530/Blog/Hero%20Images/AdobeStock_282096522.jpg","https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab native secrets manager to give software supply chain security a boost\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jocelyn Eillis\"}],\n        \"datePublished\": \"2024-05-20\",\n      }",{"title":3032,"description":3027,"authors":3033,"heroImage":3028,"date":2057,"body":3035,"category":704,"tags":3036},"GitLab native secrets manager to give software supply chain security a boost",[3034],"Jocelyn Eillis","In a constantly evolving digital world, keeping the software supply chain and sensitive information secure is a priority for organizations of all sizes. To reduce the complexity associated with managing multiple infrastructure tools, GitLab plans to release a native secrets manager later this year that will enable users to manage and scale secrets across the DevSecOps platform. This cloud-agnostic, built-in solution has a [similar look and feel to the CI Variables experience](https://gitlab.com/groups/gitlab-org/-/epics/11373) in GitLab, which will make it easier to learn and, therefore, lower friction to adopt.\n\n## What are secrets and a secrets manager?\n\n- A **secret** is a piece of data that acts as a credential to authenticate with systems or services. Secrets are highly sensitive and should be protected from unauthorized use or exposure. Examples of secrets include passwords, API keys, and certificates.\n\n- A **secrets manager** is a centralized tool that stores and manages these secrets throughout their lifecycle. Secrets are stored using unique encryption keys in order to achieve isolation, in this case, across GitLab.\n\n## Current state of secrets management within GitLab\n\nBecause GitLab does not currently have a native secrets manager, we have recommended using a third-party solution. Users leverage third-party secrets storage providers through our [OIDC connection method](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html) (Free tier) or via native integrations (currently available for [HashiCorp Vault](https://docs.gitlab.com/ee/ci/secrets/#use-vault-secrets-in-a-ci-job), [Azure Key Vault](https://docs.gitlab.com/ee/ci/secrets/azure_key_vault.html), and [Google Secret Manager](https://docs.gitlab.com/ee/ci/secrets/gcp_secret_manager.html) (Premium and Ultimate tier). However, we understand a third-party provider can be resource-prohibitive for some users because of the overhead for setup and managing user roles and integrations, as well as additional costs.\n\n## About the GitLab secrets manager\n\nThe GitLab secrets manager will allow customers to store sensitive credentials within the GitLab DevSecOps platform, which will simplify management and reduce risk of leaking sensitive information. Our [initial release of the native secrets manager](https://gitlab.com/groups/gitlab-org/-/epics/10723) will be focused on bringing secrets management to the CI workflow, then workflows across all of GitLab. We have prioritized options to use an [open source secrets manager](https://openbao.org/) with the GitLab UI. This enables us to stay true to our open core roots while minimizing our security attack surface as an extra layer of protection. \n\nGitLab plans to have the native secrets manager available in Beta release by year-end.\n\n### Aligning secrets management with GitLab Security\n\nAs we continue to iterate, the GitLab secrets manager will integrate with existing security capabilities. Our goal is to automate when possible, while still empowering the user to own security decisions by providing prompts or calls-to-action. Here are some areas we have identified for alignment: \n\n- **Secret detection.** [Detected secrets](https://gitlab.com/groups/gitlab-org/-/epics/13607) can automatically be placed in the native secrets manager. Instances of the secrets in the pipeline will be replaced automatically with the new secret key. \n\n- **Access tokens.** When access tokens are generated, [they will automatically be placed in the secrets manager](https://gitlab.com/gitlab-org/gitlab/-/issues/460606). This eliminates the need for the user to manually create a secret for each access token. This also eliminates the need to expose the value of the token at creation. A similar use case can be applied to [deploy keys](https://gitlab.com/gitlab-org/gitlab/-/issues/432522). \n\n- **Compliance.** [Advancing audit logging](https://about.gitlab.com/direction/govern/compliance/audit-events/#how-we-will-prioritize-adding-new-audit-events) within GitLab makes it easier for admins and security teams to identify access, changes, and deletion for each secret, all within the existing GitLab [audit events](https://docs.gitlab.com/ee/administration/audit_event_types.html).  \n\n- **Secured artifacts.** Enabling a [verifiable way to link job artifacts back to their source code](https://gitlab.com/groups/gitlab-org/-/epics/6207) is critical to ensuring integrity of the software supply chain. Attestations require signing and authentication to verify authenticity in the process and the secrets manager will secure these credentials within GitLab.\n\n## Share your feedback\n\nAt GitLab, we understand a single tool does not fit all. While we are building a native solution, we are also committed to continuing to support our existing third-party integrations for Hashicorp’s Vault, Azure Key Vault, and Google Secret Manager. We envision an ecosystem where multiple secret management solutions are available to customers, ensuring the best-fit solution for our customers’ use cases. \n\nInterested in joining the conversation to shape the future of GitLab’s offerings in the secrets management space? Please [leave us a comment](https://gitlab.com/gitlab-org/gitlab/-/issues/460757). You also can view our current [direction page](https://about.gitlab.com/direction/govern/pipeline_security/secrets_management/) for the latest category updates and follow our progress to building our own secrets manager in our [MVC epic](https://gitlab.com/groups/gitlab-org/-/epics/10723). \n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[704,9,478],{"slug":3038,"featured":6,"template":683},"gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost","content:en-us:blog:gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost.yml","Gitlab Native Secrets Manager To Give Software Supply Chain Security A Boost","en-us/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost.yml","en-us/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost",{"_path":3044,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3045,"content":3051,"config":3059,"_id":3061,"_type":13,"title":3062,"_source":15,"_file":3063,"_stem":3064,"_extension":18},"/en-us/blog/gitlab-now-supports-sha256-repositories",{"title":3046,"description":3047,"ogTitle":3046,"ogDescription":3047,"noIndex":6,"ogImage":3048,"ogUrl":3049,"ogSiteName":670,"ogType":671,"canonicalUrls":3049,"schema":3050},"GitLab now supports SHA256 repositories","Try this experimental security feature to create test projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667390/Blog/Hero%20Images/blog-image-template-1800x945__19_.png","https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab now supports SHA256 repositories\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"John Cai\"}],\n        \"datePublished\": \"2024-08-19\",\n      }",{"title":3046,"description":3047,"authors":3052,"heroImage":3048,"date":3054,"body":3055,"category":3056,"tags":3057},[3053],"John Cai","2024-08-19","Previously, we announced how GitLab [supports SHA256 repositories on\nthe backend in Gitaly](https://about.gitlab.com/blog/sha256-support-in-gitaly/). Now, we've added the ability to create new GitLab projects with the SHA256 hashing algorithm.\n\nYou can do so on the project creation page under “Experimental settings.”\n\n**Note: This feature is experimental and should only be used to create test projects.**\n\nWhile experimenting with this security feature, if you find any anomalies in the application,\nplease help us out and [file an issue with your feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=SHA256%20Bug).\n","bulletin-board",[704,3058,183,9],"git",{"slug":3060,"featured":6,"template":683},"gitlab-now-supports-sha256-repositories","content:en-us:blog:gitlab-now-supports-sha256-repositories.yml","Gitlab Now Supports Sha256 Repositories","en-us/blog/gitlab-now-supports-sha256-repositories.yml","en-us/blog/gitlab-now-supports-sha256-repositories",{"_path":3066,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3067,"content":3073,"config":3078,"_id":3080,"_type":13,"title":3081,"_source":15,"_file":3082,"_stem":3083,"_extension":18},"/en-us/blog/gitlab-package-roadmap-for-2024",{"title":3068,"description":3069,"ogTitle":3068,"ogDescription":3069,"noIndex":6,"ogImage":3070,"ogUrl":3071,"ogSiteName":670,"ogType":671,"canonicalUrls":3071,"schema":3072},"GitLab Package roadmap for 2024","GitLab is launching new package and container registry features to help enterprise customers consolidate on GitLab for artifact management.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669103/Blog/Hero%20Images/AdobeStock_243118595.jpg","https://about.gitlab.com/blog/gitlab-package-roadmap-for-2024","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Package roadmap for 2024\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-01-16\",\n      }",{"title":3068,"description":3069,"authors":3074,"heroImage":3070,"date":3075,"body":3076,"category":701,"tags":3077},[1040],"2024-01-16","_TLDR; In 2024, GitLab will deliver a dependency proxy for Maven, npm, PyPI, and NuGet (stretch). In addition, we'll expand the dependency proxy for containers to work with any external container registry, not just public Docker Hub accounts._\n\n2023 is nearly over. I'd like to take a minute to share some features for [GitLab Package](https://about.gitlab.com/stages-devops-lifecycle/package/) to look forward to in 2024. These new features will enable enterprise customers to consolidate on GitLab for artifact management, and help save money on licensing costs for JFrog/Sonatype and improve the developer experience.\n\n## Package registry\n\nAs the product manager for the Package stage, I have spent the past four years talking to customers and prospects about how they can replace their Artifactory or Sonatype instance with GitLab Package. Although we have helped many smaller organizations to consolidate on GitLab, it's been a challenge to help larger, more complex organizations to do so. Why? Because larger organizations typically need to pull packages from multiple repositories. Artifactory and Nexus offer a feature called virtual registries, which act as a single access point to download, install, or deploy artifacts in the same format from one or more upstream repositories.\n\nThis functionality can:\n- make pipelines faster\n- make pipelines more reliable\n- reduce the cost of data transfer because over time most packages will be pulled from the cache\n\nEach dependency proxy format will give users the ability to add/configure one external repository. \n\nOnce added, when a user tries to install a package using their project-level endpoint, GitLab will first look for the package in the project and, if it's not found, attempt to pull the package from the external repository.\n\nWhen a package is pulled from the external repository, it will be imported into the GitLab project so that the next time that particular package/version is pulled it's pulled from GitLab and not the external repository.\n\nIf the package is not found in their GitLab project or the external repository, GitLab will return an error.\n\n- This feature and all future dependency proxy formats will be in the Premium tier.\n- Project owners will be able to configure this via a project's settings (API or UI).\n- We will support external repositories that require authentication, such as Artifactory or Sonatype.\n\nTo support this theme, we will also likely need to invest in related features, such as those listed in the issues below, which focus on the performance of the registry or giving more fine-grained access control to customers:\n- [Add a dependency proxy scope for GitLab tokens](https://gitlab.com/gitlab-org/gitlab/-/issues/336800)\n- [Improve Package Registry metadata generation](https://gitlab.com/groups/gitlab-org/-/epics/9835)\n- [Package registry authentication token](https://gitlab.com/gitlab-org/gitlab/-/issues/328765)\n\n## Container registry\nToday, GitLab.com is supported by the next-generation container registry and we've seen many performance and reliability improvements.\n\nIn 2024, we will focus on:\n- Getting the [container registry to GA for self-managed customers](https://gitlab.com/groups/gitlab-org/-/epics/5521)\n- [Improving the UI/UX of the container registry](https://gitlab.com/groups/gitlab-org/-/epics/3211)\n- Adding support for [granular access protection for container registries](https://gitlab.com/groups/gitlab-org/-/epics/9825) and [immutable container image tags](https://gitlab.com/gitlab-org/container-registry/-/issues/82)\n- Adding an integration with Google Cloud Platform's Artifact Registry to help [make deploying container images from GitLab to GCP easy](https://gitlab.com/groups/gitlab-org/-/epics/11443)\n\nThis functionality will:\n- help customers to reduce their storage costs\n- make the container registry more performant and reliable\n- make the GitLab team more efficient (by avoiding maintaining two codebases)\n\nWe have exciting plans for 2024! Please follow along as we make the package and container registries more useful, easier to use, and more secure.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._",[701,678,9,703],{"slug":3079,"featured":6,"template":683},"gitlab-package-roadmap-for-2024","content:en-us:blog:gitlab-package-roadmap-for-2024.yml","Gitlab Package Roadmap For 2024","en-us/blog/gitlab-package-roadmap-for-2024.yml","en-us/blog/gitlab-package-roadmap-for-2024",{"_path":3085,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3086,"content":3092,"config":3100,"_id":3102,"_type":13,"title":3103,"_source":15,"_file":3104,"_stem":3105,"_extension":18},"/en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment",{"title":3087,"description":3088,"ogTitle":3087,"ogDescription":3088,"noIndex":6,"ogImage":3089,"ogUrl":3090,"ogSiteName":670,"ogType":671,"canonicalUrls":3090,"schema":3091},"GitLab Pages features review apps and multiple website deployment","GitLab Pages helps organizations reap the rewards of knowledge management, including better collaboration and accessibility. Learn how to use a new feature, Parallel Deployments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674550/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Pages features review apps and multiple website deployment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matthew Macfarlane\"},{\"@type\":\"Person\",\"name\":\"Janis Altherr\"}],\n        \"datePublished\": \"2024-09-23\",\n      }",{"title":3087,"description":3088,"authors":3093,"heroImage":3089,"date":3096,"body":3097,"category":701,"tags":3098,"updatedDate":3099},[3094,3095],"Matthew Macfarlane","Janis Altherr","2024-09-23","[GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) has long been a popular choice for hosting static websites, allowing users to showcase their projects, blogs, and documentation directly from their repositories.\n\nBefore GitLab 17.4, you could only have a single version of your GitLab Pages website. So you couldn’t preview your changes or have multiple versions of your website deployed simultaneously. Now, with a Premium or Ultimate license, you can do both!\n\n### Introducing Parallel Deployments\n\nWith Parallel Deployments, users can now easily preview changes and manage multiple environments for their GitLab Pages sites. This enhancement allows seamless experimentation with new ideas, enabling users to confidently test and refine their sites. By catching any issues early, users can ensure the live site remains stable and polished, building on the already great foundation of GitLab Pages.\n\n### Why Parallel Deployments is a game-changer\n\n1. **Version control made easy**\\\n   If your project involves software development or documentation that covers multiple versions (such as user guides for different software releases), Parallel Deployments makes it easy to manage. Or you can use the feature to localize your website for different languages.\n2. **Flexibility to experiment**\\\n   Want to try out a new design or feature? Parallel Deployments lets you experiment freely. You can create a separate version of your site to test new ideas without impacting the current site. This flexibility encourages creativity and continuous improvement.\n\n### How to add review apps to your GitLab Pages project\n\nTo add a review app to your GitLab Pages project, edit your `.gitlab-ci.yml` file to create a deployment for each merge request (MR). Let’s assume you start with a `.gitlab-ci.yml` file somewhat like this:\n\n```yaml\ncreate-pages:\n  stage: deploy\n  script:\n    - npm run build\n  pages: \n    publish: dist # the name of the folder containing the pages files\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # only run this job when there's a commit to the default branch\n```\n\nTo also run the pages pipeline when there’s an MR being opened or updated, we can add another rule to `pages.rules`:\n\n```yaml\n- if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n```\n\nIf we only add this rule, however, each Pages job will always replace the main deployment – each time an MR is opened! You likely don’t want that to happen.\n\nTo provide each individual deployment with its own URL, we’ve introduced the new `pages.path_prefix` property.\n\nA Pages deployment with this configuration...\n\n```yaml\ncreate-pages:\n  script:\n    - ...\n  pages:\n    ...\n    path_prefix: my-review-app\n```\n\n...will be available at `https://my-pages-app-7fe824.gitlab.io/my-review-app`, or, with unique domains disabled, `https://my-group.gitlab.io/my-project/my-review-app`.\n\nBut there’s no need to hardcode the path_prefix. You can dynamically generate it using CI variables. That’s particularly useful for review apps – to create a path for each MR, use the `CI_MERGE_REQUEST_IID variable`:\n\n```yaml\ncreate-pages:\n  script:\n    - ...\n  pages:\n    ...\n    path_prefix: mr-$CI_MERGE_REQUEST_IID\n```\n\nAn MR with the ID 114 would then automatically create a deployment at `https://my-pages-app-7fe824.gitlab.io/mr-114`.\n\nWith those concepts at hand, we’d like our pipeline to dynamically create either a main deployment for the default branch, or a path_prefixed-review app for MR events.\n\nFirst, let’s add a `create-pages-review-app` job to our pipeline config:\n\n```yaml\ncreate-pages-deployment:\n  # This job will create a pages deployment without path_prefix\n  # when there is a commit to the default branch\n  stage: deploy\n  script:\n    - npm run build\n  pages: \n    publish: dist \n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\ncreate-pages-review-app:\n  # This job will create a pages deployment with a path_prefix\n  # when there a merge request is created or updated.\n  stage: deploy\n  script:\n    - npm run build\n  pages:\n    publish: dist \n    path_prefix: 'mr-$CI_MERGE_REQUEST_IID' # Prefix with the mr-\u003Ciid>, like `mr-123`\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n```\n\nNow you’re creating a deployment both when pushing to the default branch, and prefixed parallel deployments when creating or updating MRs!\n\nFor the best experience, add the URL to the environment job property. This will add a link to the review app to the MR page:\n\n```yaml\ncreate-pages-deployment:\n  # This job will create a pages deployment without path_prefix\n  # when there is a commit to the default branch\n  stage: deploy\n  script:\n    - npm run build\n  pages: \n    publish: dist \n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\ncreate-pages-review-app:\n  # This job will create a pages deployment with a path_prefix\n  # when there a merge request is created or updated.\n  stage: deploy\n  script:\n    - npm run build\n  pages:\n    publish: dist \n    path_prefix: 'mr-$CI_MERGE_REQUEST_IID' # Prefix with the mr-\u003Ciid>, like `mr-123`\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n  environment:\n    name: \"Pages Review MR ${CI_MERGE_REQUEST_IID}\"\n    url: $CI_PAGES_URL\n```\n\nCongratulations, you’ve now set up MR review apps for your Pages site.\n\n## How to deploy documentation for different versions of your product\n\nThe Parallel Deployments feature is also a useful tool if you maintain the documentation of multiple versions of your software simultaneously.\n\nThe below CI config will not only create a pages deployment when there is a commit to the default branch, but also for any commit to branches named `v1`, `v2`, or `v3`.\n\n```yaml\ncreate-pages:\n  stage: deploy\n  script:\n    - ...\n  variables:\n    PAGES_PREFIX: \"$CI_COMMIT_BRANCH\" # Use the branch name by default\n  pages:\n    path_prefix: \"$PAGES_PREFIX\" # use whatever value is set in the variable\n  environment:\n    name: \"Pages ${PAGES_PREFIX}\"\n    url: $CI_PAGES_URL\n  artifacts:\n    paths:\n    - public\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n      variables:\n        PAGES_PREFIX: '' # No prefix\n    - if: $CI_COMMIT_BRANCH == 'v1'\n    - if: $CI_COMMIT_BRANCH == 'v2'\n    - if: $CI_COMMIT_BRANCH == 'v3'\n```\n\nBy using the `$CI_COMMIT_BRANCH` variable as the path_prefix value, each of these branches will deploy their documentation to their own sub-path of your website:\n\n- The branch named v1 has its docs published to \u003Cmy-domain>/v1.\n- The branch named v2 has its docs published to \u003Cmy-domain>/v2.\n- The branch named v3 has its docs published to \u003Cmy-domain>/v3.\n\nA new commit to one of these branches will then trigger a new deployment to its respective path, keeping the documentation of multiple versions up to date.\n\nThe Parallel Deployments feature is a significant upgrade to GitLab Pages, offering a more flexible and efficient way to manage your knowledge. Whether you're working on a small project or a large-scale site with multiple versions, this new capability will make your workflow smoother and more efficient\n\n> Visit our [Parallel Deployments documentation](https://docs.gitlab.com/ee/user/project/pages/#create-multiple-deployments) to get started today!\n\n### Feedback\n\nShare your ideas and other comments in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/482040)!\n",[1164,108,703,9,701,746],"2025-04-09",{"slug":3101,"featured":6,"template":683},"gitlab-pages-features-review-apps-and-multiple-website-deployment","content:en-us:blog:gitlab-pages-features-review-apps-and-multiple-website-deployment.yml","Gitlab Pages Features Review Apps And Multiple Website Deployment","en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment.yml","en-us/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment",{"_path":3107,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3108,"content":3114,"config":3119,"_id":3121,"_type":13,"title":3122,"_source":15,"_file":3123,"_stem":3124,"_extension":18},"/en-us/blog/gitlab-premium-with-duo",{"title":3109,"description":3110,"ogTitle":3109,"ogDescription":3110,"noIndex":6,"ogImage":3111,"ogUrl":3112,"ogSiteName":670,"ogType":671,"canonicalUrls":3112,"schema":3113},"Unlocking AI for every GitLab Premium and Ultimate customer","GitLab Premium and Ultimate now include GitLab Duo essentials for creating and understanding code throughout the software development lifecycle, all at no additional cost.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660188/Blog/Hero%20Images/blog-premium-with-duo-cover-0756-fy26-v2-1800x945.png","https://about.gitlab.com/blog/gitlab-premium-with-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unlocking AI for every GitLab Premium and Ultimate customer\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2025-05-15\",\n      }",{"title":3109,"description":3110,"authors":3115,"heroImage":3111,"date":3116,"body":3117,"category":701,"tags":3118},[2840],"2025-05-15","Today, we launch GitLab 18.0, which highlights our latest innovations and plans in core DevSecOps workflows, security and compliance, and AI. __As part of this release, we're excited to announce that GitLab Premium and Ultimate now include essential GitLab Duo AI capabilities at no additional cost.__ All Premium and Ultimate customers will have immediate access to GitLab Duo Code Suggestions and Chat directly in their preferred supported source code editors and IDEs.\n\n## AI for every development team\n\nArtificial intelligence is now at the center of the developer experience. AI enhances coding in many ways: It analyzes your codebase and provides real-time suggestions as you type, creates functions and methods based on your project's context, reduces repetitive tasks, and automates code reviews.\n\nOver the past few years, we've built [GitLab Duo](https://about.gitlab.com/gitlab-duo/) to infuse generative and agentic AI capabilities like these into our platform. Because writing code is just the start of the software lifecycle – our [global DevSecOps study](https://about.gitlab.com/developer-survey/) found that developers spend 79% of their time on tasks other than code creation – we have adopted a strategy to integrate AI throughout the entire software development lifecycle. \n\nNow, we’re excited to take the next step forward by including essential GitLab Duo capabilities in our GitLab Premium and Ultimate tiers, enabling developers to get the benefits of AI at no additional cost.\n\nBy including GitLab Duo Chat and Duo Code Suggestions in Premium and Ultimate, every software engineer can accelerate their workflow within the IDE — without requiring separate tooling, licensing, or governance. All existing Premium and Ultimate customers now have instant access to Duo Chat and Code Suggestions, once they upgrade to GitLab 18.0, and this enhancement becomes standard for all new customers.\n\n> **\"GitLab has already been instrumental in eliminating our reliance on a fragmented toolchain, which cut costs from disconnected solutions, and streamlined our workflow. Enhancing GitLab Premium with Duo will give us even greater efficiency and cost savings as our developers spend less time on routine coding tasks and more time tackling complex challenges that drive real business value.”**\n>\n>- Andrei Nita, Chief Technology Officer at McKenzie Intelligence Services\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\nPremium and Ultimate customers now have these AI-native capabilities:\n\n#### GitLab Duo Code Suggestions\n\n* Generate complete functions and code blocks from comments  \n* Get intelligent code completions as you type  \n* Support for 20+ programming languages  \n* Available in most popular IDEs\n\nTake this interactive tour to learn about GitLab Duo Code Suggestions (click on the image to start the tour).\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\nLearn more in our [Duo Code Suggestions documentation](https://docs.gitlab.com/user/project/repository/code_suggestions/).\n\n#### GitLab Duo Chat\n\n* Explain unfamiliar code to understand complex functionality  \n* Refactor existing code to improve quality and maintainability  \n* Generate comprehensive test cases to help catch bugs earlier  \n* Fix code issues directly in your workflow\n\n![Duo Chat - API endpoint explanation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Duo_Chat_-_gif_-_API_endpoint_explanation__3_.gif)\n\nLearn more in our [Duo Chat documentation](https://docs.gitlab.com/user/gitlab_duo_chat/).\n\n> **\"For us, as GitLab users, Duo's intelligent code suggestions have become a daily asset for our developers. Combined with the chat feature, it allows for immediate feedback and iteration, resulting in faster development cycles and a more secure codebase. It's a seamless and powerful addition to our workflows.\"**\n>\n>- Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA\n\n## Duo Enterprise now available to GitLab Premium customers\n\nDue to strong customer demand, we're also excited to share that [GitLab Premium](https://about.gitlab.com/pricing/premium/) customers now can purchase Duo Enterprise, our full suite of AI offerings, without needing to upgrade to GitLab Ultimate. Premium customers can enjoy a rich AI experience seamlessly integrated across the software development lifecycle. This includes exciting GitLab Duo capabilities like:\n\n* [Root Cause Analysis](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases) helps resolve CI/CD pipeline failures quickly, ensuring your CI/CD pipelines remain green.  \n* [Code Review](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) enables faster merge request reviews by leveraging Duo as a code reviewer.  \n* [Advanced Chat](https://docs.gitlab.com/user/gitlab_duo_chat/) summarizes conversations, helps understand code changes, and provides advanced configuration assistance.  \n* [Self-Hosted](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) enables Duo to be leveraged within air-gapped and offline environments by hosting approved AI models for Duo to use.\n\nIn addition to Duo Enterprise availability, we continue to invest in the success of GitLab Premium customers. Since the launch of GitLab 17, [we’ve shipped more than a hundred features and improvements](https://gitlab.com/gitlab-org/gitlab/-/releases), including: \n\n* [**CI/CD Catalog**](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) enables developers to share, discover, and reuse   \npre-existing CI/CD components and configurations.  \n* [**Artifact registry**](https://docs.gitlab.com/user/packages/virtual_registry/) gives developers secure access to artifacts and seamless integration with CI/CD pipelines.  \n* [**Remote development**](https://docs.gitlab.com/user/project/remote_development/) enables developers to work in on-demand,  \ncloud-based development environments.\n\n> [Learn more about GitLab Premium features.](https://about.gitlab.com/pricing/premium/#wp-premium-features)\n\n## GitLab Duo: AI that meets organizations where they are\n\nGitLab customers have a comprehensive menu of Duo offerings, across our Pro and Enterprise solutions, to meet you where you are in the AI adoption cycle – the further along your teams are, the more capabilities you can use to build, test, and deploy secure software faster.\n\n![Key features in Duo plans](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Screenshot_2025-05-14_at_8.50.34_AM.png)\n\n## How current GitLab Ultimate and Premium customers can get started with Duo\n\nStarting with GitLab 18.0, for existing Ultimate and Premium customers, Duo Code Suggestions and Chat features will be off by default but can easily be enabled – learn how below.\n\nTo start experiencing GitLab Premium and Ultimate with Duo: \n\n1. Ensure you're on GitLab Premium or Ultimate. If not, you can start a free, 60-day trial. \n\n2. Enable GitLab Duo in your organization settings.\n\n3. If using a local IDE, install the appropriate GitLab [Editor Extension](https://docs.gitlab.com/editor_extensions/#available-extensions). \n\n4. Start using Code Suggestions and Chat in your preferred supported local IDE or the GitLab Web IDE.\n\n**Note:** For new customers and trials, GitLab's AI capabilities will be enabled automatically.\n\n## AI-native development requires a DevSecOps platform\n\nAI is fundamentally reshaping the developer experience. Organizations won't just have more people building software. They'll have more production-ready code generated by AI – **making GitLab more essential than ever.** \n\nWe built GitLab Premium and Ultimate with Duo specifically for this new reality, giving teams one secure foundation for all their code. As AI generates code across your organization, GitLab becomes your control center: no separate tools for security scanning, compliance checks, or managing pipelines. Just a single, unified platform that scales with your organization and helps ensure all code meets your standards before reaching production. As AI accelerates your development, GitLab enables you to maintain control, security, and quality from end to end.\n\n> To learn more about GitLab Duo and all the ways it can transform how your team works, [visit our GitLab Premium page](https://about.gitlab.com/pricing/premium/) or if you are a GitLab customer, reach out to your GitLab representative to schedule a demo. Finally, we invite you to join us on June 24, 2025, for our [GitLab 18 virtual launch event](https://about.gitlab.com/eighteen/) to learn about the future of AI-native software development.\n",[786,478,678,9,701],{"slug":3120,"featured":90,"template":683},"gitlab-premium-with-duo","content:en-us:blog:gitlab-premium-with-duo.yml","Gitlab Premium With Duo","en-us/blog/gitlab-premium-with-duo.yml","en-us/blog/gitlab-premium-with-duo",{"_path":3126,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3127,"content":3133,"config":3139,"_id":3141,"_type":13,"title":3142,"_source":15,"_file":3143,"_stem":3144,"_extension":18},"/en-us/blog/gitlab-product-navigation",{"title":3128,"description":3129,"ogTitle":3128,"ogDescription":3129,"noIndex":6,"ogImage":3130,"ogUrl":3131,"ogSiteName":670,"ogType":671,"canonicalUrls":3131,"schema":3132},"Inside the vision for GitLab’s new platform navigation","A peek into what inspired our new navigation design, which is coming soon.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668078/Blog/Hero%20Images/cover-image-helm-registry.jpg","https://about.gitlab.com/blog/gitlab-product-navigation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside the vision for GitLab’s new platform navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christen Dybenko\"}],\n        \"datePublished\": \"2023-05-01\",\n      }",{"title":3128,"description":3129,"authors":3134,"heroImage":3130,"date":3135,"body":3136,"category":1513,"tags":3137},[1372],"2023-05-01","\n\nSoon, we’ll be launching an entirely redesigned navigation in the GitLab product that is based on feedback from users. We’re both excited and a little nervous because navigation is so critical to every user’s workflow. That’s why we made a thoughtful shift in our iteration strategy, taking extra time and intention to develop a new and refined vision. We'd like to share a peek into how we ended up where we did and why we are so excited for our new design!\n\n## We had to invest in the right user experience\n\nBecause it has such an obvious impact on user experience, a navigation overhaul is no small feat. That’s why we fully funded a team to work exclusively on navigation, and provided the time and space to create the best experience possible. During the past year, we put a big focus on design ideation and UX research. It was a lot of work, but we believe this level of user focus has really paid off. \n\nBacked by our amazing design and product leadership team, we put much of our focus on the new navigation for more than nine months while we designed and tested it with end users.\n\nIn this blog post, we’ll share insights on our process, what we learned, and our vision for the future.\n\n![New navigation](https://about.gitlab.com/images/blogimages/2023-04-20-new-navigation-vision/new-navigation-vision.png){: .shadow}\n\n## Predicting what users will need\n\nWhen we first started to think about how to redesign our navigation, the challenge seemed overwhelming. How do we know how to make the best decisions for our navigation? How can anyone know which design or solution is *right*?\n\nWe did not want to make users unhappy for even a short period of time. At GitLab, we have [15 user personas](/handbook/product/personas/#user-personas), incredibly savvy users, and so many different workflows. We had to consider opinions that were not present in our backlog. For example, our power users can be very verbose in issues, but new users are not.\n\nIt is a huge undertaking to get to this kind of understanding and know what is right. Time pressure and needing to ship quickly could have made this type of work impossible at this scale.\n\nThankfully, our team dedicated to navigation was amazing. They invested time to reveal our users' key pain points with navigation, which set the litmus test by which we could evaluate every mockup and solution.\n\n## Establishing a north star\n\nBefore we wrote a line of code or started planning, we did a crucial piece of alignment to know our goals. Our design team led us in a north star exercise where we examined every piece of [System Usability Score (SUS)](/handbook/product/ux/performance-indicators/system-usability-scale/) feedback we had received on navigation.\n\nWe coded this feedback and [three themes](/direction/manage/foundations/navigation_settings/#1-year-plan) emerged. We needed to: \n\n- minimize feelings of being overwhelmed\n- orient users across the platform\n- allow users to pick up where they left off easily\n\nThis north star was amazing for understanding the problem and how to proceed. We learned _a lot_ about what our users’ pain points are and what our users struggle with daily.\n\nThankfully, this also helped us remove the dread of trying to ship something with the impossible goal of being all things to all people as we could now test these three themes with any persona.\n\nWe applied the themes to every design validation effort that we conducted with users moving forward. Our UX Research team also conducted interviews to understand how users felt about these specific themes. It felt incredible to have these insights available right from the start. It was also empowering to let some of the noise go to focus more clearly on what matters and what would move us forward.\n\n## Shifting our perspective on iteration for the right user experience\n\nGitLab is amazing at [iteration](/handbook/engineering/workflow/iteration/), and lately, we’ve been raising the bar on the quality of our [MVCs](/handbook/product/product-principles/#the-minimal-viable-change-mvc) and [definition of done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html?#ui-changes) with the goal of not degrading the current user experience. For navigation, we took this extra seriously, with the intention of protecting every part of the navigation experience.\n\nAs we reviewed the history of many iterative navigation updates over the past five years, we could see that there was very little overall consistency in the code and in the intention of the updates. This is what happens at fast-moving startups, and it can be ok for a period of time, but at some point, it's necessary to take a pause to strip things back for a meaningful change. The small iterations over time gave us an indication of pain points overall, and we needed a thoughtful plan to proceed. \n\nWe decided that anything we change in this new navigation should not degrade a user’s core workflow. We would first hit a baseline for what currently exists in navigation and then make meaningful updates. We agreed that anything we ship after our Alpha had to be fully usable by our own team. We didn’t want users to feel like we’d moved backward or that they had lost functionality in this next phase.\n\nSo, while we have some exciting features planned for the future, we won’t take action on them until we fully refine the core features and address user feedback.\n\n## Iterations now and vision for the next year \n\nWhile holding the baseline promise of no degradation in the new navigation, we did find opportunities to ship small iterations to our current navigation since January. First, we shipped a new navigation called “Your Work” and second, we shipped a new “Explore” menu to all users. Those menus are central to our new navigation vision, but they improved the legacy navigation, too.\n\nAfter launch, we can’t wait to improve even further with more customizable navigation experiences like allowing pins on Your Work and seamless integration with search, command line, and keyboard use. We also have ideas on how to add better landing pages that make life more custom in GitLab, and we couldn’t do that without this new navigation.\n\n## No one likes a navigation re-design\n\nAll that said, we know that no one actually likes a navigation redesign, even if it is best in the long run. Core workflows are ingrained muscle memory that no one wants to mess with if possible.\n\nThat’s why we are releasing our new navigation with a built-in on/off switch. With this approach, you can gradually move to the new navigation by switching back and forth for a little while, as needed. \n\nOur hope is that you’ll take a similar approach and share your feedback along the way, too. We want to hear about your experiences, so please be honest and your feedback will help us iterate.\n\n## What to expect for rollout\n\nWe are proud of our vision for a new navigation! Over the next few months, our new navigation will be available via an opt-in process in the user profile menu, and we'd love your feedback. Watch our Twitter, upcoming release posts, and our [direction page](/direction/manage/foundations/navigation_settings/) for more information!\n",[701,3138,9,680],"design",{"slug":3140,"featured":6,"template":683},"gitlab-product-navigation","content:en-us:blog:gitlab-product-navigation.yml","Gitlab Product Navigation","en-us/blog/gitlab-product-navigation.yml","en-us/blog/gitlab-product-navigation",{"_path":3146,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3147,"content":3153,"config":3159,"_id":3161,"_type":13,"title":3162,"_source":15,"_file":3163,"_stem":3164,"_extension":18},"/en-us/blog/gitlab-product-vision",{"title":3148,"description":3149,"ogTitle":3148,"ogDescription":3149,"noIndex":6,"ogImage":3150,"ogUrl":3151,"ogSiteName":670,"ogType":671,"canonicalUrls":3151,"schema":3152},"GitLab's product vision for 2019 and beyond","Watch Head of Product, Mark Pundsack, present our product vision.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671613/Blog/Hero%20Images/gitlab-innovate-cover.png","https://about.gitlab.com/blog/gitlab-product-vision","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's product vision for 2019 and beyond\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2018-10-01\",\n      }",{"title":3148,"description":3149,"authors":3154,"heroImage":3150,"date":3156,"body":3157,"category":298,"tags":3158},[3155],"GitLab","2018-10-01","\n\nWe [recently went live](/blog/gitlab-live-event-recap/) to discuss the\nnews of our [Series D funding](/blog/announcing-100m-series-d-funding/)\nand what the future holds for GitLab. You can watch GitLab's Head of Product,\nMark Pundsack, present our vision with some previews of what's in the works\nbelow:\n\n## Watch the recording\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZgFqyXCsqPY?start=3796\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### View the slides\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://docs.google.com/presentation/d/e/2PACX-1vRCKP-VcLD9IomS8d1U8N73dfFWLtsVCAPtGiKBwlIv68U6tlZViv6HGCk53Nd_8HxitqDN-lVvIaTE/embed?start=false&loop=false&delayms=3000\" frameborder=\"0\" width=\"960\" height=\"569\" allowfullscreen=\"true\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\">\u003C/iframe>>\n\u003C/figure>\n\n## Summary of our product vision\n\nOur strategy is to double down on what's working: while we already cover the\nentire DevOps lifecycle, we want to increase depth in some of our existing\nfeatures, transitioning from minimum viable change to minimum loveable feature.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n  \u003Cblockquote class=\"twitter-tweet\" data-partner=\"tweetdeck\">\u003Cp lang=\"en\" dir=\"ltr\">I thought \u003Ca href=\"https://twitter.com/Jobvo?ref_src=twsrc%5Etfw\">@Jobvo\u003C/a> had me at "Minimal Viable Change".  But then \u003Ca href=\"https://twitter.com/MarkPundsack?ref_src=twsrc%5Etfw\">@MarkPundsack\u003C/a> comes out with "Minimal Lovable Product" and I'm awestruck \u003Ca href=\"https://twitter.com/hashtag/GitLabLive?src=hash&ref_src=twsrc%5Etfw\">#GitLabLive\u003C/a>\u003C/p>— Brendan O'Leary 👨🏻‍💻 (@olearycrew) \u003Ca href=\"https://twitter.com/olearycrew/status/1042837763480068096?ref_src=twsrc%5Etfw\">September 20, 2018\u003C/a>\u003C/blockquote>\n  \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWe're also going to continue to increase our breadth, building out new\ncapabilities across the entire DevOps lifecycle.\n\nAnd finally, because we believe everyone can contribute, we're going to add more\nroles to the scope of product, including executives, designers, product\nmanagers, and essentially anyone who is involved in software development and\ndelivery. Our goal is to get everyone working concurrently in a single product,\nwith nine best-in-class categories.\n\n## Coming up...\n\nWe're working on building out 26 new capabilities, but because you don't have\nall day, below are three examples to give you a taste of what's in the works.\n\n\u003Csmall>*Obligatory disclaimer: These are mock-ups and the features may turn out\nlooking a little different, or may not ship at all*\u003C/small>\n\n### Executive flow: Value Stream Management\n\nAt its heart, [Value Stream Management](/solutions/value-stream-management/)\nis about understanding your teams' work and their workflow on the way to\ndelivering value to customers. The way we're approaching it is to extend\nsomething development teams are already using to track their work, namely issue\nboards, and bring it into the bigger picture by having a board that covers the\nentire workflow necessary to get ideas into production.\n\nBecause GitLab already covers that entire scope, we can automate it too. We know\nwhen a feature is scheduled. We know when you push your first commit. We know\nwhen code review starts. We know when you deploy your code to production. So we\ncan move the cards to the right spots automatically, so not only can you track\nyour progress and communicate it to your team, you can track it all\nautomatically and more accurately. Neat, huh?\n\n![Value Stream Management analytics view](https://about.gitlab.com/images/blogimages/product-vision-sep-20/vsm-analytics.png){: .shadow.medium.center}\n\nThe above mock-up demonstrates a situation where someone was able to dive into\nthe time spent on various areas, and see that the time spent waiting for someone\nto even start QA was really high, and they managed to shave off a few days just\nby rearranging some internal processes. The same goes for the code review cycle.\n\n### Ops flow: Incident management\n\nThis is an operations flow based on a new product capability:\n[incident management](https://gitlab.com/groups/gitlab-org/-/epics/349). We\nmonitor your production apps and detect an anomaly, alert you, and then open an\nincident. Then in one place you can see: what triggered the alert, who's\ninvolved in responding, quick links to the Slack conversation, Zoom call, and\nwhere to update your public status page. There's also a timeline of all\nactivity. Because this is part of the same application that developers are\nusing, it’s not just operations people using this tool, so when you’re working\ntogether on problems, you’re looking at the same data, and GitLab knows not only\nwhat metrics are alerting, but what code was recently deployed that might have\ncaused it, and who was behind that code. When the incident is resolved, you can\neasily follow up with your users with a postmortem, pulling in all the relevant\ndata and timeline of events. Of course, with all that data comes great power for\nanalytics, to help the team learn from the incidents and improve.\n\n![Incident open](https://about.gitlab.com/images/blogimages/product-vision-sep-20/incident-management-error-rate.png){: .shadow.medium.center}\n  *\u003Csmall>Mock-up showing an Incident open with timeline view, including Slack messages and Status page updates\u003C/small>*\n\n### Security flow: Auto remediate\n\nA common security task is watching for new vulnerabilities in your project’s\ndependencies. If a module you depend on has a vulnerability, there’s usually a\npatch update to go along with it. When that patch is released, you then need to\ntest your software again with that patch, to make sure everything still works\nbefore you deploy it. That’s a pain!\n\nInstead of making anyone do all that repetitive, but necessary security work,\n[we want to automate it all away](https://gitlab.com/groups/gitlab-org/-/epics/133).\nIn our vision, a bot detects that a dependency has a new version, and instead of\nalerting someone, automatically creates a merge request that bumps the version\nnumber for you, and runs the test suite to make sure that everything still\nworks. The CI pipeline passes, and confirms that the security vulnerability is\nnow gone, so the bot automatically merges the changes. If all goes well, your\nsecurity and development teams just get an email in the morning saying that all\nthe projects with that dependency were automatically fixed.\n\nBy why leave a known, security vulnerability live any longer than it needs to?\nTo bring it full circle, after merging, the CI/CD pipeline starts incrementally\ndeploying to production. If the production error rate jumps, we automatically\nstop the incremental rollout, and go ahead and roll back to the last-known good\nversion immediately. The bot detects this and automatically reverts the merge\nrequest so we can leave `master` in a good state. This, we can finally alert the\nteams about, so instead of having to test 20 projects manually, they can focus\non the few that can’t be automated.\n\n![Auto remediate reverted](https://about.gitlab.com/images/blogimages/product-vision-sep-20/auto-remediate-reverted.png){: .shadow.medium.center}\n  *\u003Csmall>Mock-up showing a merge request reverted automatically following detection of production errors\u003C/small>*\n\nAs always, our plans are in draft and we welcome your feedback and input!\n",[9,680],{"slug":3160,"featured":6,"template":683},"gitlab-product-vision","content:en-us:blog:gitlab-product-vision.yml","Gitlab Product Vision","en-us/blog/gitlab-product-vision.yml","en-us/blog/gitlab-product-vision",{"_path":3166,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3167,"content":3172,"config":3178,"_id":3180,"_type":13,"title":3181,"_source":15,"_file":3182,"_stem":3183,"_extension":18},"/en-us/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast",{"title":3168,"description":3169,"ogTitle":3168,"ogDescription":3169,"noIndex":6,"ogImage":1622,"ogUrl":3170,"ogSiteName":670,"ogType":671,"canonicalUrls":3170,"schema":3171},"GitLab Runner update required to use SAST in Auto DevOps","Make sure you upgrade GitLab Runner to 11.5+ to coninue using SAST in Auto DevOps.","https://about.gitlab.com/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Runner update required to use SAST in Auto DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabio Busatto\"}],\n        \"datePublished\": \"2018-12-06\",\n      }",{"title":3168,"description":3169,"authors":3173,"heroImage":1622,"date":3175,"body":3176,"category":849,"tags":3177},[3174],"Fabio Busatto","2018-12-06","\n\nWe are introducing a major change for the [SAST] job definition for [Auto DevOps] with **GitLab 11.6**, shipping Dec. 22.\nAs a result, SAST jobs will fail after the upgrade to GitLab 11.6 if they are picked up by a version of [GitLab Runner]\nprior to 11.5. The jobs will fail, but they will not block pipelines. However, you won't see results\nfor SAST in the merge request or at the pipeline level anymore.\n\nThe same change will happen for [Dependency Scanning], [Container Scanning], [DAST], and [License Management] in future releases.\n\n## Why did this happen?\n\nThe [new job definition] uses the [`reports` syntax], which is necessary to show SAST results in the [Group Security Dashboard].\nUnfortunately, this syntax is not supported by GitLab Runner prior to 11.5.\n\n## Who is affected?\n\nYou are affected by this change if you meet **all** the requirements in the following list:\n1. You are using Auto DevOps **AND**\n1. you have at least one GitLab Runner 11.4 or older set up for your projects **AND**\n1. you are interested in security reports.\n\n## Who is not affected?\n\nYou are **not** affected by this change if you meet **at least one** of the requirements in the following list:\n1. You are not using Auto DevOps **OR**\n1. you are using only GitLab Runner 11.5 or newer **OR**\n1. you are using only shared runners on GitLab.com (we already upgraded them) **OR**\n1. you are not interested in security reports.\n\n## How to solve the problem\n\nIf you are not affected by the change, you don't need to take any action.\n\nIf you are affected, you should upgrade your GitLab Runners to version 11.5 or newer as soon as possible.\nIf you don't, you will not have new SAST reports until you do upgrade. If you upgrade your runners later, SAST will\nstart to work again correctly.\n\n## Which is the expected timeline?\n\nGitLab 11.6 will be released on **Dec. 22**.  This change may also be shipped in an early release\ncandidate (RC) version.\n\nIf you are using a **self-managed** GitLab instance, and you don't install RC versions, you will be affected when\nyou'll upgrade to GitLab 11.6.\n\nIf you are using **GitLab.com**, you will be affected as soon as the RC version with the change will be deployed.\n\nFeel free to reach out to us with any further questions!\n\n[SAST]: https://docs.gitlab.com/ee/user/application_security/sast/\n[Auto DevOps]: https://docs.gitlab.com/ee/topics/autodevops/\n[new job definition]: https://docs.gitlab.com/ee/user/application_security/sast/\n[`reports` syntax]: https://docs.gitlab.com/ee/ci/yaml/#artifactsreportssast-ultimate\n[Group Security Dashboard]: https://docs.gitlab.com/ee/user/application_security/security_dashboard/\n[GitLab Runner]: https://docs.gitlab.com/runner/\n[Dependency Scanning]: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/\n[Container Scanning]: https://docs.gitlab.com/ee/user/application_security/container_scanning/\n[DAST]: https://docs.gitlab.com/ee/user/application_security/dast/\n[License Management]: https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html\n",[1396,851,9,893,704],{"slug":3179,"featured":6,"template":683},"gitlab-runner-update-required-to-use-auto-devops-and-sast","content:en-us:blog:gitlab-runner-update-required-to-use-auto-devops-and-sast.yml","Gitlab Runner Update Required To Use Auto Devops And Sast","en-us/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast.yml","en-us/blog/gitlab-runner-update-required-to-use-auto-devops-and-sast",{"_path":3185,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3186,"content":3192,"config":3198,"_id":3200,"_type":13,"title":3201,"_source":15,"_file":3202,"_stem":3203,"_extension":18},"/en-us/blog/gitlab-series-e-funding",{"title":3187,"description":3188,"ogTitle":3187,"ogDescription":3188,"noIndex":6,"ogImage":3189,"ogUrl":3190,"ogSiteName":670,"ogType":671,"canonicalUrls":3190,"schema":3191},"Announcing $268 million in Series E funding","New funding and our $2.75 billion valuation will allow us to enhance monitoring and security capabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664134/Blog/Hero%20Images/gitlabcommitbrooklyn.png","https://about.gitlab.com/blog/gitlab-series-e-funding","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Announcing $268 million in Series E funding\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2019-09-17\",\n      }",{"title":3187,"description":3188,"authors":3193,"heroImage":3189,"date":3194,"body":3195,"category":298,"tags":3196},[3155],"2019-09-17","We’re excited to share that GitLab has completed a $268 million Series E round of fundraising that pushed the company’s valuation to $2.75 billion. This latest funding round was led by existing investors Goldman Sachs and ICONIQ, but also included participation from nine new-to-GitLab investors.\n\nOur plans for the funding are straightforward: GitLab will invest to make all of our [DevOps platform](/topics/devops-platform/) offerings, including monitoring, security, and planning, _best in class_ so we can enable our [enterprise customers](/enterprise/) to continue to bring products to market faster.\n\nAt a time when the DevOps tools market is expected to triple by 2023 (from $5.2 billion last year to $15 billion, according to IDC), it was clear there was an opportunity for our company to pursue additional funding.\n“To be competitive today, companies need to be 10x faster to market. We made an early bet that enterprises would benefit from a single application experience for DevOps teams to accelerate getting software products to market faster and more securely,” says CEO [Sid Sijbrandij](/company/team/#sytses). “I love hearing how our customers are innovating faster with a single DevOps application that enables Dev, Ops, and Security to collaborate, and this funding will help more organizations experience the benefits of this unified DevOps experience.”\n\nToday more than 100,000 organizations use GitLab, including Ask Media Group, Charter Communication, Delta Air Lines, Goldman Sachs, Ticketmaster, Nvidia, and [many more](/customers/). We just found out we were ranked 32nd in the [Forbes 2019 Cloud 100](https://about.gitlab.com/2019-09-11-gitlab-named-leader-in-forbes-cloud-100-list/) – and we were the only cloud-agnostic DevOps tool maker named! Our ARR (annual recurring revenue) growth rate is 143%, a sign of customer satisfaction and strong demand.\n\n## A fast pace\n\nThis latest fundraising effort happened less than a year after we announced our [Series D round of $100 million](/blog/announcing-100m-series-d-funding/). At that time the company was valued at $1.1 billion; with today’s announcement, our valuation has more than doubled in less than a year.\n\nIt’s been an amazing journey to get to this point, and it’s worth remembering where we came from. In 2015 fewer than 10 people worked at GitLab; today over 800 team members contribute from 55 countries around the world. And we’re still growing, as our [222 open positions](/jobs/) show. More than 4,800 people actively contribute code to GitLab, and we receive an average of 180 improvements to each monthly release. In March 2019 we had [one million merge requests](/blog/1-mil-merge-requests/), which was a milestone indeed.\nWe’re on this journey together and we couldn’t be more excited to see where it takes us. Today you’ll find us at our first ever user conference, [GitLab Commit](/events/commit/), in Brooklyn and then again in London on October 9. We’re looking forward to the inspiring customer stories that have made this all possible.\n\nThe funding was announced live in the [keynote of GitLab Commit Brooklyn](https://www.youtube.com/watch?v=6LrgxOfWMXA&list=PLFGfElNsQthaaqEAb6ceZvYnZgzSM50Kg), also see [the playlist of all talks that day](https://www.youtube.com/playlist?list=PLFGfElNsQthaaqEAb6ceZvYnZgzSM50Kg).",[678,266,276,9,3197],"frontend",{"slug":3199,"featured":6,"template":683},"gitlab-series-e-funding","content:en-us:blog:gitlab-series-e-funding.yml","Gitlab Series E Funding","en-us/blog/gitlab-series-e-funding.yml","en-us/blog/gitlab-series-e-funding",{"_path":3205,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3206,"content":3212,"config":3219,"_id":3221,"_type":13,"title":3222,"_source":15,"_file":3223,"_stem":3224,"_extension":18},"/en-us/blog/gitlab-summit-cape-town-recap",{"title":3207,"description":3208,"ogTitle":3207,"ogDescription":3208,"noIndex":6,"ogImage":3209,"ogUrl":3210,"ogSiteName":670,"ogType":671,"canonicalUrls":3210,"schema":3211},"Salani kakuhle (bye!) and thanks for a great summit in Cape Town!","And just like that, it was all over. Check out the highlights and keynote from our recent summit in South Africa.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670482/Blog/Hero%20Images/summit_recap_pic_post.jpg","https://about.gitlab.com/blog/gitlab-summit-cape-town-recap","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Salani kakuhle (bye!) and thanks for a great summit in Cape Town!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daisy Miclat\"},{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n        \"datePublished\": \"2018-09-14\",\n      }",{"title":3207,"description":3208,"authors":3213,"heroImage":3209,"date":3216,"body":3217,"category":298,"tags":3218},[3214,3215],"Daisy Miclat","Rebecca Dodd","2018-09-14","\n\nFrom August 23-29, 350 GitLab team-members, significant others, community members, and customers descended on Cape Town, South Africa to get to know one another IRL at our sixth [summit](/events/gitlab-contribute/). As an all-remote company, it’s not often we’re all in one place, so we get together every nine months to hang out, bond, take in the local sights, and even get a little work done.\n\n## Highlights\n\n### Keynote\n\nAfter getting settled in and, for many, powering through some brutal jetlag, we gathered for the opening keynote with Chief Culture Officer [Barbie Brewer](/company/team/#BarbieJBrewer), Chief Revenue Officer [Michael McBride](/company/team/#mmcb), Head of Product [Mark Pundsack](/company/team/#MarkPundsack), and CEO and co-founder, [Sid Sijbrandij](/company/team/#sytses), which you can watch below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4BIsON95fl8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Challenge\n\nIt’s become [tradition at our summits for Sid to throw down the gauntlet with a few challenges](/blog/gitlab-summit-greece-recap/#summit-challenges), and this year’s was no different:\n\n![Cape Town summit challenges](https://about.gitlab.com/images/blogimages/summit2018/summit-challenge-slide.png){: .shadow.medium.center}\n\nAnd, as with previous summits, we were promised to be rewarded richly for meeting the challenges:\n\n![Cape Town summit challenges reward](https://about.gitlab.com/images/blogimages/summit2018/summit-challenge-win.png){: .shadow.medium.center}\n\nIt's also become tradition that we hit it out of the park 😎 We're happy to report that we were successful in challenges! Greg Brewer was convinced and is #movingtogitlab, and we've [added the ability to request a free instance check](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6995).\n\n### Excursions\n\nThe summits also give us an amazing opportunity to get to know the area that we’re visiting. We were able to choose from some phenomenal excursions throughout Cape Town to learn more about the culture and history of what locals affectionately call the Mother City.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-5\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"1\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"2\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n          \u003Cimg src=\"/images/blogimages/summit2018/cape-of-good-hope.jpeg\" alt=\"Cape of Good Hope\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/summit2018/lanzerac-wine-tour.jpg\" alt=\"Lanzerac wine tour\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/summit2018/robben-island.jpg\" alt=\"Robben Island\">\n    \u003C/div>\n\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\n\n#### Boulders Beach and the Cape of Good Hope\n\nA beautiful tour along the coast and the opportunity to say hello to our furry friends, our first stop on this excursion was Boulders Beach, where we saw cute African Penguins waddling around, taking swims, and hanging out. They weren’t fazed by us humans. If anything they enjoyed the attention! Up next, we drove to the southernmost tip of Africa, through breathtaking, untouched terrain. Along the way, we spotted local wildlife including antelopes, ostriches, and a couple of feisty baboons.\n\n#### Robben Island\n\nA somewhat choppy 20-minute ferry ride from Victoria Wharf, [Robben Island](http://www.robben-island.org.za/) is home to the prison where political activist and South Africa's first democratic president Nelson Mandela was imprisoned for 18 years. Our tour guide was a former prisoner himself, and he shared his experiences and the history of Robben Island. Although it was a somber setting, we were able to learn more about the history of South Africa and how inequality existed not too long ago.\n\n#### Cape winelands\n\nThe Western Cape is home to some spectacular wine estates. Some GitLab team-members visited [Groot Constantia](https://www.grootconstantia.co.za/), the oldest wine-producing estate in the country, while others ventured further to Paarl, Franschhoek and Stellenbosch for a leisurely day of vineyard hopping and tasting. Those of us checking baggage loaded up on the good stuff to take home.\n\n#### City and cultural tour\n\nA tour of the city center included visits to the [District Six Museum](http://www.districtsix.co.za/), [Castle of Good Hope](https://castleofgoodhope.co.za/), and the [Slave Lodge](https://www.iziko.org.za/museums/slave-lodge), stopping off at the V&A Waterfront for lunch. Some persuasive GitLab team-members got the tour guide to agree to a diversion to quirky coffee shop and Capetonian institution, [Truth Café](https://truth.coffee/pages/truth-cafe), to soak up some of the city's coffee culture.\n\n#### Tour of Langa\n\nSome GitLab team-members also visited Langa, the oldest township in Cape Town. After being greeted by the locals at the cultural center, they shared their dance, music, and history. Some of us were even able to participate and beat on the drums or do a little dancing! Our tour guide shared the history of the township: its beginnings during Apartheid, how things are today, and where they are striving to rebuild unity within the community. Our tour ended with a lovely dance performance and goodbyes from the locals.\n\n### UGC sessions\n\nOur summit UGC (user-generated content) sessions are an opportunity for anyone attending to raise a subject for discussion or run a workshop. With topics as diverse as \"Kubernetes 101,\" \"Learn to Yo-Yo for fun and profit,\" \"How to be a great public speaker,\" \"Yoga/body balance,\" and \"Cocktail making class,\" there's always something for everyone, and it's up to individuals to decide how formal or off-the-cuff they want their session to be.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-4\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n  \u003C!-- Indicators -->\n  \u003Col class=\"carousel-indicators\">\n    \u003Cli data-target=\"#carousel-example-generic-4\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n    \u003Cli data-target=\"#carousel-example-generic-4\" data-slide-to=\"1\">\u003C/li>\n  \u003C/ol>\n\n  \u003C!-- Wrapper for slides -->\n  \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n    \u003Cdiv class=\"item active\">\n      \u003Cimg src=\"/images/blogimages/summit2018/yoga-ugc.jpg\" alt=\"Yoga and body balance session\">\n    \u003C/div>\n    \u003Cdiv class=\"item\">\n      \u003Cimg src=\"/images/blogimages/summit2018/for-funs-sake-ugc.jpg\" alt=\"Pinpoint pain points in GitLab session\">\n    \u003C/div>\n  \u003C/div>\n\n  \u003C!-- Controls -->\n  \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-4\" role=\"button\" data-slide=\"prev\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Previous\u003C/span>\n  \u003C/a>\n  \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-4\" role=\"button\" data-slide=\"next\">\n    \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n    \u003Cspan class=\"sr-only\">Next\u003C/span>\n  \u003C/a>\n\u003C/div>\n\nAs we grow, the summit grows with us. Now, our formidable resident summit expert [Kirsten](/company/team/#kirstenabma) is focusing on planning our summits FULL TIME. As we closed out our Cape Town gathering, she announced to wild cheers that our next one will be going down in May 2019, in New Orleans, LA, USA! Bring on the beignets!\n\nSee you next time 🇿🇦\n",[9,276,998,680],{"slug":3220,"featured":6,"template":683},"gitlab-summit-cape-town-recap","content:en-us:blog:gitlab-summit-cape-town-recap.yml","Gitlab Summit Cape Town Recap","en-us/blog/gitlab-summit-cape-town-recap.yml","en-us/blog/gitlab-summit-cape-town-recap",{"_path":3226,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3227,"content":3233,"config":3239,"_id":3241,"_type":13,"title":3242,"_source":15,"_file":3243,"_stem":3244,"_extension":18},"/en-us/blog/gitlab-supply-chain-security",{"title":3228,"description":3229,"ogTitle":3228,"ogDescription":3229,"noIndex":6,"ogImage":3230,"ogUrl":3231,"ogSiteName":670,"ogType":671,"canonicalUrls":3231,"schema":3232},"Introducing GitLab’s supply chain security direction and landscape","Learn about software supply chain security at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667466/Blog/Hero%20Images/GitLab-Sec.png","https://about.gitlab.com/blog/gitlab-supply-chain-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab’s supply chain security direction and landscape\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam White\"}],\n        \"datePublished\": \"2022-02-15\",\n      }",{"title":3228,"description":3229,"authors":3234,"heroImage":3230,"date":3236,"body":3237,"category":298,"tags":3238},[3235],"Sam White","2022-02-15","\n\n_This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in the blog post and linked pages are subject to change or delay. The development, release, and timing of products, features, or functionality remain at the sole discretion of GitLab, Inc._ \n\nWe would like to introduce you to our software supply chain security [direction](/direction/supply-chain/) and landscape.\n\nAn emerging concern in the software development space is being able to document the entire supply chain and development progress by creating a chain of custody starting from code creation, build, test, package, and going through deployment. \n\nGitLab's software supply chain security (SSCS) vision includes everything needed to securely deliver and run software with a high degree of confidence that not only your software, but also its surrounding cloud-native infrastructure, has not been compromised. \n\nIn the long-term, our strategy is to become a complete provider for all aspects of SSCS. Providing all of these aspects within a single application not only supports GitLab's broader Single Application Strategy but also provides numerous tangible benefits for users.\n\nAmong other things, using a single application:\n\n1. Minimizes the number of different tools that need to be hardened and monitored.\n1. Reduces the number of potential points of security failure as data is transferred between various tools.\n1. Enables seamless interoperability.\n1. Simplifies visibility and traceability for audits.\n\n## GitLab SSCS Framework\n\nGitLab has put together a framework describing the various aspects that are required to accomplish this based on feedback from customers and inspiration from common standards (such as [SLSA](https://slsa.dev/)), as well as thought leadership from industry analysts. Please note, however, that this framework is not necessarily representative of any other entity's opinion or perspective on the SSCS space.\n\nWe believe that there are five main aspects to consider when providing for a secure, end-to-end software supply chain.\n\n1. **Source** - includes the controls needed to be confident that both internal and external source code is safe from vulnerabilities and has not been compromised in any way.\n1. **Build** - includes rigorous requirements for the security and isolation of build environments as well as the automatic generation of provenance.\n1. **Consumption** - includes the ability to validate authenticity and source of any executed binaries. Supports requirements for securing the underlying host infrastructure itself.\n1. **Management Process** - spans across all other aspects of SSCS and includes both the tools and processes necessary to provide for ongoing visibility into SSCS continuous compliance requirements.\n1. **Tool Security** - spans across all other aspects of SSCS and includes the adoption of best practices for managing the security of the underlying tools themselves.\n\nYou can learn more about the SSCS framework in our [direction](/direction/supply-chain/).\n\n### GitLab helps keep your software supply chain secure\n\nGitLab has [numerous capabilities that support continuous compliance](/blog/gitlabs-newest-continuous-compliance-features-bolster-software/) and a secure software supply chain. Our newly released [“Guide to Software Supply Chain Security”](https://page.gitlab.com/resources-ebook-software-supply-chain-security.html) explains the urgency of protecting the supply chain now and also describes how this can be done while using GitLab.\n\nGitLab is a platform that [plays well with others](/handbook/product/gitlab-the-product/#plays-well-with-others) and can work together with other best-in-class security tools to provide complete end-to-end chain of custody throughout the development and deployment process. GitLab's vision is to partner closely with leading technologies in this space to provide an integrated, turnkey experience for end users.\n\n### What’s next\n\nAs a single DevOps platform, there are many opportunities to rise to the challenge of creating transparency around software components and artifacts. We welcome feedback on our [current position and vision](/direction/supply-chain/#current-position-and-vision) for the long-term direction of GitLab in SSCS. \n\nHere are a few of our near-term projects:\n\n- GitLab's [Runner Core](/direction/verify/runner_core/#strategic-priorities",[704,851,9],{"slug":3240,"featured":6,"template":683},"gitlab-supply-chain-security","content:en-us:blog:gitlab-supply-chain-security.yml","Gitlab Supply Chain Security","en-us/blog/gitlab-supply-chain-security.yml","en-us/blog/gitlab-supply-chain-security",{"_path":3246,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3247,"content":3252,"config":3258,"_id":3260,"_type":13,"title":3261,"_source":15,"_file":3262,"_stem":3263,"_extension":18},"/en-us/blog/gitlab-technical-certification-award-wins",{"title":3248,"description":3249,"ogTitle":3248,"ogDescription":3249,"noIndex":6,"ogImage":1055,"ogUrl":3250,"ogSiteName":670,"ogType":671,"canonicalUrls":3250,"schema":3251},"GitLab Technical Certifications program wins 5 awards at LearnX Conference","GitLab's Tech Certification programs won 5 different awards at this year's LearnX conference.","https://about.gitlab.com/blog/gitlab-technical-certification-award-wins","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Technical Certifications program wins 5 awards at LearnX Conference\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kendra Marquart\"}],\n        \"datePublished\": \"2021-12-03\",\n      }",{"title":3248,"description":3249,"authors":3253,"heroImage":1055,"date":3255,"body":3256,"category":704,"tags":3257},[3254],"Kendra Marquart","2021-12-03","\n\nIn June of this year our Professional Services team entered our [GitLab Technical Certification programs](/handbook/customer-success/professional-services-engineering/gitlab-technical-certifications/) into several different worldwide conferences and we are proud to announce that GitLab has won 5 awards at this year's LearnX learning impact awards! \n\nWe won 3 Gold awards for our [GitLab Certified CI/CD Specialist Self Paced Course](/services/education/gitlab-technical-certification-self-paced/) in the following categories: \n\n![LearnX gold award](https://about.gitlab.com/images/blogimages/learnxgold.png){: .shadow.small.left}\n\n- Best Certification Training Project \n- Best Game eLearning Design \n- Best Learning and Development Project \n\nWe won 2 Silver awards for our [GitLab Certified Associate Self Paced Course](/services/education/gitlab-technical-certification-self-paced/) in the following categories: \n\n![LearnX silver award](https://about.gitlab.com/images/blogimages/learnxsilver.png){: .shadow.small.left}\n\n- Best Micro/Bite Size eLearning Design \n- Best Content Curation Project\n\n## What is LearnX?\n\nThe LearnX Impact Awards is an annual event run by the LearnX Foundation, a not-for-profit organization promoting innovative workforce learning and supporting technologies. This conference is held once a year in November and highlights success in the learning and development space. \n\n## What GitLab Technical Certifications are Available?\n\nWe currenly offer the following [GitLab Technical Certifications](/handbook/customer-success/professional-services-engineering/gitlab-technical-certifications/), all of which are available as self-paced e-learnings in [GitLab Learn](/learn/) or as an [Instructor-Led class](/services/education/) with our Professional Services team.  \n\n\n",[9,680,266],{"slug":3259,"featured":6,"template":683},"gitlab-technical-certification-award-wins","content:en-us:blog:gitlab-technical-certification-award-wins.yml","Gitlab Technical Certification Award Wins","en-us/blog/gitlab-technical-certification-award-wins.yml","en-us/blog/gitlab-technical-certification-award-wins",{"_path":3265,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3266,"content":3272,"config":3277,"_id":3279,"_type":13,"title":3280,"_source":15,"_file":3281,"_stem":3282,"_extension":18},"/en-us/blog/gitlab-tiers",{"title":3267,"description":3268,"ogTitle":3267,"ogDescription":3268,"noIndex":6,"ogImage":3269,"ogUrl":3270,"ogSiteName":670,"ogType":671,"canonicalUrls":3270,"schema":3271},"New names for GitLab self-managed pricing tiers","Understand GitLab's pricing tiers and know which features your subscription gives you access to.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680136/Blog/Hero%20Images/gitlab-tiers-cover.png","https://about.gitlab.com/blog/gitlab-tiers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New names for GitLab self-managed pricing tiers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"William Chia\"}],\n        \"datePublished\": \"2018-04-20\",\n      }",{"title":3267,"description":3268,"authors":3273,"heroImage":3269,"date":3274,"body":3275,"category":298,"tags":3276},[2977],"2018-04-20","\n\n_Note: We've continued to iterate on our platform and pricing model since this blog post was published in 2018. To see what's new (including everything from security and container-focused capabilities to guest users), check out our [platform](https://about.gitlab.com/platform/), [pricing](https://about.gitlab.com/pricing/), and [why GitLab](https://about.gitlab.com/why-gitlab/) pages._\n\nAt GitLab, [iteration is one of our ore values](https://handbook.gitlab.com/handbook/values/#iteration). We’ve recently iterated on the names of our self-managed pricing tiers, so [Marcia](/company/team/#XMDRamos) and I got together and wrote this post\nto catch you up on the current options. We’ll explain each tier, and share how to figure out\nwhich features your subscription gives you access to.\n\n- [GitLab deployment options](#gitlab-deployment-options)\n- [GitLab self-hosted](#gitlab-self-managed)\n- [GitLab.com](#gitlabcom)\n- [Repository architecture](#repository-architecture)\n- [Subscription model](#subscription-model)\n- [Examples of use cases](#examples)\n\n## GitLab deployment options\n\nTo use GitLab, you have two options:\n\n- **GitLab self-managed**: Install, administer, and maintain your own GitLab self-managed instance.\n- **GitLab.com**: GitLab's SaaS offering. You don't need to install anything to use GitLab.com,\nyou only need to [sign up](https://gitlab.com/users/sign_in) and start using GitLab\nstraight away.\n\n### GitLab self-managed\n\nWith GitLab self-managed, you deploy your own GitLab instance on-premises or in the cloud. From\nbare metal to Kubernetes, you can [install GitLab almost\nanywhere](/install/). GitLab self-managed has both [free\nand paid options](/pricing/):\n**Core**, **Starter**, **Premium**, and **Ultimate**.\n\nYou can see a full list of features in each self-managed tier on the [self-managed feature\ncomparison](/pricing/feature-comparison/) page. For more details on storage amounts and CI/CD minutes per month, see our [pricing page](https://about.gitlab.com/pricing/).\n\n### GitLab.com\n\nGitLab.com is hosted, managed, and administered by GitLab, Inc., with\n[free and paid options](/pricing/) for individuals\nand teams: **Free**, **Bronze**, **Silver**, and **Gold**.\n\nTo support the open source community and encourage the development of\nopen source projects, GitLab grants access to **Gold** features\nfor all GitLab.com **public** projects, regardless of the subscription.\n\nYou can see a full list of features in each GitLab.com tier on the [GitLab.com feature\ncomparison](/pricing/feature-comparison/) page.\n\n### Repository architecture\n\nWe develop GitLab from two repositories, one for GitLab Community Edition (CE)\nand another for GitLab Enterprise Edition (EE):\n\n- [GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce/): open source code, [MIT-based\nlicense](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE), from which we deliver\nGitLab CE packages.\n- [GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee/): open core code, [proprietary\nlicense](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE), from which we deliver\nGitLab EE packages.\n\nGitLab EE grants you access to features by installing a license key. You\ncan also install GitLab EE and run it for free without a license key which will give you\naccess to the same features as CE. This makes it easier to upgrade later on.\n\nVisit the CE vs EE page to see [which GitLab installation method to\nchoose](/install/ce-or-ee/).\n\n### Subscription model\n\nGitLab Core contains all of the open source features of GitLab. Whether you are running GitLab\nCE or GitLab EE without a license key, you'll get access to the same Core features. The\nproprietary features of EE are unlocked by purchasing a license key.\n\nTiers are additive:\n- Starter contains all the features of Core\n- Premium contains all the features of Starter and Core\n- Ultimate contains all of the features of Premium, Starter, and Core\n\n![GitLab Core, Starter, Premium, Ultimate](https://about.gitlab.com/images/blogimages/gitlab-tiers-repos-and-tiers.jpg)\n\n### Examples\n\n- Consider a user of [GitLab Premium](/pricing/premium/) who wants to contribute to a given feature present in GitLab Core, e.g. Issue Boards. The code is submitted to the CE repo, therefore, it's open source code. The master branch of GitLab CE is then merged into GitLab EE. The CE code will be available to this Premium user in the next release.\n- Consider a user of GitLab Premium who wants to contribute to a given feature present only in Premium, e.g., Geo. The code is submitted directly to the EE repo, therefore, it's proprietary. The same is valid for Starter and Ultimate features.\n\n### Use cases\n\n#### GitLab self-managed use cases\n\n- I installed GitLab CE: I’m a Core user. I have access to Core features. The software I’m using is 100 percent open source.\n- I installed GitLab EE: the software I’m using is open core- it includes both open source and proprietary code.\n  - I don't have a subscription: I have access to Core features.\n  - I have a Starter subscription: I have access to Starter features.\n  - I have a GitLab Premium subscription: I have access to Premium features.\n  - I have a GitLab Ultimate subscription: I have access to Ultimate features.\n- I have a trial installation: I installed GitLab EE, and I’m an Ultimate user during the valid period of the trial. If the trial period expires and I don’t get a paid subscription (Starter, Premium, or Ultimate), I’ll become a Core user, with access to Core features.\n\n#### GitLab.com use cases\n\n- I use GitLab.com, a huge installation of GitLab EE. I’m using proprietary software.\n- I don’t have access to administration features as GitLab.com is administered by GitLab, Inc.\n- _Subscriptions_:\n  - I have a Bronze subscription: my private projects get access to Bronze features. My public projects get access to Gold features.\n  - I have a Silver subscription: my private projects get access to Silver features. My public projects get access to Gold features.\n  - I have a Gold subscription: my private projects get access to Gold features, as well as my public projects.\n  - I don’t have any paid subscriptions: I’m a Free GitLab.com user:\n      - I have access to Free features for private projects.\n      - I have access to Gold features for public projects.\n\n_Questions, comments? Let us know what you think below._\n",[680,9],{"slug":3278,"featured":6,"template":683},"gitlab-tiers","content:en-us:blog:gitlab-tiers.yml","Gitlab Tiers","en-us/blog/gitlab-tiers.yml","en-us/blog/gitlab-tiers",{"_path":3284,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3285,"content":3291,"config":3297,"_id":3299,"_type":13,"title":3300,"_source":15,"_file":3301,"_stem":3302,"_extension":18},"/en-us/blog/gitlab-value-stream-management-and-dora",{"title":3286,"description":3287,"ogTitle":3286,"ogDescription":3287,"noIndex":6,"ogImage":3288,"ogUrl":3289,"ogSiteName":670,"ogType":671,"canonicalUrls":3289,"schema":3290},"Improving visibility: GitLab's value stream and DORA metrics","Optimize DevOps with the new DORA metrics in GitLab Value Stream Management.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667845/Blog/Hero%20Images/gl15.jpg","https://about.gitlab.com/blog/gitlab-value-stream-management-and-dora","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Break the black box of software delivery with GitLab Value Stream Management and DORA Metrics\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2022-06-20\",\n      }",{"title":3292,"description":3287,"authors":3293,"heroImage":3288,"date":3294,"body":3295,"category":1513,"tags":3296},"Break the black box of software delivery with GitLab Value Stream Management and DORA Metrics",[2014],"2022-06-20","\n\nOur customers frequently tell us that despite being very effective DevOps practitioners, they still struggle to build a data-driven DevOps culture. They find it especially hard to answer the fundamental question:\n\n_What are the right things to measure?_\n\nThis becomes more challenging in enterprise organizations when there are hundreds of different development groups, and there's no normalization between how things are done or measured. Because of this, we see a strong interest from customers for metrics that would allow them to standardize between teams and benchmark themselves against the industry.\n\n![Value Streams Analytics helps you visualize and manage the DevOps flow from ideation to customer delivery.](https://about.gitlab.com/images/blogimages/2022-06-dora-vsa-overview.png){: .shadow}\nValue Streams Analytics helps you visualize and manage the DevOps flow from ideation to customer delivery.\n{: .note.text-center}\n\n## What Are DORA Metrics? \n\nWith the continued acceleration of digital transformation, most organizations realize that technology delivery excellence is a must for long-term success and competitive advantage. After seven years of data collection and research, the [DORA's State of DevOps research program](https://www.devops-research.com/research.html) has developed and validated four metrics that measure software delivery performance: [(1) deployment frequency, (2) lead time for changes, (3) time to restore service and (4) change failure rate.](https://docs.gitlab.com/ee/user/analytics/#devops-research-and-assessment-dora-key-metrics) \n\nIn GitLab, The One DevOps Platform, [Value Stream Analytics (VSA)](/solutions/value-stream-management/) surfaces a single source of insight for each stage of the software development process. The analytics are available out of the box for teams to drive performance improvements.\n\n## What does DORA bring to Value Stream Analytics?\n\nValue Stream Analytics (VSA) measures [the entire journey from customer request to release](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) and automatically displays the overall performance of the stream. Each stage in the value stream is transparent and compliant in a shared experience for everyone in the company. \n\nThis makes the VSA the single source of truth (SSoT) about what's happening within the entire software supply chain, with DORA’s metrics as the key measure of the value stream outputs. \n\n## How do Value Stream Analytics work?\n\nValue stream analytics measures the median time spent by issues or merge requests in each development stage.\n\nAs an example, a stage might begin with the addition of a label to an issue and end with the addition of another label:\n\n![Value stream analytics measures each stage from its start event to its end event.](https://about.gitlab.com/images/blogimages/2022-06-dora-vsa-stage.png){: .shadow}\nValue stream analytics measures each stage from its start event to its end event.\n{: .note.text-center}\n\nFor each stage, a table list displays the workflow items filtered in the context of that stage. [In stages based on labels](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#label-based-stages-for-custom-value-streams), the table will list Issues, and in stages based on Commits, it will list MRs:\n\n![The VSA MR table provides a deeper insight into stage time breakdown .](https://about.gitlab.com/images/blogimages/2022-06-dora-vsa-mr.png){: .shadow}\nThe VSA MR table provides a deeper insight into stage time breakdown.\n{: .note.text-center}\n\nThe tables provide a deep dive into the stage performance and allow users to answer questions such as:\n\n- How to easily see bottlenecks that are slowing down the delivery of value to customers?\n- How to reduce the time spent in each stage so I can deliver features faster and stay competitive? \n- How can we develop code faster?\n- How can we hand off to QA faster?  How can we push changes to Production more quickly?\n\nUsing the Filter results text box, you can filter by a project (example below) or parameter (e.g., Milestone, Label). \n\n![Value stream analytics filtering.](https://about.gitlab.com/images/blogimages/2022-06-dora-vsa-filter.png){: .shadow}\nValue stream analytics filtering.\n{: .note.text-center}\n\nNo login is required to view [Value stream analytics for projects](https://gitlab.com/gitlab-org/gitlab/-/value_stream_analytics) where you can become familiar with stream filtering, default stages and deep-dive tables. For a full view of the DORA metrics, you have to log in with your GitLab [Ultimate-tier](https://about.gitlab.com/pricing/) account or sign up for a [free trial](https://about.gitlab.com/free-trial/).\n\n## How to understand DevOps maturity and benchmark progress with the DORA metrics?\n\nDORA metrics can also provide answers to questions not related to VSA, such as:\n\n- How to become an elite team of DevOps professionals?\n- How do I perform vs. industry standards? \n- Is the organization better at DevOps this year than last?\n\n## Learn more about VSA and DORA:\n\n- Check out the GitLab Speed Run about DORA metrics in VSA:\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/wQU-mWvNSiI\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n- [GitLab DORA metrics API documentation](https://docs.gitlab.com/ee/api/dora/metrics.html)\n\n- [Step-by-step instructions for creating a custom value stream](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#create-a-value-stream-with-gitlab-default-stages)\n",[1164,851,9,2018,894],{"slug":3298,"featured":6,"template":683},"gitlab-value-stream-management-and-dora","content:en-us:blog:gitlab-value-stream-management-and-dora.yml","Gitlab Value Stream Management And Dora","en-us/blog/gitlab-value-stream-management-and-dora.yml","en-us/blog/gitlab-value-stream-management-and-dora",{"_path":3304,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3305,"content":3310,"config":3315,"_id":3317,"_type":13,"title":3318,"_source":15,"_file":3319,"_stem":3320,"_extension":18},"/en-us/blog/gitlab-visual-studio-extension",{"title":3306,"description":3307,"ogTitle":3306,"ogDescription":3307,"noIndex":6,"ogImage":906,"ogUrl":3308,"ogSiteName":670,"ogType":671,"canonicalUrls":3308,"schema":3309},"GitLab for Visual Studio, including code suggestions, available in Beta","GitLab for Visual Studio is now available in Beta, bringing GitLab Duo code suggestions to Visual Studio.","https://about.gitlab.com/blog/gitlab-visual-studio-extension","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab for Visual Studio, including code suggestions, available in Beta\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2023-06-29\",\n      }",{"title":3306,"description":3307,"authors":3311,"heroImage":906,"date":3312,"body":3313,"category":806,"tags":3314},[2370],"2023-06-29","\n\n\u003Ci>This blog is the latest post in an ongoing series about GitLab's journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nIn June, we shared our plans to [extend code suggestions](/blog/extending-code-suggestions/) to more IDEs, thereby continuing to enhance developer productivity. Over the past several weeks, we've been iterating quickly and we can share that GitLab for Visual Studio is available ([in Beta](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#beta)) from the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio).\n\nThe GitLab for Visual Studio extension supports [GitLab Duo](https://about.gitlab.com/gitlab-duo/) code suggestions for both [GitLab SaaS](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#enable-code-suggestions-on-gitlab-saas) and [GitLab self-managed](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#enable-code-suggestions-on-self-managed-gitlab).\n\nDownload it and let us know what you think and any issues you're having in our [feedback issue](https://gitlab.com/gitlab-org/editor-extensions/gitlab-visual-studio-extension/-/issues/38).\n\n## Getting started\nTo get started with the extension, download it from the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio). After the extension is downloaded and installed, you can follow our [setup instructions](https://gitlab.com/gitlab-org/editor-extensions/gitlab-visual-studio-extension/-/blob/main/README.md#setup) to get it configured.\n\n![GitLab for Visual Studio setup](https://about.gitlab.com/images/blogimages/gitlab-visual-studio-extension-setup.png)\n\n## Using the extension\nOnce you've set up the extension, make sure things are configured properly and authentication is working by checking the status bar icon.\n\n![GitLab for Visual Studio status bar icon](https://about.gitlab.com/images/blogimages/gitlab-visual-studio-extension-status-bar-icon.png)\n\nIf everything looks good, you're ready to start receiving code suggestions as you work. Just start typing and GitLab Duo will automatically provide you suggestions inline. You can press \u003Ckbd>Tab\u003C/kbd> to accept the suggestions or just keep typing to receive new suggestions.\n\n![GitLab for Visual Studio suggestions](https://about.gitlab.com/images/blogimages/gitlab-visual-studio-extension-suggestions.gif)\n\n## Iterating on AI/ML features\nWhile this brings us one step closer to reaching developers working in Visual Studio, we still have our eyes on the [JetBrains IDEs](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin) as well as a native integration for [Neovim](https://gitlab.com/gitlab-org/editor-extensions/gitlab.vim). You can track these projects and stay tuned for future announcements regarding their availability.\n\nWe're also working on a [GitLab Language Server for code suggestions](https://gitlab.com/gitlab-org/editor-extensions/gitlab-language-server-for-code-suggestions). This allows us to not only standardize and iterate faster on our IDE extensions, but for users of IDEs and Editors to use GitLab Duo code suggestions even if we're not officially providing an extension. We look forward to providing more documentation and working with the community on this project in the future.\n\nThese efforts are just the start of how we're bringing GitLab Duo capabilities throughout the software development lifecycle to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":3316,"featured":6,"template":683},"gitlab-visual-studio-extension","content:en-us:blog:gitlab-visual-studio-extension.yml","Gitlab Visual Studio Extension","en-us/blog/gitlab-visual-studio-extension.yml","en-us/blog/gitlab-visual-studio-extension",{"_path":3322,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3323,"content":3328,"config":3335,"_id":3337,"_type":13,"title":3338,"_source":15,"_file":3339,"_stem":3340,"_extension":18},"/en-us/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities",{"title":3324,"description":3325,"ogTitle":3324,"ogDescription":3325,"noIndex":6,"ogImage":736,"ogUrl":3326,"ogSiteName":670,"ogType":671,"canonicalUrls":3326,"schema":3327},"GitLab Webhooks get smarter with self-healing capabilities","Introducing changes to webhook self-healing behavior, which reduce manual intervention and improve reliability. Discover the impact on your integrations and how to prepare.","https://about.gitlab.com/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Webhooks get smarter with self-healing capabilities\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n        \"datePublished\": \"2024-11-14\",\n      }",{"title":3324,"description":3325,"authors":3329,"heroImage":736,"date":3331,"body":3332,"category":3056,"tags":3333,"updatedDate":3334},[3330],"Magdalena Frankiewicz","2024-11-14","We're excited to announce upcoming changes to how GitLab handles webhooks, aimed at improving reliability and reducing manual intervention. These changes will affect GitLab.com users in the coming weeks. For GitLab Self-Managed users, the current auto-disabling webhook behavior is behind an existing [ops flag `auto_disabling_webhooks`](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#auto-disabled-webhooks). The changes described here will be introduced behind the same feature flag.\n\nThis improvement is the result of a valuable community contribution by [Phawin Khongkhasawan](https://gitlab.com/lifez), exemplifying the power of our open source community in driving GitLab forward.\n\n## What's changing?\n\n- Currently, webhooks that result in 4xx errors become permanently disabled after multiple failures. With this update, all webhooks, regardless of the error type (4xx or 5xx), will have the ability to self-heal.\n- Failing webhooks will be temporarily disabled with an increasing backoff period, up to a maximum of 1 day. After a webhook fails for 40 times successively, it becomes permanently disabled.\n- All types of errors (4xx, 5xx, network errors, etc.) will be treated the same way, allowing for more predictable behavior and easier troubleshooting.\n- Webhooks that are currently permanently disabled will be migrated to be temporarily disabled with 40 failures, so they will remain permanently disabled.\n\n## Why this change matters\n\nReduced manual intervention: You'll no longer need to manually re-enable webhooks that have been disabled due to temporary issues.\n* **Improved reliability:** Webhooks will automatically attempt to recover from transient errors, ensuring your integrations remain functional.\n* **Better handling of temporary issues:** This change accounts for scenarios like temporary outages, deployments, or configuration changes that might cause temporary webhook failures.\n\n## What you need to do\n\n**1. Review your webhooks:** Take this opportunity to review your existing webhooks. If you have any that you no longer need, consider deleting them.\n\n**2. Update your monitoring:** If you rely on webhook status for monitoring, update your processes to account for the new behavior where webhooks may self-heal.\n\n**3. Test your integrations:** Once the change is rolled out, test your integrations to ensure they behave as expected with the new webhook handling.\n\n## Timeline and rollout\n\nThis feature is expected to be rolled out in GitLab 17.11.\n- For GitLab.com users, the changes will be applied automatically.\n- For Self-Managed and Dedicated users, the changes will only affect instances that have the auto_disabling_webhooks ops flag enabled.\n\n## Feedback and support\n\nWe value your feedback! If you encounter any issues or have suggestions regarding this change, please comment on our [webhook feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/503733).\n\nFor any questions or concerns, please reach out to [GitLab Support](https://about.gitlab.com/support/) or consult our [webhooks documentation](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html).\n\nStay tuned for more updates, and thank you for being a part of the GitLab community!",[266,1166,478,9],"2025-03-24",{"slug":3336,"featured":6,"template":683},"gitlab-webhooks-get-smarter-with-self-healing-capabilities","content:en-us:blog:gitlab-webhooks-get-smarter-with-self-healing-capabilities.yml","Gitlab Webhooks Get Smarter With Self Healing Capabilities","en-us/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities.yml","en-us/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities",{"_path":3342,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3343,"content":3349,"config":3354,"_id":3356,"_type":13,"title":3357,"_source":15,"_file":3358,"_stem":3359,"_extension":18},"/en-us/blog/gitlabs-2018-product-vision",{"title":3344,"description":3345,"ogTitle":3344,"ogDescription":3345,"noIndex":6,"ogImage":3346,"ogUrl":3347,"ogSiteName":670,"ogType":671,"canonicalUrls":3347,"schema":3348},"GitLab's 2018 Product Vision: Prototype demo","Take an early look at where we're heading this year.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671288/Blog/Hero%20Images/gitlab-live-event.png","https://about.gitlab.com/blog/gitlabs-2018-product-vision","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's 2018 Product Vision: Prototype demo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Pundsack\"}],\n        \"datePublished\": \"2018-02-26\",\n      }",{"title":3344,"description":3345,"authors":3350,"heroImage":3346,"date":3351,"body":3352,"category":298,"tags":3353},[1973],"2018-02-26","\nAt GitLab, we believe there's something magical about a video demo as a way to\n[convey strategic\nvision](/handbook/product/index.html#communicating-product-vision). We've\ncreated this video to internally align where we're going; and since we're\n[transparent by\ndefault](https://handbook.gitlab.com/handbook/values/#transparency), you get to see\nit as well!\n\n\u003C!-- more -->\n\nSo sit back, [watch the video](https://youtu.be/RmSTLGnEmpQ), follow\nalong with [the\npresentation](https://docs.google.com/presentation/d/19dZ1Y4us11B_96YoXvgQL4aBXPy2iNYRId0vmTulnnQ/edit?usp=sharing),\nor read below for a lightly edited transcript of the video. You can also [play\nwith the prototype](https://framer.cloud/UaofH/index.html) yourself (click the\nheader to move to the next page, click the left sidebar to move back) or\n[follow our progress](/direction/).\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/RmSTLGnEmpQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Introduction\n\nToday I’m going to talk about GitLab’s product vision for 2018. Specifically,\nI’m going to show a prototype of what the product might look like.\n\nAs you can imagine with a product vision as extensive as ours, there’s a lot to\ncover. So if you only remember three things from this presentation, know that:\n\n1. We’re going after the **complete DevOps** lifecycle, and specifically,\n2. we want **Operations and Security** to use GitLab as a primary interface, and\n3. a [single application](/topics/single-application/) covering this entire scope brings emergent benefits, specifically that people can work **concurrently**, on the same data, with the same interface.\n\nSo hopefully it’s\n[obvious](/blog/devops-strategy/)\n[by](/blog/gitlab-raises-20-million-to-complete-devops/)\n[now](/blog/from-dev-to-devops/) that we’re going\nfrom covering the development lifecycle to covering the entire DevOps lifecycle.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/dev2devops.png\" alt=\"Dev to DevOps\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>From Dev to DevOps\u003C/small>*\n\nBut traditional DevOps tools only focus on the intersection between Dev and Ops,\nand GitLab is going to deliver a complete scope for both Dev and Ops. In\nparticular, that means we’re not just looking at how Developers can get their\ncode into production, but how Operations can then monitor and manage those\napplications and underlying infrastructure. A big milestone for GitLab will be\nwhen Operations people log into GitLab every day and consider it their main\ninterface for getting work done.\n\nBut even that’s not really sufficient, as we’re redefining what the scope of\nDevOps even is; we’re also covering Security and Business needs (such as project\nmanagers). Rather than coming up with some crazy DevSecBizOps name, we’re just\ncalling it DevOps, and putting it all into a single application.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/devsecbizops.png\" alt=\"DevSecBizOps\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>No DevSecBizOps; a single application for DevOps\u003C/small>*\n\nAnd with that, each group gets an experience tailored to their needs, but shares\nthe same data and interface as everyone else, so collaboration is easy. Imagine\nan Ops person finds an issue in production, drills down to find the application\nwith the problem, and sees that a recent deploy caused the problem.\nSimultaneously, a dev gets alerted that their recent deploy triggered a change\nin production, goes to the merge request and sees the performance change right\nthere. When Dev, Ops, and Security talk, they’re looking at the same data, but\nfrom their own point of view.\n\nNow the scope we’re going after is quite large, with a lot of new categories\nbeing introduced this year. I won’t go into all of these today, but instead I\nwant to focus on a couple flows that paint a picture of how this could look.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/product-categories.png\" alt=\"Product categories\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>New product categories in 2018\u003C/small>*\n\n## Interactive prototype\n\nFor this, I’ll switch over to an [interactive\nprototype](https://framer.cloud/UaofH/index.html). *[Note: if you want to try it for yourself, click the header to\nmove to the next page, click the left sidebar to move back.]* While this may\nlook like a fully functioning instance of GitLab, it is just a demo and many of\nthese features have not been implemented yet.\n\n### Development flow\n\nI’ll start by showing a merge request.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/development.png\" alt=\"Developer Flow\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>Developer Flow: Merge Request\u003C/small>*\n\nOne of the new elements we see is a “Test summary” which shows a deeper\nunderstanding of your test results. Using standard JUnit XML output, we can tell\nexactly which tests fail, and provide that information in a nice summary format.\n\nWe also see links to the binary artifacts and container images associated with\nthis merge request.\n\nAs I scroll down, we see a lot of information about the extensive collection of\ntests we’ve run on the code.\n\nFirst we see the code quality section, which we’ve had for a while.\n\nThen the relatively new Security section with static [application security\ntesting](/topics/devsecops/) to find vulnerabilities in your *code* or your code's dependencies,\ndynamic application security testing to find vulnerabilities while actually\n*running your app*, and an analysis of any vulnerabilities in any of your\nunderlying Docker layers.\n\nWe’ll also show how your application performance has changed.\n\nAnd lastly, we’ll check your dependencies for any violations of your company’s\nlicense policy.\n\nNow, this is a LOT to cover for every merge request, so we have separate issues\nto redesign for all this new information, but I wanted to show it all to you now\nto see how much we’re doing automatically for you.\n\nDown below all of that is an enhanced code diff that highlights any code you\nshould pay attention to because of code quality concerns or missing test\ncoverage.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/code-coverage.png\" alt=\"code coverage\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>Code coverage and alerts\u003C/small>*\n\nThis is all part of the “shift left” movement, where important quality,\nsecurity, and performance tests that may have once been run manually, if at all,\nand usually much later in the development lifecycle, are now being run\nautomatically as soon as the first code is written.\n\nThere’s a lot more planned, but this is a good idea of the direction we’re going\nin to help Developers get their ideas into production faster.\n\n### Operations flow\n\nBut that only covers part of our vision, because there’s also\nthe Operations point of view. And a big milestone for our DevOps vision is when\nOperations start using GitLab as their primary interface.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/operations-health.png\" alt=\"Operations health\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>Operations flow: operations health dashboard\u003C/small>*\n\nThere’s a long way to go, but here we’re answering the question, “How is\nproduction doing?” In this case we’re seeing a group with four projects in it, and\na quick green/yellow/red indicator of how those projects are doing. We’ve put a\ngraph of the Apdex score there to represent the one-metric-to-watch.\n\nBelow the projects is a view of the cluster, including CPU and memory usage,\npossibly indicating when you need to scale up or down the cluster size.\n\nNow, if there was an indication that something was wrong, you’d be able to drill\ndown and see more details and rectify the situation.\n\nBut that’s only the first-level understanding of operations. I mean, if we’ve\ngot the data about how things are doing, why not proactively alert you to the\nproblem? Well, that’s the second level, and a natural step. But we’re not going\nto stop there. The third level is to automatically detect *and resolve* any\nissues. If your app needs more resources, just autoscale it. If you then hit a\nlimit on the cluster, well, add a node to the cluster automatically. The\nOperations experience then should really just be that I go to work in the morning\nand see an email summary of what has happened, without me having to do anything.\n\nBut autoscaling is just scratching the surface, as Operations involves a lot\nmore, from application, infrastructure, and network monitoring, to security\npatches. After we’ve got this breadth as a structure, we look forward to the\ncustomer feature requests.\n\n### Security flow\n\nSo that covers Dev and Ops, but we’ve got a lot of security\nfeatures in the product now. How about treating Security folks as first-class\ncitizens and giving them their own Security Audit view?\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/security-audit.png\" alt=\"Security audit\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>Security flow: security audit\u003C/small>*\n\nThis is your one-stop-shop to see what security vulnerabilities have been\ndetected across the group, showing any automatic or manual actions taken to\naddress the vulnerabilities, and of course letting you click into details.\n\nIn the top left we’re reporting an overall success rate in hitting our own\ninternal SLAs for security vulnerabilities.\n\n### Full circle\n\nLet’s drill down on one of these vulnerabilities.\n\n\u003Cimg src=\"/images/blogimages/2018-product-vision/automatic-updates.png\" alt=\"Automatic updates\" style=\"width: 700px;\"/>{: .shadow}\u003Cbr/>\n*\u003Csmall>Automatic updates for security vulnerabilities\u003C/small>*\n\nWe see that the GitLab Bot automatically created a merge request to upgrade one\nof our dependencies because it noticed that a new version was released.\n\nSince the tests all pass, and of course the merge request fixed the\nvulnerability, the merge request was automatically merged by the Bot as well.\n\nBut, to bring it full circle, l’m showing here that after merging, the CI/CD\npipeline started deploying automatically to Production. I mean, why leave a\nknown, fixable security vulnerability live any longer than it needs to, right?\n\nBut, in this case, even though all tests passed, we still saw the error rate\njump to more than five percent, so we automatically stopped the rollout process, and\nactually rolled back to the last-known good version immediately.\n\nThen, the Bot detects this and automatically reverts the merge request so we can\nleave `master` in a good state.\n\nPhew.\n\n## Summary\n\nSo, wrapping it up:\n1. We’re going after the **complete DevOps** lifecycle,\n2. we want **Operations and Security** to be our new favorite users, and\n3. we want teams working **concurrently**.\n\nAnd that’s the GitLab Product Vision for 2018!\n",[680,9],{"slug":3355,"featured":6,"template":683},"gitlabs-2018-product-vision","content:en-us:blog:gitlabs-2018-product-vision.yml","Gitlabs 2018 Product Vision","en-us/blog/gitlabs-2018-product-vision.yml","en-us/blog/gitlabs-2018-product-vision",{"_path":3361,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3362,"content":3367,"config":3374,"_id":3376,"_type":13,"title":3377,"_source":15,"_file":3378,"_stem":3379,"_extension":18},"/en-us/blog/gitlabs-newest-continuous-compliance-features-bolster-software",{"title":3363,"description":3364,"ogTitle":3363,"ogDescription":3364,"noIndex":6,"ogImage":3230,"ogUrl":3365,"ogSiteName":670,"ogType":671,"canonicalUrls":3365,"schema":3366},"GitLab strengthens supply chain with compliance features","Business leaders and DevOps teams can continuously mitigate the risk of cloud-native environments and use guard rails to automate software compliance.","https://about.gitlab.com/blog/gitlabs-newest-continuous-compliance-features-bolster-software","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab’s newest continuous compliance features bolster software supply chain security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2022-02-09\",\n      }",{"title":3368,"description":3364,"authors":3369,"heroImage":3230,"date":3371,"body":3372,"category":704,"tags":3373},"GitLab’s newest continuous compliance features bolster software supply chain security",[3370],"Cindy Blake","2022-02-09","\n_This blog post contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only._\n\n_Please do not rely on this information for purchasing or planning purposes._\n\n_As with all projects, the items mentioned in the blog post and linked pages are subject to change or delay. The development, release, and timing of products, features, or functionality remain at the sole discretion of GitLab, Inc._\n\nCompliance and risk management have become the responsibility of everyone in an organization, and DevOps is no exception. To ensure the greatest level of security with the least exposure, business leaders must be able to trust that when they adopt or create compliance frameworks and policies, the associated rules will be able to be automatically deployed and enforced throughout the software development lifecycle. GitLab’s newest functionality and our near-term roadmap will help companies shift compliance left just as they have done for security, and also simplify governance and risk management across the entire software lifecycle.\n\n## Software supply chain risks\n\nHigh-profile attacks on software supply chains, and the resulting demand for tighter controls in software development and deployment by the U.S. government and customers worldwide, have put compliance and risk management front and center. Companies are not only struggling to protect their traditional architecture, but cloud-native transformation has introduced new attack surfaces that require [DevSecOps](/topics/devsecops/) teams to secure more than just the code. Containers, orchestrators, microservices, and the cloud environment as a whole make the job of identifying and mitigating vulnerabilities and risks even more challenging.\n\nTraditional application security is [no longer enough](/blog/are-you-ready-for-the-newest-era-of-devsecops/) in the era of DevOps automation and growth of cloud-native applications. In addition to testing and monitoring the new attack surfaces, complicated toolchains full of disparate products make it difficult to gain the visibility necessary to meet compliance demands and manage risk.\n\nAt GitLab, we remain focused on innovating an end-to-end DevOps Platform that organizations can leverage to simplify all aspects of security, compliance, governance, and risk management – no matter if you are developing software in a traditional environment, a cloud-native workspace, or a hybrid of the two.\n\nSecurity and compliance remain key focuses for our product investment. Let’s take a quick look at recent innovations along with what’s coming in the near-term within the three themes of:\n\n- Enabling secure cloud-native development\n- Security governance\n- Leveraging the DevOps Platform for better security and compliance\n\nAll of the information from these additional scans is available within existing workflows so DevSecOps teams can get the actionable insight they need to quickly find and fix issues from within the continuous integration (CI) pipeline. Here is how it looks for the developer:\n\n![WIP: Feature branch](https://about.gitlab.com/images/blogimages/cindyfeaturebranch.png){: .shadow}\n\nAt the same time, security pros get early insight into risks as vulnerabilities are merged into feature branches (pre-production). The [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) helps review and triage of vulnerabilities not resolved by the developer. This information is available at the project and group levels.\n\n![Vulnerability report](https://about.gitlab.com/images/blogimages/cindyvulnerabilityreport.png){: .shadow}\n\nThese capabilities are part of the existing GitLab Ultimate tier – no integrations or added costs required.\n\n## Enabling secure cloud-native development\n\nHere’s **what’s new** in GitLab to help DevSecOps secure cloud-native development:\n\n**Infrastructure as code scanning** – Many DevSecOps teams have started to implement [IaC](/direction/delivery/infrastructure_as_code/) as part of their software development lifecycle, so GitLab has introduced robust scanning tools that can analyze the IaC configuration files (i.e., YAML, Kubernetes, CloudFormation, Terraform) to identify common security issues of these new attack surfaces.\n\n**More flexible container scanning** – While we already had container scanning available in GitLab, we have switched to [Trivy open-source container vulnerability scanner technology](/releases/2021/06/22/gitlab-14-0-released/#container-scanning-integration-with-trivy) for pre-production environments. Trivy covers more languages and has better results than previous scanners. We also are beta-testing container scanning for production environments and [cluster image scanning](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html).\n\n**API security** – APIs represent a tremendous attack surface when not properly secured. We are using the state-of-the-art fuzzing technology [acquired from Peach Tech and Fuzzit](/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html) to test APIs. In addition, our [dynamic application security testing for APIs](https://docs.gitlab.com/ee/user/application_security/dast_api/) (DAST) is in beta.\n\nResults from all of the scanners (IaC, containers and APIs) are incorporated into GitLab’s CI pipeline alongside other scan results enabling correction before configuration errors manifest in production.\n\nHere’s **what’s next** that will help DevSecOps secure cloud-native development:\n\n**Production container scanning** – We plan to make production container scanning generally available to scan containers for vulnerabilities after they’ve [already been deployed](/direction/secure/composition-analysis/container-scanning/). This will help surface vulnerabilities from new exploits not tested for during development.\n\n**DAST API scanner** – We will be making our [DAST API scanner](/direction/secure/dynamic-analysis/api-security/#whats-next--why)  generally available to enable broader coverage, better quality, and easier configuration. This will help you apply even greater defense-in-depth.\n\n**API Discovery** – DevSecOps teams will be able to leverage access to code to automatically [discover and test the APIs](https://gitlab.com/gitlab-org/gitlab/-/issues/38384)  being used throughout the organization’s software supply chain. Understanding the attack surface is important to protecting it.\n\n## Security governance\n\nHere’s **what’s new** to help organizations establish and manage security and compliance guardrails that allow developers to run fast while also managing risk:\n\n**Continuous compliance** – Organizations can shift compliance left, similar to security, to identify and mitigate violations early on to avoid delays at go-live. Compliant workflow automation enables a DevOps admin to assign a compliance framework to a project and enforce scans and other common controls across all project pipelines. Developers may not easily sidestep required controls.\n\n**Policy Engine** – GitLab automates a comprehensive set of security and compliance scans within the CI pipeline. Automating what happens when exceptions are encountered has been fairly simplistic. Now, GitLab provides users with a [policy editor](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor) that provides more fine-grained rules that can determine what approvals are required helping you manage your own unique appetite for risk.\n\nThe policy engine is part of a larger direction for [Security Orchestration](/direction/govern/security_policies/security_policy_management/) that includes continued iteration on Security Alert Management, Security Policy Management, and Security Approvals.\n\nHere’s **what’s next** that will help organizations establish and manage security governance:\n\n**Compliance checks in MRs** – GitLab is further automating continuous [compliance checks into the developer’s daily workflow](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html#approval-status-and-separation-of-duties) in a similar way as security scans. This will help compliance essentially shift left so developers can find and fix compliance violations early and stay on schedule.\n\n**Governance at the group level** – We are working to bring the controls found at the project level up to the group level so that policies may be more easily applied across a broad set of projects. This project is tied to the completion of workspaces.\n\n## The benefits of a single DevOps Platform\n\nHere’s **what’s new** that enables you to leverage the benefits of a single DevOps Platform in GitLab’s Ultimate version:\n\n**Unified vulnerability management and reporting** – We’ve consolidated security findings into a [single dashboard](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) that aggregates information from GitLab and other sources, including third-party scanners, our [security partners](/partners/technology-partners/#security), and more. You can [pull in vulnerability data from other systems](/blog/three-things-you-might-not-know-about-gitlab-security/), manual pen testing, bug bounty programs, or even from security tools that don’t run in GitLab pipeline jobs. Vulnerability management in GitLab Ultimate helps you manage all of your [software vulnerability information](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) in one place to efficiently triage and remediate findings.\n\n**Proprietary SAST scanner** – We have [replaced some of our language-specific open-source scanners (OSS)](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) with [Semgrep](https://r2c.dev/blog/2021/introducing-semgrep-for-gitlab/), a proprietary scanner, to improve coverage, accuracy, and speed. Semgrep's flexible rule syntax is ideal for streamlining the [GitLab Custom Rulesets](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets) feature for extending and modifying detection rules. It also allows GitLab customers access to Semgrep's community rules.\n\nHere’s **what’s next** that will enable organizations to leverage the benefits of a single DevOps Platform in GitLab’s Ultimate version:\n\n**Software supply chain security** – Organizations will be able to secure the full software supply chain with one application while improving confidence in its integrity and security. GitLab has put together a framework describing the various aspects that are required to accomplish this based on feedback from customers, inspiration from common standards (such as SLSA), as well as thought leadership from industry analysts. We would love your thoughts and contributions to these epics. Check out our [Software Supply Chain Security direction page](/direction/supply-chain/).\n\n**Inline security training** – Developers will have just-in-time access to popular third-party security training as they encounter vulnerabilities. For instance, if a vulnerability is detected, a module will pop up that the developer can click on to learn more, including what the vulnerability is and how to fix it. This optimizes security training with an immediate need. More details coming soon.\n\n**Intelligent code security** – Leveraging a previous acquisition, GitLab plans to help organizations automatically detect and remediate insecure coding practices using [machine learning](/direction/modelops/ai_assisted/#categories). This will help our customers further reduce risk and technical debt.\n\nGitLab is uniquely transparent. By making our product roadmaps public, we encourage contribution and iteration. We invite you to contribute your ideas by checking out our [product directions pages](/direction/#job-to-be-done) and commenting on [upcoming releases](/upcoming-releases/).\n",[851,704,9],{"slug":3375,"featured":6,"template":683},"gitlabs-newest-continuous-compliance-features-bolster-software","content:en-us:blog:gitlabs-newest-continuous-compliance-features-bolster-software.yml","Gitlabs Newest Continuous Compliance Features Bolster Software","en-us/blog/gitlabs-newest-continuous-compliance-features-bolster-software.yml","en-us/blog/gitlabs-newest-continuous-compliance-features-bolster-software",{"_path":3381,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3382,"content":3388,"config":3393,"_id":3395,"_type":13,"title":3396,"_source":15,"_file":3397,"_stem":3398,"_extension":18},"/en-us/blog/gko-on-ocp",{"title":3383,"description":3384,"ogTitle":3383,"ogDescription":3384,"noIndex":6,"ogImage":3385,"ogUrl":3386,"ogSiteName":670,"ogType":671,"canonicalUrls":3386,"schema":3387},"How to install and use the GitLab Kubernetes Operator","Follow these step-by-step instructions to set up the GitLab Kubernetes Operator on a Kubernetes cluster.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682191/Blog/Hero%20Images/GKO-Thumbnail.png","https://about.gitlab.com/blog/gko-on-ocp","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to install and use the GitLab Kubernetes Operator\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2021-11-16\",\n      }",{"title":3383,"description":3384,"authors":3389,"heroImage":3385,"date":3390,"body":3391,"category":849,"tags":3392},[803],"2021-11-16","\n\nThe GitLab Kubernetes Operator was released on October 12, 2021.\n\n## What is the GitLab Kubernetes Operator?\n\nThe GitLab Operator allows you to install and run an instance of GitLab in a vanilla Kubernetes or OpenShift cluster. Kubernetes operators increase the reliability and availability of your applications by automating Day 2 operations such as upgrading components, management of data integrity, application reconfiguration, automatic recovery from a failure, and autoscaling.\n\n## Installing the GitLab Kubernetes Operator on an OpenShift Container Platform cluster\n\nIn this short post, we show you how to install and run the GitLab Operator to create a GitLab instance on an OpenShift Container Platform cluster, which we have already preinstalled:\n\n![OCP console](https://about.gitlab.com/images/blogimages/gko-on-ocp/0-ocp-console.png){: .shadow.medium.center.wrap-text}\nThe OpenShift Container Platform console\n{: .note.text-center}\n\nInspecting the running pods of the OpenShift cluster, we see that Prometheus is already being used as the metrics server, which is a prerequisite for the installation of the GitLab Operator:\n\n![Prometheus up and running](https://about.gitlab.com/images/blogimages/gko-on-ocp/1-prometheus-up.png){: .shadow.medium.center.wrap-text}\nPrometheus up and running on cluster\n{: .note.text-center}\n\nAlso, we verify that the gitlab-system namespace does not yet exist:\n\n![gitlab namespace not present](https://about.gitlab.com/images/blogimages/gko-on-ocp/2-no-gitlab-sys-namespace.png){: .shadow.medium.center.wrap-text}\ngitlab-system namespace non-existent\n{: .note.text-center}\n\nAnother prerequisite is cert-manager, which automates the management and issuance of TLS certificates. Let’s use the OpenShift OperatorHub to install and instantiate an instance of cert-manager. We first verify that one is not running. Then we head to the OperatorHub and install the cert-manager Operator:\n\n![cert-manager in OperatorHub](https://about.gitlab.com/images/blogimages/gko-on-ocp/3-cert-mgr-in-operatorhub.png){: .shadow.medium.center.wrap-text}\nInstalling cert-manager using its operator in OperatorHub\n{: .note.text-center}\n\n**NOTE:** Once the GitLab Kubernetes Operator is certified with OpenShift, it will have its own tile in the OperatorHub.\n{: .alert .alert-info}\n\nThen we create an instance of cert-manager by using its newly installed operator:\n\n![cert-manager instance creation](https://about.gitlab.com/images/blogimages/gko-on-ocp/4-create-instance-cert-mgr.png){: .shadow.medium.center.wrap-text}\nCreating an instance of cert-manager using its operator\n{: .note.text-center}\n\nIn preparation of the GitLab Operator installation, we create the namespace gitlab-system, under which all of the GitLab resources will be:\n\n![gitlab-system namespace creation](https://about.gitlab.com/images/blogimages/gko-on-ocp/5-create-gitlab-sys-namespace.png){: .shadow.medium.center.wrap-text}\nCreating the gitlab-system namespace\n{: .note.text-center}\n\nTo install the GitLab Operator, we define two environment variables: one is to set the version of the GitLab Operator we want to use and the other one is to set the platform for which we are targeting the Operator. In this case, it is OpenShift. We then apply the GitLab Operator Custom Resource Definition or CRD to the cluster, which creates the operator, by entering the following command:\n\n```\nexport GL_OPERATOR_VERSION=\"0.1.0\" \nexport PLATFORM=\"openshift\"\nkubectl apply -f https://gitlab.com/api/v4/projects/18899486/packages/generic/gitlab-operator/${GL_OPERATOR_VERSION}/gitlab-operator-${PLATFORM}-${GL_OPERATOR_VERSION}.yaml\n```\n\nAnd here's is an example screenshot of what the output of this command would be like:\n\n![application of the CRD to the cluster](https://about.gitlab.com/images/blogimages/gko-on-ocp/6-applying-the-crd.png){: .shadow.medium.center.wrap-text}\nApplying the GitLab Kubernetes Operator to the OpenShift cluster\n{: .note.text-center}\n\nAs we watch the pods in the gitlab-system namespace, we see the creation of two pods for the gitlab-controller-manager:\n\n![operator pods](https://about.gitlab.com/images/blogimages/gko-on-ocp/7-watching-operator-pods-creation.png){: .shadow.medium.center.wrap-text}\nGitLab Kubernetes Operator pods being created on the OpenShift cluster\n{: .note.text-center}\n\nThe GitLab Kubernetes Operator is now installed on the OpenShift Container Platform cluster. Next, we need to use this newly installed operator to create an instance of GitLab.\n\n## Creating a GitLab instance on the cluster using the GitLab Kubernetes Operator\n\nTo create an instance of GitLab, we create a Custom Resource file called mygitlab.yaml to provide information, such as domain name and certmanager issuer email, for the GitLab Operator to use during the creation of the GitLab instance. Here is a parameterized example of the contents for this file:\n\n```\napiVersion: apps.gitlab.com/v1beta1\nkind: GitLab\nmetadata:\n  name: gitlab\nspec:\n  chart:\n    version: \"[REPLACE WITH THE CHART VERSION]\"\n    values:\n      global:\n        hosts:\n          domain: [REPLACE WITH YOUR DOMAIN NAME]\n        ingress:\n          configureCertmanager: true\n      certmanager-issuer:\n        email: [REPLACE WITH YOUR EMAIL]\n```\n\nAnd here is an example screenshot of what this file would look like with actual values for the parameters:\n\n![creating-gitlab-yaml-file](https://about.gitlab.com/images/blogimages/gko-on-ocp/8-creating-mygitlab-yaml.png){: .shadow.small.center.wrap-text}\nCreating mygitlab.yaml, the custom resource file\n{: .note.text-center}\n\nWe then apply the Custom Resource to the cluster. This action will kickstart the creation of all the pods needed for the instantiation of a GitLab instance on the cluster:\n\n![applying the custom resource to the cluster](https://about.gitlab.com/images/blogimages/gko-on-ocp/9-applying-the-cr.png){: .shadow.medium.center.wrap-text}\nApplying the custom resource file to the cluster\n{: .note.text-center}\n\nAfter a few minutes, when the GitLab instance is up and running, we obtain its external IP address from the nginx ingress controller installed by the GitLab Operator by entering the following command:\n\n> kubectl -n gitlab-system get services -o wide gitlab-nginx-ingress-controller\n\nHere's an example screenshot of its output:\n\n![getting the external ip](https://about.gitlab.com/images/blogimages/gko-on-ocp/10-get-external-ip.png){: .shadow.medium.center.wrap-text}\nObtaining the external IP address for our newly created GitLab instance\n{: .note.text-center}\n\nWe use this IP address to create DNS A records to map the DNS names of three (minio, registry, and gitlab) of the GitLab instance subsystems to it. Here is a snapshot for the gitlab one (you need to do the same for the minio and registry subsystems):\n\n![creating dns record](https://about.gitlab.com/images/blogimages/gko-on-ocp/11-creating-dns-record.png){: .shadow.medium.center.wrap-text}\nCreating DNS A record for the gitlab subsystem\n{: .note.text-center}\n\n**NOTE:** I owned the domain ocpgitlab.com. You would use a domain that you own.\n{: .alert .alert-info}\n\n## Logging in to the newly created instance running on the OpenShift Container Platform cluster\n\nBefore logging in to our newly created GitLab instance running on OpenShift Container Platform, we need to obtain the initial root password, which is a secret stored under the gitlab-system namespace. You obtain the initial root password for the newly created GitLab instance by entering the following command:\n\n> kubectl -n gitlab-system get secret gitlab-gitlab-initial-root-password -ojsonpath='{.data.password}' \\| base64 --decode ; echo\n\nAt this moment, we can point our browser to our newly created GitLab instance on OpenShift and login as root:\n\n![logging in to GitLab](https://about.gitlab.com/images/blogimages/gko-on-ocp/13-log-in-to-gitlab.png){: .shadow.medium.center.wrap-text}\nLogging in to the newly created GitLab instance running on the OpenShift Container Platform cluster\n{: .note.text-center}\n\nThat’s it!\n\n## Conclusion\n\nWe have shown you how to install and run the GitLab Operator to create a GitLab instance on an OpenShift Container Platform cluster. View [this demo](https://youtu.be/sEBnuhzYD2I) to see how this feature works.\n\n## Read more on Kubernetes\n\n- [Threat modeling the Kubernetes Agent: from MVC to continuous improvement](/blog/threat-modeling-kubernetes-agent/)\n\n- [How to deploy the GitLab Agent for Kubernetes with limited permissions](/blog/setting-up-the-k-agent/)\n\n- [A new era of Kubernetes integrations on GitLab.com](/blog/gitlab-kubernetes-agent-on-gitlab-com/)\n\n- [Understand Kubernetes terminology from namespaces to pods](/blog/kubernetes-terminology/)\n\n- [What we learned after a year of GitLab.com on Kubernetes](/blog/year-of-kubernetes/)\n\n",[1936,9,230],{"slug":3394,"featured":6,"template":683},"gko-on-ocp","content:en-us:blog:gko-on-ocp.yml","Gko On Ocp","en-us/blog/gko-on-ocp.yml","en-us/blog/gko-on-ocp",{"_path":3400,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3401,"content":3407,"config":3412,"_id":3414,"_type":13,"title":3415,"_source":15,"_file":3416,"_stem":3417,"_extension":18},"/en-us/blog/going-remote-education-virtual-learning-tips",{"title":3402,"description":3403,"ogTitle":3402,"ogDescription":3403,"noIndex":6,"ogImage":3404,"ogUrl":3405,"ogSiteName":670,"ogType":671,"canonicalUrls":3405,"schema":3406},"Going remote in education? Don't panic.","If you're an educator moving online, we have some tips for virtual learning success.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681183/Blog/Hero%20Images/work_remote_coffee_green.jpg","https://about.gitlab.com/blog/going-remote-education-virtual-learning-tips","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Going remote in education? Don't panic.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":3402,"description":3403,"authors":3408,"heroImage":3404,"date":3409,"body":3410,"category":996,"tags":3411},[1203],"2020-03-27","\n\nCampuses around the world in both K-12 and higher education are moving to virtual models of instruction and operation to help reduce the spread of COVID-19. As a result, many faculty, students, staff and leadership are now in the position of navigating how to work, teach, and learn remotely with little to no preparation time and even fewer resources.\n\nJumping into virtual education – voluntarily or otherwise – is not easy. Properly developing an online curriculum takes months and months of work, a coordinated tech stack, and a well-defined communication plan. Intentionally, online courses have IT staff to assist in the process of converting classes and generally only convert one at a time.\n\nAre you an educator facing a suddenly digital classroom? Are you worried about answering endless emails from panicked students? Dreading spending hours upon hours recording lectures? Wondering how you will be able to effectively communicate with all your students?\n\nAs the world’s largest all-remote company with 1,200+ employees in 65 countries, GitLab has a wealth of resources to help navigate this challenge! The GitLab [remote work emergency plan]( /company/culture/all-remote/remote-work-emergency-plan/) can be adapted to help both students and educators get up and running quickly and function effectively in this new reality.\n\nWe're excited to share a few immediately actionable tips for faculty, staff, and students who’ve been suddenly thrust out of the classroom and into a virtual education model.\n\n\n\n## Tip 1: Adopt a single source of truth\n\nWhile this term is pretty self-explanatory, it can’t be emphasized enough. When an entire company of people have to be on the same page, it is essential that everyone knows exactly what needs to happen, how it happens, and when it should happen. This same concept applies directly to an online class.\n\nImagine you need to make a change in your class agenda for a project due tomorrow – where does that update need to appear? A syllabus schedule, due dates on folders, due dates on assignments, class calendars, and of course via email, etc. Chances are, you’ll miss making the update in one of those locations. Confusion and lots of emails with questions will ensue! (see [Tip 2](#tip-2-leverage-a-transparent-communication-tool)).\n\nThe concept of a [single source of truth](https://handbook.gitlab.com/handbook/values/#single-source-of-truth) (SSoT) that serves as a living record has many benefits in a classroom setting. Students need a SSoT in order to build trust, confidence, and be successful in a course, especially when they are used to the reassurance of seeing teachers several times a week. A SSoT also minimizes the number of questions about logistics and allows you to spend more time discussing the content itself.\n\n### How to adopt a single source of truth\n\n* Identify a tool (see [Tip 2](#tip-2-leverage-a-transparent-communication-tool)) that serves as the SSoT and document all relevant information such as due dates, schedules, directions, policies, etc. in this single location.\n* Avoid the temptation to list dates and policies on multiple documents such as calendars and assignments.\n* Update the SSoT as needed. As students ask questions, add the answers to the SSoT. This approach will save you time in answering questions down the road.\n* You will need to adjust as the cadence of the course develops, especially if this is your first time teaching it online.\n* Make sure students know that they will only need to look in this one location for any changes.\n\n## Tip 2: Leverage a [transparent communication tool](/company/culture/all-remote/remote-work-emergency-plan/#establish-a-handbook)\n\nIf you are put in the situation of having to migrate to remote quickly, you probably don’t have much time to invest in a complicated setup.  Don’t worry, you can implement this tip by starting simple.\n\nFirst things first, the tool should not be email. Email is one of the most inefficient methods of communication for remote work. You and your students are better served when information is shared out in a way that everyone has the same knowledge. Reducing email’s allure will save you and your students time and energy.\n\n### [What do we recommend instead?](/company/culture/all-remote/remote-work-emergency-plan/#establish-a-handbook)\n\n* A cloud-based word processor, such as Google Docs, is a great tool to get started with an SSoT. Ensure that you can easily update the document without downloading, uploading, and changing formats..\n* We recommend using a tool that allows for live editing, so making changes is very simple and easy.\n* Adding timestamps to track updates can also be helpful so students know they are looking at the most recent information.\n\n### What other tools do I need?\n\nBe sure to keep the [tech stack simple](/company/culture/all-remote/remote-work-emergency-plan/#minimize-your-tool-stack) and make sure everyone knows when to use which tool for each kind of communication.\n* For live meetings, we use [Zoom](https://zoom.us/) but whatever video conferencing tool your institution has will work.\n* For informal communication we use Slack, but there are other tools available such as Microsoft Teams.\n* If you need a more visual collaboration tool, consider using a tool such as [Mural](https://mural.co/).\n\nLet’s consider an example of how, when taken together, this approach can improve the experience for everyone in a remote environment whether teaching or learning.\n\n* A student asks a good question on the informal chat tool. You update the SSoT and direct the student to the answer there. Now students who may have the same question can see the response and know where to find the answer.\n* A student asks a question that is already in the SSoT. You direct the student to the correct link, thus minimizing the time it takes to answer the question.\n* A student asks a question that has been asked multiple times before. Private message the student, provide the SSoT link and suggest that he looks at the thread for answers in the future so he/she doesn’t need to wait for individualized responses.\n\n## Tip 3: Establish a [communication plan](/company/culture/all-remote/remote-work-emergency-plan/#establish-a-communications-plan)\n\nFor the first time in years, there’s no school bell ringing hourly or class schedule to keep everything on track! We recommend that you start by thinking about – and enjoying – **[asynchronous communication](/company/culture/all-remote/asynchronous/)** and then identify the [tool(s)](/company/culture/all-remote/remote-work-emergency-plan/#minimize-your-tool-stack) that you will use.\n\nFirst, let’s explore **asynchronous communication**. Working asynchronously removes the temptation to find a time that works for everyone and ensures that people who can’t make it to a specific event aren’t left out of the loop.\n\nIt is possible to strike a balance between providing key information in a self-service model while at the same time allowing for teams to ask questions and have discussions. Adopting a self-service model means that all content and relevant information is provided in a manner that students can easily find, read, and digest on their own ahead of time. With this approach, students can decide how much time to spend digging into the content according to their own needs and schedules.\n\nRecording a set of lectures ahead for an entire class, yet alone several classes' worth, is very daunting. Approaching lectures with an asynchronous communication style can help ease the burden on educators and at the same time provide effective mechanisms for discussion.\n\n### How can lectures be asynchronous?\n\n* [Have an editable agenda](/company/culture/all-remote/meetings/#have-an-agenda)  for the actual lecture discussion where students can post their name and a question in a numbered list.\n* Host a live video discussion where students voice their question(s) in the order on the agenda. If they aren’t present, read the question for them.\n* Answer the questions in the meeting and make sure someone is taking great notes. [Document everything](/company/culture/all-remote/meetings/#document-everything-live-yes-everything).  Try the [‘everyone is a moderator’](/handbook/communication/#everyone-is-a-moderator) concept to help run these meetings effectively.\n* Consider live-streaming the video directly to YouTube. This saves time and does not require you to download the recording, process it, and then upload back to your learning management system. The videos will be available on YouTube afterwards as well.\n* For more information, check out GitLab’s guide on [how to run remote meetings right](/company/culture/all-remote/meetings/#how-do-you-do-all-remote-meetings-right). You can also check a [recent example of a meeting livestream](https://www.youtube.com/watch?v=KMvrb0M3fFA) and an agenda to match (see below).\n\n![Agenda screenshot](https://about.gitlab.com/images/blogimages/group-convo-agenda.jpg){: .shadow.medium.center}\nA GitLab editable agenda after a meeting\n{: .note.text-center}\n\n## Tip 4: [Devote time to fostering relationships](/company/culture/all-remote/informal-communication/#devote-time-to-fostering-relationships)\n\nIn all-remote environments, there should be a greater emphasis placed on carving out time to get to know one another as humans. To connect and bond as empathetic beings with interests, emotions, fears, and hopes – people, not just colleagues or classmates. This tip is especially useful when transitioning from an in-person to an online setting. Your students are probably already a bit stressed, overwhelmed, and missing in-person, in-classroom connections.\n\n### How can you foster a sense of community with your online class?\n\n#### Try creating some fun channels in your online chat tool\n\nGitLab has channels that are all business as well as a set of channels for fun topics such as cooking, fitness, and dogs. People who have similar interests will connect and share experiences, photos, recipes etc. Students who connect over their puppies or a great recipe are more likely to help eachother out with questions or study together.\n\n#### Consider starting your video conference five minutes early with a conversational slide as a starter\n\nStudents arriving early can chit-chat just as they may have done in person. It might take a few meetings and some encouragement to get the ball rolling, but they’ll soon look forward to this opportunity to connect with classmates.\n\n![GitLab marketing team Show & Tell social call](https://about.gitlab.com/images/all-remote/marketing-social-call-show-and-tell.jpg){: .shadow.medium.center}\nA GitLab marketing team Show & Tell social call\n{: .note.text-center}\n\n#### Hold your office hours over a video conference\n\nStudents will be able to ask questions and have discussions, allowing them to build on the relationship with you and others they started in the in-person classroom.\n\n#### Try breakout groups\n\nThese are a great way to give students who may be less likely to speak up in a large group a chance to connect in a smaller setting.\n\n#### Consider hosting an **“Ask Me Anything”** meeting\n\nThese meetings are open times when students can ask a variety of questions. The questions could be anything from career advice, to sharing thoughts on research projects, course advising etc. It doesn’t have to be all business either.\n\n#### Encourage group conversation rather than 1:1 wherever possible\n\nThis helps to foster relations. We have some [guidelines that encourage collaboration through group communication](/handbook/communication/#avoid-direct-messages).\n\n#### There are some cases where you may need to discuss something 1:1 with a student\n\nWe recommend clearly outlining when to use group and private conversations in your SSoT.\n\nAdopting some of these strategies for remote teaching and learning is fairly easy. In our experience at GitLab, we find that team members enjoy and respect the independence this way of working affords them.  Students want to be engaged, and encouraging them to contribute by asking questions and taking collective notes themselves will allow them to contribute directly. Start small and go from there.\n\nWe hope this information helps make the transition a little bit easier and challenges some conventions in the long term! To learn more about the GitLab Education Program read our blog post [How to bring GitLab to a classroom near you](/blog/bring-gitlab-to-classroom-nearyou/).\n\nCover image by [Djurdjica Boskovic](https://unsplash.com/@escape_from_reality) on [Unsplash](https://unsplash.com/photos/G8_A4ZWxE3E)\n{: .note}\n",[9,680,998],{"slug":3413,"featured":6,"template":683},"going-remote-education-virtual-learning-tips","content:en-us:blog:going-remote-education-virtual-learning-tips.yml","Going Remote Education Virtual Learning Tips","en-us/blog/going-remote-education-virtual-learning-tips.yml","en-us/blog/going-remote-education-virtual-learning-tips",{"_path":3419,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3420,"content":3426,"config":3431,"_id":3433,"_type":13,"title":3434,"_source":15,"_file":3435,"_stem":3436,"_extension":18},"/en-us/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"title":3421,"description":3422,"ogTitle":3421,"ogDescription":3422,"noIndex":6,"ogImage":3423,"ogUrl":3424,"ogSiteName":670,"ogType":671,"canonicalUrls":3424,"schema":3425},"Guide to fulfilling SOC 2 security requirements with GitLab","Understand the application security features in the GitLab DevSecOps platform that map to System and Organization Controls 2 requirements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Guide to fulfilling SOC 2 security requirements with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":3421,"description":3422,"authors":3427,"heroImage":3423,"date":3428,"body":3429,"category":704,"tags":3430},[2234],"2025-01-22","For businesses that handle sensitive customer information, achieving SOC 2 (System and Organization Controls 2) compliance is not just a good practice — it's often a necessity. SOC 2 is a rigorous auditing standard developed by the American Institute of Certified Public Accountants that assesses a service organization's controls related to security, availability, processing integrity, confidentiality, and privacy.\n\nWhile SOC 2 is not legally mandated, it has become increasingly important, in part due to breaches consistently seen in news headlines. Obtaining SOC 2 compliance allows customers to build trust with service organizations because they know their data is being properly stored and security controls have been assessed by a third party.\n\nIn this guide, we'll review the requirements for obtaining SOC 2 compliance and how GitLab can help your organization meet the highest standards for application security.\n\n## What requirements are set by SOC 2\n\nThe compliance process involves an audit by an independent auditor who evaluates the design and operating effectiveness of an organization's controls. This process can be very costly, and many organizations are not sufficiently prepared before an audit. With the SOC 2 audit process typically taking close to a year, it is important to establish an efficient pre-audit process.\n\nTo obtain SOC 2 compliance, an organization must meet requirements based on the Trust Services Criteria:\n\n| Criteria | Requirements |\n| :---- | :---- |\n| Security | - Implement controls to protect against unauthorized access \u003Cbr> - Establish procedures for identifying and mitigating risks\u003Cbr> - Set up systems for detecting and addressing security incidents |\n| Availability | - Ensure systems are accessible for operation as agreed\u003Cbr> - Monitor current usage and capacity \u003Cbr> - Identify and address environmental threats that could affect system availability |\n| Process integrity | - Maintain accurate records of system inputs and outputs \u003Cbr> - Implement procedures to quickly identify and correct system errors \u003Cbr> - Define processing activities to ensure products and services meet specifications |\n| Confidentiality | - Identify and protect confidential information \u003Cbr> - Establish policies for data retention periods \u003Cbr> - Implement secure methods for destroying confidential data after retention periods expire |\n| Privacy | - Obtain consent before collecting sensitive personal information \u003Cbr> - Communicate privacy policies clearly and in plain language \u003Cbr> - Collect data only through legal means and from reliable sources |\n\u003Cbr>\n\nNote that these requirements are not one-time achievements, but rather a continuous process. Auditors will require control effectiveness over time.\n\n## How to achieve and maintain the security requirements\n\nGitLab provides several features off the board to get you started with assuring SOC 2 security needs are met:\n\n| Security Requirement | Addressing Feature |\n| :---- | :---- |\n| Implement controls to protect against unauthorized access | - Confidential Issues and Merge Requests \u003Cbr> - Custom Roles and Granular Permissions \u003Cbr> - Security Policies \u003Cbr> - Verified Commit \u003Cbr> - Signed Container Images \u003Cbr> - CodeOwners \u003Cbr> - Protected Branches |\n| Set up systems for detecting and addressing security incidents | - Vulnerability Scanning \u003Cbr> - Merge Request Security Widget \u003Cbr> - Vulnerability Insights Compliance Center \u003Cbr> - Audit Events \u003Cbr> - Vulnerability Report Dependency List \u003Cbr> - AI: Vulnerability Explanation \u003Cbr> - AI: Vulnerability Resolution |\n| Establish procedures for identifying and mitigating risks | All the above tools can be used by a security team to establish a procedure around what to do when security vulnerabilities are identified and how they are mitigated. |\n\u003Cbr>\nLet’s go through each section and highlight the security features that address these requirements. Note that a [GitLab Ultimate subscription](https://about.gitlab.com/free-trial/) and the correct Role and Permissions are required to access many of the features listed. Be sure to check out the appropriate documentation for more information.\n\n## Implement controls to protect against unauthorized access\n\nImplementing robust access controls is essential for protecting an organization's assets, ensuring regulatory compliance, maintaining operational continuity, and fostering trust. GitLab allows you to implement controls to follow the [principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/), securing against unauthorized access. I will briefly cover:\n\n* [Security policies](#security-policies)  \n* [Custom roles and granular permissions](#custom-roles-and-granular-permissions)  \n* [Branch protections and CodeOwners](#branch-protections-and-codeowners)  \n* [Verified commits](#verified-commits)\n\n### Security policies\n\nGitLab's security policies, known as guardrails, enable security and compliance teams to implement consistent controls across their organization, helping prevent security incidents, maintain compliance standards, and reduce risk by automatically enforcing security best practices at scale.\n\n![Merge request approval policy in action](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\u003Ccenter>\u003Ci>Merge request approval policy in action\u003C/i>\u003C/center>\u003Cbr>\n\nThe following policy types are available:\n\n* Scan execution policy: Enforce security scans, either as part of the pipeline or on a specified schedule  \n* Merge request approval policy: Enforce project-level settings and approval rules based on scan results  \n* Pipeline execution policy: Enforce CI/CD jobs as part of project pipelines  \n* Vulnerability management policy: Automate vulnerability management workflows\n\nHere is an example of ensuring compliance with the pipeline execution policy:\n\n1. Create a project that houses multiple compliance jobs. An example of a job can be to check permissions of files that are deployed. These jobs should be generic enough that they can be applied to multiple applications.\n2. Limit the project's permissions to only security/compliance officers; don’t allow developers to remove jobs. This allows for separation of duties.\n3. Inject the compliance jobs in batch to the projects where they are required. Force them to run no matter what, but allow approval from team lead to not block development. This will ensure compliance jobs are always run and cannot be removed by developers, and that your environment remains compliant.\n\n> ##### Learn how to create security policies with our [security policy documentation](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n### Custom roles and granular permissions\n\nCustom permissions in GitLab allow organizations to create fine-grained access controls beyond the standard role-based permissions, providing benefits such as:\n\n* more precise access control  \n* better security compliance  \n* reduced risk of accidental access  \n* streamlined user management  \n* support for complex organizational structures\n\n![GitLab custom roles](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\u003Ccenter>\u003Ci>Roles and permissions settings, including custom roles\u003C/i>\u003C/center>\n\n> ##### Learn how to create custom roles with granular permissions using our [custom role documentation](https://docs.gitlab.com/ee/user/custom_roles.html).\n\n### Branch protections and CodeOwners\n\nGitLab helps you further control who can change your code using two key features:\n* Branch Protection, which lets you set rules about who can update specific branches – like requiring approval before merging changes.\n* Code Ownership, which automatically finds the right people to review code changes by matching files to their designated owners.\n\nTogether, these features help keep your code secure and high-quality by making sure the right people review and approve changes.\n\n![Protected branches](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\u003Ccenter>\u003Ci>Protected branch settings\u003C/i>\u003C/center>\n\n> ##### Learn how to create protected branches along with CodeOwners using [protected branch](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) and [codeowner](https://docs.gitlab.com/ee/user/project/codeowners/) documentation.\n\n### Verified commits\n\nWhen you sign your commits digitally, you prove they really came from you, not someone pretending to be you. Think of a digital signature like a unique stamp that only you can create. When you upload your public GPG key to GitLab, it can check this stamp. If the stamp matches, GitLab marks your commit as `Verified`. You can then set up rules to reject commits that aren't signed, or block all commits from users who haven't verified their identity.\n\n![Commit signed with verified signature](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\u003Ccenter>\u003Ci>Commit signed with verified signature\u003C/i>\u003C/center>\u003Cbr>\n\nCommits can be signed with:\n\n* SSH key  \n* GPG key  \n* Personal x.509 certificate\n\n> ##### Learn more about verified commits with our [signed commits documentation](https://docs.gitlab.com/ee/user/project/repository/signed_commits/).\n\n## Set up systems for detecting and addressing security incidents\n\nSetting up systems for detecting and addressing security incidents is vital for maintaining a robust security posture, ensuring regulatory compliance, minimizing potential damages, and enabling organizations to respond effectively to the ever-evolving threat landscape.\n\nGitLab provides security scanning and vulnerability management for the complete application lifecycle. I will briefly cover:\n\n* [Security scanning and vulnerability management](#security-scanning-and-vulnerability-management)  \n* [Software bill of materials](#software-bill-of-materials)  \n* [System auditing and security posture review](#system-auditing-and-security-posture-review)\n* [Compliance and security posture oversight](#compliance-and-security-posture-oversight)\n\n### Security scanning and vulnerability management\n\nGitLab provides a variety of different security scanners that cover the complete lifecycle of your application:\n\n* Static Application Security Testing (SAST)  \n* Dynamic Application Security Testing (DAST)\n* Container Scanning  \n* Dependency Scanning  \n* Infrastructure as Code (IaC) Scanning  \n* Coverage-guided Fuzzing\n* Web API Fuzzing\n\nThese scanners can be added to your pipeline via the use of templates. For example, to run SAST and dependency scanning jobs in the test stage, simply add the following to your .gitlab-ci.yml:\n\n```yaml  \nstages:  \n   - test\n\ninclude:  \n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  \n  - template: Jobs/SAST.gitlab-ci.yml  \n``` \n\nThese jobs are fully configurable via environment variables and using GitLab job syntax. Once a pipeline kicks off, the security scanners run and detect vulnerabilities in the diff between the current branch and the target branch. The vulnerability can be seen in a merge request (MR), providing detailed oversight before the code is merged to the target branch. The MR will provide the following information on a vulnerability:\n\n* description  \n* status  \n* severity  \n* evidence  \n* identifiers  \n* URL (if applicable)  \n* request/response (if applicable)  \n* reproduction assets (if applicable)  \n* training (if applicable)  \n* code flow (if using advanced SAST)\n\n![MR view of introduced vulnerability](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\u003Ccenter>\u003Ci>MR view of introduced vulnerability\u003C/i>\u003C/center>\u003Cbr>\n\nDevelopers can use this data to remediate vulnerabilities without slowing down security team workflows. Developers can dismiss a vulnerability with reasoning, speeding up the review process, or they can create a confidential issue to track the vulnerability.\n\nIf the code in an MR is merged to the default (usually production-level) branch, then the vulnerability report is populated with the security scanner results. These results can be used by security teams to manage and triage the vulnerabilities found in production.\n\n![Vulnerability report with Batch Status setting](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\u003Ccenter>\u003Ci>Vulnerability report with Batch Status setting\u003C/i>\u003C/center>\u003Cbr>\n\nWhen clicking on a vulnerability description within the vulnerability report, you are provided with the vulnerability page, which contains the same vulnerability data as the MR, allowing for a single source of truth when assessing impact and performing remediation. From the vulnerability page, [GitLab Duo](https://about.gitlab.com/gitlab-duo/) AI features can be used to explain the vulnerability and also create an MR to remediate, speeding up resolution time.\n\n> ##### Learn more about the security scanners included with GitLab and how to manage vulnerabilities in our [application security documentation](https://docs.gitlab.com/ee/user/application_security/).\n\n### Software bill of materials\n\nGitLab can create a detailed list of everything your software uses – kind of like an ingredients list for your code. This list, called a software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)), shows you all the external code your project depends on, including the parts you directly use and their own dependencies. For each item, you can see which version you're using, what license it has, and whether it has any known security problems. This helps you keep track of what's in your software and spot potential risks.\n\n![Group-level dependency list (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\u003Ccenter>\u003Ci>Group-level dependency list (SBOM)\u003C/i>\u003C/center>\n\n> ##### Learn how to access and use the dependency list with our [dependency list documentation](https://docs.gitlab.com/ee/user/application_security/dependency_list/).\n\n### System auditing and security posture review\n\nGitLab keeps track of everything that happens in your system such as who made changes, what they changed, and when they did it. Think of it like a security camera for your code. This record helps you:\n\n* spot any suspicious activity  \n* show regulators you're following the rules  \n* figure out what happened if something goes wrong  \n* see how people are using GitLab\n\nAll of this information is stored in one place, making it easy to review and investigate when needed. For example, you can use audit events to track:\n\n* who changed the permission level of a particular user for a GitLab project, and when  \n* who added a new user or removed a user, and when\n\n![Project-level audit events](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\u003Ccenter>\u003Ci>Project-level audit events\u003C/i>\u003C/center>\n\n> ##### Learn more about audit events, see the [audit events documentation](https://docs.gitlab.com/ee/user/compliance/audit_events.html).\n\n## Compliance and security posture oversight\n\nGitLab's Security Dashboard works like a control room that shows you all your security risks in one place. Instead of checking different security tools separately, you can see all their findings together on one screen. This makes it easy to spot and fix security problems across all your projects.\n\n![Group-level Security Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\u003Ccenter>\u003Ci>Group-level security dashboard\u003C/i>\u003C/center>\n\n> ##### Learn more about security dashboards with our [security dashboard documentation](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n\n## Establish procedures for identifying and mitigating risks\n\nVulnerabilities go through a specific lifecycle. For example, a part of the procedure can be to require approval for any vulnerable code to be merged to protected branches using security policies. Then the procedure can state that vulnerable code detected in production must be prioritized, assessed, remediated, and then validated: \n\n* The criteria for prioritization can be by the severity of the vulnerability provided by GitLab scanners.  \n* The assessment can be done using exploitation details provided by the AI: Vulnerability Explanation.  \n* Once the vulnerability is remediated, then it can be validated using built-in GitLab regression tests and scanners.\n\nWhile every organization's needs are different, leveraging GitLab as a platform, risks can be quickly identified and addressed with reduced risk when compared to using a sprawl of disparate tools.\n\n### Best practices for SOC 2 compliance\n\n* Establish a strong security culture: Foster a culture of security awareness and accountability throughout your organization.  \n* Document everything: Maintain thorough documentation of policies, procedures, and controls.  \n* Automate where possible: Use automation tools to streamline compliance processes and reduce errors.  \n* Communicate effectively: Keep stakeholders informed about your compliance efforts.  \n* Seek expert guidance: Consider partnering with a qualified consultant to assist with your SOC 2 journey.\n\nAchieving SOC 2 compliance is a significant undertaking, but the benefits are undeniable. By demonstrating your commitment to application security and operational excellence, you can build trust with customers, enhance your reputation, and gain a competitive edge in the marketplace.\n\n## Read more\n\nTo learn more about GitLab and how we can help achieve SOCv2 compliance while enhancing your security posture, check out the following resources:\n\n* [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)  \n* [GitLab DevSecOps Tutorial Project](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n",[746,704,478,9,701],{"slug":3432,"featured":90,"template":683},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab","content:en-us:blog:guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab","en-us/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","en-us/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"_path":3438,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3439,"content":3445,"config":3450,"_id":3452,"_type":13,"title":3453,"_source":15,"_file":3454,"_stem":3455,"_extension":18},"/en-us/blog/hosted-runners-for-gitlab-dedicated-available-in-beta",{"title":3440,"description":3441,"ogTitle":3440,"ogDescription":3441,"noIndex":6,"ogImage":3442,"ogUrl":3443,"ogSiteName":670,"ogType":671,"canonicalUrls":3443,"schema":3444},"Hosted Runners for GitLab Dedicated available in Beta","GitLab Dedicated customers can now scale their CI/CD workloads with no maintenance overhead.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663948/Blog/Hero%20Images/dedicatedcoverimage.png","https://about.gitlab.com/blog/hosted-runners-for-gitlab-dedicated-available-in-beta","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Hosted Runners for GitLab Dedicated available in Beta\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"}],\n        \"datePublished\": \"2024-01-31\",\n      }",{"title":3440,"description":3441,"authors":3446,"heroImage":3442,"date":3447,"body":3448,"category":678,"tags":3449},[2470],"2024-01-31","Managing fleets of runners can be complex and requires significant experience to ensure all CI/CD jobs can scale to meet the demands of developers. Hosted Runners for GitLab Dedicated, now available in Beta, allows customers to use runners that are fully managed by GitLab for CI/CD jobs running on GitLab Dedicated.\n\nHosted Runners for GitLab Dedicated brings the same flexibility, efficiency, and control of GitLab Dedicated to runners. The Beta release includes the following features:\n- Linux-based runners at the instance level\n- Complete isolation from other tenants, following the same principles as GitLab Dedicated\n- Auto-scaling\n- Fully managed by GitLab\n\nAdditional features will be included based on customer demand leading up to limited and general availability.\n\nAs we develop this new feature, we are making Hosted Runners for GitLab Dedicated available upon invitation for existing GitLab Dedicated customers. Please reach out to your Customer Success Manager or [contact sales](https://about.gitlab.com/sales/). You can learn more about Gitlab Dedicated [on our website](https://about.gitlab.com/dedicated/).",[9,701,108],{"slug":3451,"featured":6,"template":683},"hosted-runners-for-gitlab-dedicated-available-in-beta","content:en-us:blog:hosted-runners-for-gitlab-dedicated-available-in-beta.yml","Hosted Runners For Gitlab Dedicated Available In Beta","en-us/blog/hosted-runners-for-gitlab-dedicated-available-in-beta.yml","en-us/blog/hosted-runners-for-gitlab-dedicated-available-in-beta",{"_path":3457,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3458,"content":3464,"config":3469,"_id":3471,"_type":13,"title":3472,"_source":15,"_file":3473,"_stem":3474,"_extension":18},"/en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability",{"title":3459,"description":3460,"ogTitle":3459,"ogDescription":3460,"noIndex":6,"ogImage":3461,"ogUrl":3462,"ogSiteName":670,"ogType":671,"canonicalUrls":3462,"schema":3463},"Hosted runners for GitLab Dedicated: Now in limited availability"," Simplify CI/CD infrastructure management with hosted runners for GitLab Dedicated, a fully managed solution that handles all aspects of runner infrastructure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664751/Blog/Hero%20Images/AdobeStock_640077932.jpg","https://about.gitlab.com/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Hosted runners for GitLab Dedicated: Now in limited availability\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gabriel Engel\"}],\n        \"datePublished\": \"2025-01-23\",\n      }",{"title":3459,"description":3460,"authors":3465,"heroImage":3461,"date":3466,"body":3467,"category":701,"tags":3468},[2193],"2025-01-23","We are excited to announce that hosted runners for [GitLab Dedicated](https://about.gitlab.com/dedicated/), our single-tenant SaaS solution, have transitioned from [beta](https://about.gitlab.com/blog/hosted-runners-for-gitlab-dedicated-available-in-beta/) to limited availability, marking a significant milestone in our commitment to simplifying CI/CD infrastructure management for our customers.\n\n## Streamlined CI/CD infrastructure management\n\nManaging runner infrastructure has traditionally been a complex undertaking, requiring dedicated resources and expertise to maintain optimal performance. Hosted runners for GitLab Dedicated eliminates these challenges by providing a fully managed solution that handles all aspects of runner infrastructure. This allows your teams to focus on what matters most – building and deploying great software.\n\n## Key benefits\n\n### Reduced operational overhead\n\nBy choosing hosted runners, you can eliminate the complexity of provisioning, maintaining, and securing your runner infrastructure. Our fully managed service handles all aspects of runner operations, from deployment to updates and security patches.\n\n### Automatic scaling\n\nHosted runners automatically scale to match your CI/CD demands, ensuring consistent performance during high-traffic periods and for large-scale projects. This dynamic scaling capability means you'll always have runners available to pick up your CI/CD jobs and ensure optimal efficiency of your development teams.\n\n### Cost optimization\n\nWith hosted runners, you only pay for the resources you actually use. This consumption-based model eliminates the need to maintain excess capacity for peak loads, potentially reducing your infrastructure costs while ensuring resources are available when needed.\n\n### Enterprise-grade security\n\nFollowing the same security principles as GitLab Dedicated, hosted runners provide complete isolation from other tenants and are secure by default. Jobs are executed in fully-isolated VMs with no inbound traffic allowed. This means you can maintain the highest security standards without the complexity of implementing and maintaining security measures yourself.\n\n## Introducing native Arm64 support\n\nOur hosted runners now include native Arm64 support in addition to our existing x86-64 runners, offering significant advantages for modern development workflows.\n\n### Enhanced performance for Arm-based development\n\nNative Arm64 runners enable you to build, test, and deploy Arm-based applications in their native environment, ensuring optimal performance and compatibility. Teams developing Docker images or services targeting Arm-based cloud platforms can see build times cut significantly, accelerating their development cycles and deployments.\n\n### Cost-efficient computing\n\nArm-based runners can significantly reduce your computing costs, due to their efficient processing architecture and lower cost per minute. For compatible jobs, this means more affordable pipeline execution.\n\n### Native building capabilities\n\nWith support for both x86-64 and Arm64 architectures, you can:\n- build and test applications natively on either architecture\n- create multi-architecture container images efficiently\n- validate cross-platform compatibility in your CI/CD pipeline\n- optimize your delivery pipeline for specific target platforms\n- eliminate the performance overhead of emulation when building for Arm targets\n\nThis dual-architecture support ensures you have the flexibility to choose the right environment for each specific workload while maintaining a consistent and efficient CI/CD experience across all your projects.\n\n## Available runner sizes\n\nWe're expanding our runner offerings to include both x86-64 and Arm64 architectures with a range of configurations. The following sizes are available:\n\n| Size | vCPUs | Memory | Storage |\n|------|--------|---------|----------|\n| Small    | 2      | 8 GB    | 30 GB    |\n| Medium    | 4      | 16 GB   | 50 GB    |\n| Large    | 8      | 32 GB   | 100 GB   |\n| X-Large   | 16     | 64 GB   | 200 GB   |\n| 2X-Large  | 32     | 128 GB  | 200 GB   |\n\nThis expanded size support allows you to optimize your CI/CD pipeline performance based on your application's specific requirements.\n\n## What's next for hosted runners\n\nWe plan to release hosted runners in general availability in May 2025. The release includes compute minute visualization to help you better understand and control your CI/CD usage across your organization.\n\nWe'll be expanding our hosted runners offering with several new features coming later this year:\n- Network controls for enhanced security and compliance\n- MacOS runners to support application development for the Apple ecosystem\n- Windows runners for .NET and Windows-specific workloads\n\nThese additions will provide even more flexibility and coverage for your CI/CD needs, allowing you to consolidate all your build and test workflows on GitLab Dedicated hosted runners.\n\nReady to simplify your CI/CD infrastructure? Contact your GitLab representative or [reach out to our sales team](https://about.gitlab.com/dedicated/) to learn more about hosted runners for GitLab Dedicated.\n",[703,478,9,678,108,183],{"slug":3470,"featured":6,"template":683},"hosted-runners-for-gitlab-dedicated-now-in-limited-availability","content:en-us:blog:hosted-runners-for-gitlab-dedicated-now-in-limited-availability.yml","Hosted Runners For Gitlab Dedicated Now In Limited Availability","en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability.yml","en-us/blog/hosted-runners-for-gitlab-dedicated-now-in-limited-availability",{"_path":3476,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3477,"content":3483,"config":3488,"_id":3490,"_type":13,"title":3491,"_source":15,"_file":3492,"_stem":3493,"_extension":18},"/en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities",{"title":3478,"description":3479,"ogTitle":3478,"ogDescription":3479,"noIndex":6,"ogImage":3480,"ogUrl":3481,"ogSiteName":670,"ogType":671,"canonicalUrls":3481,"schema":3482},"How all-remote supports inclusion and bolsters communities","When your hiring pipeline is more inclusive, your team becomes more inclusive.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679679/Blog/Hero%20Images/kuala-lumpur-dm.jpg","https://about.gitlab.com/blog/how-all-remote-supports-inclusion-and-bolsters-communities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How all-remote supports inclusion and bolsters communities\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Murph\"}],\n        \"datePublished\": \"2019-12-06\",\n      }",{"title":3478,"description":3479,"authors":3484,"heroImage":3480,"date":3485,"body":3486,"category":996,"tags":3487},[993],"2019-12-06","\n\nA diverse and [inclusive](/company/culture/inclusion/#fully-distributed-and-completely-connected) team is a stronger, [smarter](https://hbr.org/2016/11/why-diverse-teams-are-smarter), and more empathetic team. As industries grapple with mechanisms to encourage and facilitate inclusivity, all-remote teams — where [100% of team members](/company/culture/all-remote/stages/) are empowered to work from anywhere — are more inclusive by default.\n\n## All-remote exudes inclusiveness\n\n![GitLab colleagues gathered in London](https://about.gitlab.com/images/blogimages/gitlab-commit-london-2019-colleagues.jpg){: .shadow.medium.center}\nGitLab colleagues gathered in London.\n{: .note.text-center}\n\nResearch from [Deloitte](https://www2.deloitte.com/us/en/insights/deloitte-review/issue-22/diversity-and-inclusion-at-work-eight-powerful-truths.html) shows that \"teams with inclusive leaders are 17% more likely to report that they are high performing, 20% more likely to say they make high-quality decisions, and 29% more likely to report behaving collaboratively.\"\n\nGitLab recognizes that one [advantage](/company/culture/all-remote/benefits/) to being an all-remote company is that we can [hire talent from a global pool](/handbook/hiring/). We are not restricted to the usual job centers, which gives us access to a tremendous amount of talent that many other companies will not consider for employment. It may take more effort to find talent in more diverse places, but that is an effort we are willing to make.\n\nCurrently, GitLab employs over [1,000 team members across more than 60 countries](/company/team/). This level of richness in cultural and geographic diversity is enabled by all-remote, and naturally shields against biases that form when entire teams live, work, and interact in the same region of the world.\n\nWe're surrounded by a tapestry of unique cultures, celebrations, and traditions. Not only does this give us a broader view of the world internally, it enables us to be more empathetic to the broader open-source community.\n\n## Sourcing talent from around the globe\n\n![All-remote allows people to thrive wherever they call home. Image by [Darren Murph](https://twitter.com/darrenmurph)](https://about.gitlab.com/images/blogimages/night-train-city-sweden.jpg){: .shadow.medium.center}\nAll-remote allows people to thrive wherever they call home. Image by [Darren Murph](https://twitter.com/darrenmurph)\n{: .note.text-center}\n\nGitLab's six [values](https://handbook.gitlab.com/handbook/values/) are Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging , Iteration, and Transparency, and together they spell CREDIT.\n\nTrue to those values, GitLab strives to hire team members who are passionate, empathetic, kind, tenacious, and ambitious, *regardless* of their location. By opening the recruiting funnel to as [broad a swath of the world as we can](/handbook/people-group/employment-solutions/#country-hiring-guidelines), we create a more inclusive hiring environment, lean on tight collaboration to drive progress [across time zones](/company/culture/all-remote/management/#asynchronous), and focus our hiring decisions on results rather than location.\n\nHiring an all-remote team from across the globe allows GitLab to [pay local rates](/blog/why-we-pay-local-rates/). By hiring brilliant minds in locations with lower costs of living, GitLab is able to save money to hire even more people as we [scale our business](/company/culture/all-remote/scaling/).\n\n- All-remote means that you [will not sacrifice career advancement](/handbook/people-group/learning-and-development/) by working outside of the office, as even GitLab executives are fully remote.\n- All-remote creates a workplace where caregivers, individuals with physical disabilities, etc., are not disadvantaged by being unable to regularly commute into an office.\n- GitLab's approach to [spending company money](/handbook/spending-company-money/) enables all team members to create a work environment uniquely tailored for them.\n- All-remote enables those who must relocate frequently for family and personal reasons to take their career with them.\n- All-remote allows movement and relocation to physical settings that contribute to an individual's health (e.g., moving to a location with an improved air quality index).\n\n## Bolstering communities\n\n![When people aren't forced to relocate for work, their communities benefit. Image by [Darren Murph](https://twitter.com/darrenmurph)](https://about.gitlab.com/images/blogimages/community-outdoors-eu.jpg){: .shadow.medium.center}\nWhen people aren't forced to relocate for work, their communities benefit. Image by [Darren Murph](https://twitter.com/darrenmurph)\n{: .note.text-center}\n\nAll-remote encourages team members to work and live in a place where they are most fulfilled. This enables our team to reside in regions or communities that provides far more than shelter, but enriches their life experience by enabling long-lasting relationships with people who shape and support them.\n\nBy not forcing people to relocate for work, companies which embrace all-remote are benefitting local comunities in a significant way. Rural communities receive [outsized economic benefit](https://www.lajuntatribunedemocrat.com/news/20190808/state-remote-work-program-could-help-rural-communities), while major metropolitan areas experience less strain on infrastructure.\n\nStay-at-home [parents](/company/culture/all-remote/people/#parents) who wish to further their career, [caregivers](/company/culture/all-remote/people/#caretakers), [military spouses](/company/culture/all-remote/people/#military-spouses-and-families), and those who struggle with mobility can all contribute meaningfully when a company removes the location requirement from the job description.\n\nAll-remote opens the hiring door to places far beyond the usual job centers of the world. Candidates are not limited by geography and [we champion this approach](/blog/all-remote-is-for-everyone/) – to the extent that it’s possible – for all companies.\n\n{: .note}\n\n",[9,680,998],{"slug":3489,"featured":6,"template":683},"how-all-remote-supports-inclusion-and-bolsters-communities","content:en-us:blog:how-all-remote-supports-inclusion-and-bolsters-communities.yml","How All Remote Supports Inclusion And Bolsters Communities","en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities.yml","en-us/blog/how-all-remote-supports-inclusion-and-bolsters-communities",{"_path":3495,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3496,"content":3502,"config":3508,"_id":3510,"_type":13,"title":3511,"_source":15,"_file":3512,"_stem":3513,"_extension":18},"/en-us/blog/how-eclipse-foundation-champions-open-source-with-gitlab",{"title":3497,"description":3498,"ogTitle":3497,"ogDescription":3498,"noIndex":6,"ogImage":3499,"ogUrl":3500,"ogSiteName":670,"ogType":671,"canonicalUrls":3500,"schema":3501},"How the Eclipse Foundation champions open source with GitLab","In this interview, learn how adopting GitLab helps the Eclipse Foundation be a more effective champion for open source.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679184/Blog/Hero%20Images/eclipsefoundationcover.png","https://about.gitlab.com/blog/how-eclipse-foundation-champions-open-source-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the Eclipse Foundation champions open source with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-10-19\",\n      }",{"title":3497,"description":3498,"authors":3503,"heroImage":3499,"date":3505,"body":3506,"category":827,"tags":3507},[3504],"Bryan Behrenshausen","2023-10-19","\nThe Eclipse Foundation is a pillar of the open source ecosystem. Home to more than 415 open source projects, the not-for-profit organization has been championing open source collaboration and innovation for more than two decades.\n\nGitLab plays a significant role in the Eclipse Foundation's operations, and the organization recently joined the GitLab [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) community. To mark the occasion, I caught up with Denis Roy, IT director at the Eclipse Foundation, to chat about the organization's history, vision, and passion for open source development.\n\n**We're so excited to welcome the Eclipse Foundation to the GitLab Open Source Partners community. You've been champions of open source for quite some time. Tell us about your history and the mission that guides you today.**\n\nThe Eclipse Foundation was born in 2004, as a not-for-profit, [open source](https://go.gitlab.com/spHNym) software foundation with the goal of driving the evolution of the Eclipse Platform and its ecosystem of tools, plugins, and addons in a vendor-neutral, open, and transparent community. Since then, the Eclipse Foundation has become one of the world's largest open source software foundations. The foundation offers a mature, scalable, and business-friendly environment for open source software collaboration and innovation, hosting more than 415 open source projects, including runtimes, tools, and frameworks for a wide range of technology domains such as the Internet of Things, automotive, geospatial, systems engineering, and many others.\n\n> Connect with the GitLab Open Source Partners on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n\n**How does the Eclipse Foundation use GitLab? What has using GitLab helped you accomplish?**\n\nGitLab has allowed us to modernize our development platform, because it offers an integrated, cohesive environment to help maximize developer productivity while reducing the administrative overhead related to managing such a complex set of tools. With a single package to upgrade and maintain, and tight integration between code repositories, issue trackers, wikis, code review, and CI tools, it's easier for the Eclipse Foundation's IT team to stay up to date. This has allowed us to reduce our reliance on customized, in-house code.\n\nWhen we began our work in 2004, open source code hosting options were rudimentary and limited. At the time, we created our own forge by using a handful of tools that were not designed with interoperability in mind, including [CVS](https://www.nongnu.org/cvs/), [Bugzilla](https://www.bugzilla.org/), and [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki). When it came time to refresh our offering, it was an easy decision to replace our home-grown forge with GitLab, since GitLab offers a seamless integration of all these developer tools, and many more, within a single, easy-to-use package. This creates a very useful environment for our developers and allows the project teams to be productive while offering a familiar interface for interacting and building their user communities.\n\nAt this time, [the Eclipse Foundation's GitLab instance](https://gitlab.eclipse.org) hosts more than 70 [open source software projects](https://gitlab.eclipse.org/eclipse) and dozens of other projects that [help us manage and support our community](https://gitlab.eclipse.org/eclipsefdn).\n\n**How big is the Eclipse Foundation's IT team? What have you seen the team achieve after the migration to GitLab?**\n\nThe Foundation's IT team consists of a dozen people, split almost evenly between infrastructure, release engineering, security, and web development. Our migration to GitLab is still a work in progress, but it's allowing the Eclipse Foundation IT team to consolidate our code repositories, issues, and documentation onto a single platform with a modern and friendly UI. The same is also true for the Eclipse OSS projects that have, or are currently migrating from, \"pure Git\" to GitLab.\n\nWith GitLab, the team is seeing a notable decrease in both administrative overhead and user support, as using, managing, and maintaining GitLab on premise is straightforward and very robust. We're able to stay up-to-date with new GitLab releases easily, which scores extra points with our security team. We're able to use that freed time towards activities that benefit our community and provide extra value.\n\n**What's on the horizon for the Eclipse Foundation? What are your most important initiatives right now?**\n\nOne of the big initiatives we’re working on right now is improving the security of our open source projects. We’ve made a significant investment in security over the past year, including auditing some of our top projects for security concerns and we are looking to establish a [working group](https://www.eclipse.org/org/workinggroups/eclipse-cyber-risk-concept.php) to help us gain the resources we need to enhance our security processes across all of our operations.\n\nWe're also focused on growing the [Eclipse Software Defined Vehicle](https://sdv.eclipse.org/) community, which continues to gain momentum with new members like General Motors, Qualcomm, and Microsoft. The automotive industry is becoming increasingly willing to collaborate on open source software, and experience the technological and business benefits of doing so.  \n\n**How can GitLab community members get more involved in the Eclipse Foundation's work?**\n\nIt's easy! Browse the list of [Eclipse Projects](https://projects.eclipse.org/) and discover the Developer Resources section. Or browse the list of projects on Eclipse's [GitLab instance](https://gitlab.eclipse.org/eclipse) and send in those those merge requests!\n\n## Learn more\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n",[1187,266,9],{"slug":3509,"featured":6,"template":683},"how-eclipse-foundation-champions-open-source-with-gitlab","content:en-us:blog:how-eclipse-foundation-champions-open-source-with-gitlab.yml","How Eclipse Foundation Champions Open Source With Gitlab","en-us/blog/how-eclipse-foundation-champions-open-source-with-gitlab.yml","en-us/blog/how-eclipse-foundation-champions-open-source-with-gitlab",{"_path":3515,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3516,"content":3522,"config":3528,"_id":3530,"_type":13,"title":3531,"_source":15,"_file":3532,"_stem":3533,"_extension":18},"/en-us/blog/how-gitlab-can-support-your-iso-compliance-journey",{"title":3517,"description":3518,"ogTitle":3517,"ogDescription":3518,"noIndex":6,"ogImage":3519,"ogUrl":3520,"ogSiteName":670,"ogType":671,"canonicalUrls":3520,"schema":3521},"How GitLab can support your ISO 27001 compliance journey","As a strategic partner, GitLab's software security features can help support your ISO 27001 compliance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab can support your ISO 27001 compliance journey\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-06\",\n      }",{"title":3517,"description":3518,"authors":3523,"heroImage":3519,"date":3525,"body":3526,"category":704,"tags":3527},[3524],"Joseph Longo","2023-09-06","\nAs a single, all-inclusive platform, managing your DevSecOps lifecycle with GitLab is easy. GitLab’s platform enables developers to build better software faster. But the effectiveness of GitLab extends beyond DevSecOps.\n\nIn October of 2022, the International Organization for Standardization released the latest edition of the ISO 27001 standard. ISO/IEC 27001:2022 includes several changes from its previous edition, including the addition of Annex A controls focused on secure coding and configuration management.\n\nAt GitLab, we leverage our platform to support many aspects of our security compliance program, a concept we internally call [dogfooding](https://about.gitlab.com/direction/dogfooding/). An overview of the compliance and assurance credentials that we maintain can be found on our [Trust Center](https://about.gitlab.com/security/) page.\n\nLet’s review the primary functions you can leverage to support your ISO 27001 compliance journey.\n\n## Organizational controls\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 5.3 Segregation of duties | Conflicting duties and conflicting areas of responsibility shall be segregated. |\n| 5.15 Access control | Rules to control physical and logical access to information and other associated assets shall be established and implemented based on business and information security requirements. |\n| 5.16 Identity management | The full lifecycle of identities shall be managed. |\n| 8.2 Privileged access rights | The allocation and use of privileged access rights shall be restricted and managed.|\n| 8.4 Access to source code | Read and write access to source code, development tools, and software libraries shall be appropriately managed. |\n\nWith GitLab, you can [assign users a role](https://docs.gitlab.com/ee/user/permissions.html) when you add them to a project or group. A user’s role determines the actions they can take within your GitLab instance. The following roles are available for assignment:\n* Guest (private and internal projects only)\n* Reporter\n* Developer\n* Maintainer\n* Owner\n* Minimal access (available for the top-level group only)\n\nGitLab’s roles enable you to limit a user’s permissions in accordance with the [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege) and your business and information security requirements.\n\nGitLab enables you to centralize authentication and authorization responsibilities for your GitLab instance through [SAML SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) integrations. GitLab integrates with a wide range of identity providers to support our customers’ diverse tech stacks. GitLab also supports the System for Cross-Domain Identity Management ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Through GitLab’s SSO and SCIM integrations, you can automate the lifecycle of your user identities in a secure and efficient manner.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) and [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) are also available for GitLab self-managed customers.\n\n**Note:** Annex A Technological controls 8.2 and 8.4 were included in the chart above due to their close relationship with Organizational controls 5.3, 5.15, and 5.16. The same GitLab features can be applied to support these control requirements.\n{: .note}\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 5.8 Information security in project management | Information security shall be integrated into project management. |\n\nWith GitLab, you can use our [planning tools](https://about.gitlab.com/features/?stage=plan) to support your project management efforts and ensure information security is being appropriately considered through all phases of a project’s lifecycle.\n\n- GitLab’s [team planning](https://about.gitlab.com/features/?stage=plan#team_planning) features enable users to organize, plan, align, and track project work from idea to production.\n\n- [Epics](https://docs.gitlab.com/ee/user/group/epics/), [issues](https://docs.gitlab.com/ee/user/project/issues/), and [tasks](https://docs.gitlab.com/ee/user/tasks.html) can be used to collaborate on ideas, solve problems, and plan work with your information security team. [Description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) and [checklists](https://docs.gitlab.com/ee/user/markdown.html#task-lists) enable users to apply a consistent description and workflow to issues or [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). These templates support a consistent approach to integrating information security into your project management lifecycle. \n\n- [Labels](https://docs.gitlab.com/ee/user/project/labels.html) allow users to organize issues as they see fit. To support information security, labels may be used to identify the risk level associated with a project, identify the stage a project is in, or identify the information security team that is responsible for a set of work. [Scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) can be used to add further logic to workflows by preventing certain labels from being used together. At GitLab, we leverage [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to identify work assigned to different teams, the project stage the work resides in, and the product or feature set associated with the work.\n\n![Scoped Labels](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nScoped Labels\n{: .note.text-center}\n\n- [Group](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) and [project](https://about.gitlab.com/stages-devops-lifecycle/issueboard/) issue boards can be used to further organize your work and provide a central, aggregated view of all work associated with a group or project.\n\n## Technological controls\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.8 Management of technical vulnerabilities | Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken. |\n| 8.9 Configuration management | Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored, and reviewed. |\n| 8.25 Secure development lifecycle | Rules for the secure development of software and systems shall be established and applied. |\n| 8.26 Application security requirements | Information security requirements shall be identified, specified, and approved when developing or acquiring applications. |\n| 8.27 Secure system architecture and engineering principles | Principles for engineering secure systems shall be established, documented, maintained, and applied to any information system development activities |\n\nWith GitLab, you can store your hardware and software configurations, maintain version control, update your configurations via [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html), and leverage GitLab’s [CI/CD pipelines](https://docs.gitlab.com/ee/ci/pipelines/) to push those configurations to your applications and infrastructure. GitLab enables organizations to implement [GitOps](https://about.gitlab.com/topics/gitops/) through a single platform.\n\nGitLab’s [infrastructure-as-code scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) functionality enables you to scan your IaC configuration files for known vulnerabilities. GitLab’s IaC scanning supports a variety of IaC configuration files and languages making it adaptable to different tech stacks.\n\nFor compliance professionals, GitLab enables you to implement automation through [compliance frameworks](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) and [compliance pipelines](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines). These features enable users to identify critical projects that have certain compliance requirements and push configurations to those projects via pipelines. They enable consistent enforcement of controls, thereby supporting your security posture and facilitating adherence to your organization’s internal and external compliance requirements.\n\nFor [Ultimate](https://about.gitlab.com/pricing/ultimate/) customers, GitLab’s [Compliance Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) provides a centralized view of a group’s compliance posture, such as the different compliance frameworks being applied to the projects in the group. You can even see how well you comply with the [GitLab Standard](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html#gitlab-standard).\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.15 Logging | Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected, and analyzed. | \n| 8.16 Monitoring activities Control | Networks, systems, and applications shall be monitored for anomalous behavior and appropriate actions taken to evaluate potential information security incidents. |\n\nWith GitLab, you can use [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) to track important events, including who performed the related action and when. Audit events cover a broad range of categories, including:\n* Group management\n* Authentication and authorization\n* User management\n* Compliance and security\n* CI/CD\n* GitLab Runners\n\n![Audit events](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nExample of an audit event\n{: .note.text-center}\n\nFor [Ultimate](https://about.gitlab.com/pricing/ultimate/) customers, [audit event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) can be enabled. Audit event streaming enables users to set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and projects, as structured JSON.\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.28 Secure coding | Secure coding principles shall be applied to software development. |\n| 8.29 Security testing in development and acceptance | Security testing processes shall be defined and implemented in the development lifecycle. | \n\nYou can use the features in GitLab’s [Secure](https://about.gitlab.com/features/?stage=secure) stage to enhance your software development lifecycle and improve the security of your products. GitLab’s Secure stage features include:\n* [Static application security testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [Code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n* [Container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [Dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nAnd much more!\n\n![Code quality findings](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nCode quality findings\n{: .note.text-center}\n\nLeaked secrets is one of the leading catalysts of security breaches. GitLab’s [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) scans your repository to help prevent your secrets from being exposed.\n\nGitLab’s [Policies](https://docs.gitlab.com/ee/user/application_security/policies/) feature enables users to implement [scan execution](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) and [scan result](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) policies based on configured logic. These policies combine the scanning capabilities in the [Secure](https://about.gitlab.com/features/?stage=secure) stage with [merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) to further enforce compliance requirements.\n\nTogether, GitLab’s Secure features create a foundation for a secure software development lifecycle program and enable you to implement secure coding principles in accordance with your organization’s requirements.\n\n\u003Cbr>\n\n| Control ID | Control Description |\n| ---- | ---- |\n| 8.32 Change management | Changes to information processing facilities and information systems shall be subject to change management procedures. |\n\nGitLab offers many features to support a comprehensive change management program.\n\nGitLab’s source code management features enable users to implement [protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html). Protected branches allow GitLab users to impose restrictions on certain branches that are considered critical to their operations. A protected branch controls:\n* which users can merge into the branch\n* which users can push to the branch\n* if users can force push to the branch\n* if changes to files listed in the CODEOWNERS file can be pushed directly to the branch\n* which users can unprotect the branch\n\nThe [default branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) in a repository is automatically designated as a protected branch.\n\n![Protected branches](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nProtected branches settings within GitLab\n{: .note.text-center}\n\nMerge requests (MR) are a core component of the software development lifecycle. GitLab users can configure their MRs so that they must be approved before they can be merged. MR approvals allow users to set the minimum number of required approvals before work can merge into a project. Some examples of rules you can create include:\n* Users with specific permissions can always approve work.\n* [Code owners](https://docs.gitlab.com/ee/user/project/codeowners/index.html) can approve work for files they own.\n* Users with specific permissions can approve work, [even if they don’t have merge rights](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) to the repository.\n* Users with specific permissions can be allowed or denied the ability to [override approval rules on a specific merge request](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nAs previously mentioned, [issues](https://docs.gitlab.com/ee/user/project/issues/) and [tasks](https://docs.gitlab.com/ee/user/tasks.html) can be used to document and collaborate on change requests. [Description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) enable users to apply a consistent description to issues or [MRs](https://docs.gitlab.com/ee/user/project/merge_requests/index.html). These templates support a consistent approach to requesting changes in a manner that best fits your organization.\n\n## Learn more\nAs a comprehensive DevSecOps platform, GitLab supports a broad range of requirements. ISO added additional controls around secure coding and configuration management in the 2022 edition of the ISO standard. This demonstrates that certifying bodies have an increased focus on software security as a whole. As a strategic partner, GitLab can help support your ISO 27001 compliance journey and help you develop better software faster.\n\nTo learn more about these features, see our library of [tutorials](https://docs.gitlab.com/ee/tutorials/).",[704,9,1208],{"slug":3529,"featured":6,"template":683},"how-gitlab-can-support-your-iso-compliance-journey","content:en-us:blog:how-gitlab-can-support-your-iso-compliance-journey.yml","How Gitlab Can Support Your Iso Compliance Journey","en-us/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","en-us/blog/how-gitlab-can-support-your-iso-compliance-journey",{"_path":3535,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3536,"content":3542,"config":3546,"_id":3548,"_type":13,"title":3549,"_source":15,"_file":3550,"_stem":3551,"_extension":18},"/en-us/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance",{"title":3537,"description":3538,"ogTitle":3537,"ogDescription":3538,"noIndex":6,"ogImage":3539,"ogUrl":3540,"ogSiteName":670,"ogType":671,"canonicalUrls":3540,"schema":3541},"How GitLab supports NSA and CISA CI/CD security guidance","GitLab can support your alignment with NSA and CISA CI/CD recommendations and best practices for cloud-based DevSecOps environments.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683032/Blog/Hero%20Images/vaultimage.png","https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How GitLab supports NSA and CISA CI/CD security guidance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-19\",\n      }",{"title":3537,"description":3538,"authors":3543,"heroImage":3539,"date":1850,"body":3544,"category":704,"tags":3545},[3524],"\nIn June, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) [issued a joint cybersecurity information sheet (CSI)](https://media.defense.gov/2023/Jun/28/2003249466/-1/-1/0/CSI_DEFENDING_CI_CD_ENVIRONMENTS.PDF) providing recommendations and best practices for cloud-based DevSecOps environments. Specifically, the CSI focuses on security hardening best practices for continuous integration/continuous delivery (CI/CD) cloud deployments.\n\nLet's take a look at the relevant threats, recommended countermeasures, and how the [GitLab DevSecOps Platform](https://about.gitlab.com/platform/) can support the implementation and enforcement of the countermeasures to help secure your CI/CD environment.\n\n## CI/CD environments are under threat\nOver the past few years, the software supply chain, and specifically CI/CD environments, have become a persistent and valuable target for malicious actors. Theft of proprietary code and data, injection of malicious links and redirects, and denial-of-service attacks are a few examples of why CI/CD environments have been such lucrative targets for threat actors.\n\nThe CSI outlines examples of common risks in CI/CD pipelines. These risks include:\n* insecure first-party code\n* insecure third-party code\n* poisoned pipeline execution\n* insufficient pipeline access controls\n* insecure system configuration\n* usage of insecure third-party services\n* exposure of secrets\n\nAdditional context can be found in the CSI and in [OWASP's top 10 CI/CD security risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/).\n\nNote: The CSI contains helpful information on potential threat scenarios and illustrations to help visualize different attack vectors.\n\n## Hardening recommendations for CI/CD environment\nAs a single, all-inclusive DevSecOps platform, GitLab's features support the implementation of the recommended mitigations from the NSA and CISA.\n\n### Authentication and access mitigation\nHere are the features that align with authentication and access mitigation.\n\n#### Use NSA-recommended cryptography\n_\"NSA and CISA recommend the implementation and configuration of strong cryptographic algorithms when configuring cloud applications and services.\"_\n\nGitLab's [GitLab.com](https://about.gitlab.com/solutions/) and [GitLab Dedicated](https://about.gitlab.com/dedicated/) SaaS solutions implement TLS 1.2+ for encrypting data in transit and AES-256-bit encryption for data at rest. You can learn more about our approach to cryptography in our [Cryptography Standard](https://about.gitlab.com/handbook/security/cryptographic-standard.html).\n\n#### Minimize the use of long-term credentials\n_\"Use strong credentials that are resistant to stealing, phishing, guessing, and replaying wherever and whenever possible.\"_\n\nTo support the use of strong credentials, GitLab enables you to centralize authentication and authorization responsibilities for your GitLab instance through [SAML SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) integrations. GitLab integrates with a wide range of identity providers to support our customers’ diverse tech stacks. GitLab also supports the System for Cross-Domain Identity Management ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Through GitLab’s SSO and SCIM integrations, you can automate the lifecycle of your user identities in a secure and efficient manner.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) and [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) are also available for GitLab self-managed customers.\n\nGitLab supports [two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html). Customers can enable one or both of the following second factors of authentication:\n\n* time-based one-time passwords ([TOTP](https://datatracker.ietf.org/doc/html/rfc6238))\n* WebAuthn devices\n\n> Check out our [Ultimate guide to enabling SAML and SSO on GitLab.com](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/) for more information.\n\n#### Add signature to CI/CD configuration and verify it\n_\"NSA and CISA recommend implementing secure code signing to establish digital trust\nwithin the CI/CD pipeline.\"_\n\nGitLab enables its customers to [sign commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/) using:\n* an [SSH key](https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html)\n* a [GPG key](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)\n* a [personal x.509 certificate](https://docs.gitlab.com/ee/user/project/repository/signed_commits/x509.html)\n\nGitLab's [push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) feature can also be used to reject individual commits if they are not signed with GPG, or you can choose to reject all commits from unverified users.\n\n![Signed commits](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/signed-commits.png)\n\nSigned commits verified and unverified badges\n{: .note.text-center}\n\n#### Utilize two-person rules (2PR) for all code updates\n_\"No single developer should be able to check in code without another developer\nreviewing and approving the changes.\"_\n\nGitLab enables users to configure their [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) (MRs) so that they must be approved before they can be merged. MR approvals allow users to set the minimum number of required approvals before work can merge into a project. Some examples of rules you can create include:\n* Users with specific permissions can always approve work.\n* [Code owners](https://docs.gitlab.com/ee/user/project/codeowners/index.html) can approve work for files they own.\n* Users with specific permissions can approve work, [even if they don’t have merge rights](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) to the repository.\n* Users with specific permissions can be allowed or denied the ability to [override approval rules on a specific MR](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nGitLab's MR approval [rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) and [settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html) can be configured and adapted to meet your organization's requirements and align with your risk tolerance.\n\n![MR approval settings](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/mr-approval-settings.png)\n\nExample of MR approval requirements\n{: .note.text-center}\n\n#### Implement least-privilege policies for CI/CD access\n_\"The CI/CD pipeline should not be accessible by everyone in the organization.\" \n\"Mitigate password risks by implementing multi-factor authentication (MFA).\"_\n\nGitLab enables you to [assign users a role](https://docs.gitlab.com/ee/user/permissions.html) when you add them to a project or group. A user’s role determines the actions they can take within your GitLab instance. The following roles are available for assignment:\n* Guest (private and internal projects only)\n* Reporter\n* Developer\n* Maintainer\n* Owner\n* Minimal access (available for the top-level group only)\n\nGitLab's role-based access control (RBAC) model enables you to limit a user’s permissions in accordance with the [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege) and your business and information security requirements.\n\nAs mentioned [above](#minimize-the-use-of-long-term-credentials), GitLab supports two-factor authentication and can integrate with several SSO providers to support your tech stack and help you centralize authentication and authorization responsibilities.\n\n#### Secure user accounts\n_\"Regularly audit administrative user accounts and configure access controls under the\nprinciples of least privilege and separation of duties. Audit logs to ensure new accounts\nare legitimate.\"_\n\nAs mentioned in the [previous section](#implement-least-privilege-policies-for-cicd-access), GitLab enables you to assign roles and associated permissions to your users in a way that aligns with your business and information security requirements. GitLab's authorization feature enables you to support the principle of least privilege and the concept of separation of duties.\n\nKeep reading to understand how GitLab supports the NSA and CISA's audit log guidance.\n\n#### Secure secrets\n_\"Secure handling of secrets, tokens, and other credentials is crucial in a CI/CD pipeline.\"_\n\nGitLab's [secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) enables users to scan their repositories for exposed secrets and take action based on the scan results.\n\nWith secret detection, users can see scan results in multiple places such as GitLab's [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/index.html) and [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), and users can configure [automatic responses to leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html).\n\n### Development process mitigations\nHere are features that support development process mitigations.\n\n#### Integrate security scanning as part of the CI/CD pipeline\n_\"Include security scanning early in the CI/CD process.\"_\n\nThe CSI recommends the implementation of the following tools:\n* static application security testing (SAST)\n* registry scanning\n* dynamic analysis security testing\n\nGitLab supports these recommendations through its [SAST](https://docs.gitlab.com/ee/user/application_security/sast/), [dynamic application security testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/), [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/), and [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) features. GitLab also offers additional scanning features such as [code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) and [dynamic API security testing (DAST API)](https://docs.gitlab.com/ee/user/application_security/dast_api/).\n\nTogether, these [Secure stage](https://about.gitlab.com/features/?stage=secure) features provide comprehensive coverage to help you write secure code faster.\n\n#### Restrict untrusted libraries and tools\n_\"Only use software, tools, libraries, and artifacts from secure and trusted sources.\"_\n\nIn addition to [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), GitLab's [license compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html) feature enables organizations to incorporate trusted dependencies into their codebase that meet their unique business and security requirements.\n\nWith license compliance, you can check that your dependencies' licenses are compatible with your business and security requirements, and you can approve or deny dependencies based on configured license approval policies.\n\nNote: License compliance is only available for GitLab Ultimate users.\n\n#### Analyze committed code\n_\"Securing the CI/CD pipeline involves analyzing the code that is being committed, which can be achieved manually or by using automated tools.\"_\n\nAs an all-inclusive DevSecOps platform, GitLab supports a seamless and comprehensive approach to reviewing code changes.\n\nWith the scanning features mentioned [above](#integrate-security-scanning-as-part-of-the-cicd-pipeline), you can enable automated code reviews to help identify vulnerabilities, logic flaws, and policy violations.\n\nGitLab's [MR review](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/) feature streamlines the manual code review process. [Suggested Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers) makes it easy to identify users who are authorized to review and merge your changes.\n\n![Suggested Reviewers](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/suggested-reviewers.png){: .shadow.small.center}\n\nSuggested Reviewers\n{: .note.text-center}\n\nMR approval [rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) and [settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html) help ensure your code review requirements are enforced in a programmatic way.\n\n#### Remove any temporary resources\n_\"A CI/CD pipeline may also create temporary resources, such as virtual machines or Kubernetes clusters, to run tests. While test environments are usually always live, these temporary resources are meant to be created for a single test purpose and must be destroyed after the pipeline run.\"_\n\nWithin GitLab, a temporary runner VM hosts and runs each CI job. GitLab automatically issues a command to remove the temporary runner VM immediately after the CI job completes. Additional details on this process can be found in our documentation for [Security for SaaS runners](https://docs.gitlab.com/ee/ci/runners/#security-for-saas-runners).\n\n#### Keep audit logs\n_\"An audit log should provide clear information on who committed, reviewed, and deployed what, when, and where.\"_\n\nAs outlined in this [blog post](https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/), GitLab enables you to use [audit events](https://docs.gitlab.com/ee/administration/audit_events.html) to track important events, including who performed the related action and when. Audit events cover a broad range of categories, including:\n* group management\n* authentication and authorization\n* user management\n* compliance and security\n* CI/CD\n* GitLab Runners\n\n![Audit events](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nExample of an audit event\n{: .note.text-center}\n\nFor [Ultimate](https://about.gitlab.com/pricing/ultimate/) customers, [audit event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) can be enabled. Audit event streaming enables users to set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and projects, as structured JSON.\n\n#### Implement an SBOM and SCA \n_\"A software bill of materials (SBOM) and software composition analysis (SCA) can play a useful role in the software development lifecycle (SDLC) and in DevSecOps by helping to track all third-party and open source components in the codebase.\"_\n\nGitLab's [dependency list](https://docs.gitlab.com/ee/user/application_security/dependency_list/) feature enables you to review your project or group’s dependencies, including their known vulnerabilities. \n\nCombining GitLab's dependency list feature with its [SCA](#restrict-untrusted-libraries-and-tools) suite of features supports a comprehensive strategy for identifying and remediating vulnerabilities and risks within your supply chain.\n\n![Dependency List](https://about.gitlab.com/images/blogimages/2023-09-07-how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/dependency-list.png)\n\nExample of dependency list results\n{: .note.text-center}\n\nNote: Dependency list is only available for GitLab Ultimate users.\n\n#### Plan, build, and test for resiliency\n_\"Build the pipeline for high availability, and test for disaster recovery periodically.\"_\n\nAs a SaaS provider, GitLab prioritizes your resiliency and efficiency needs. We maintain robust [business continuity](https://about.gitlab.com/handbook/business-technology/gitlab-business-continuity-plan/) and [disaster recovery](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/disaster-recovery/index.md) strategies to support the availability of the GitLab platform, and we provide helpful strategies for GitLab users to maintain [pipeline efficiency](https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html).\n\nIf you'd like to learn more about what we're doing to maintain the security, confidentiality, and availability of the GitLab platform, please request our [Customer Assurance Package](https://about.gitlab.com/security/cap/).\n\n## Learn more\nAs a comprehensive DevSecOps platform, GitLab supports a broad range of requirements and recommendations. CI/CD environments have become lucrative targets for malicious actors, and the CSI provides excellent guidance for protecting such a critical component of an organization's assets. As a strategic partner, GitLab supports your efforts to safeguard your CI/CD environment and enables you to develop secure software faster. \n\nTo learn more about these features, have a look at our library of [tutorials](https://docs.gitlab.com/ee/tutorials/).\n",[704,9,1208,108],{"slug":3547,"featured":6,"template":683},"how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance","content:en-us:blog:how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance.yml","How Gitlab Supports The Nsa And Cisa Cicd Security Guidance","en-us/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance.yml","en-us/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance",{"_path":3553,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3554,"content":3559,"config":3566,"_id":3568,"_type":13,"title":3569,"_source":15,"_file":3570,"_stem":3571,"_extension":18},"/en-us/blog/how-remote-work-at-gitlab-enables-location-independence",{"title":3555,"description":3556,"ogTitle":3555,"ogDescription":3556,"noIndex":6,"ogImage":1825,"ogUrl":3557,"ogSiteName":670,"ogType":671,"canonicalUrls":3557,"schema":3558},"How I work from anywhere (with good internet)","Sarah Daily, digital marketing programs manager and remote work advocate, shares how all-remote work at GitLab has enabled her life on the road.","https://about.gitlab.com/blog/how-remote-work-at-gitlab-enables-location-independence","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How I work from anywhere (with good internet)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Daily\"},{\"@type\":\"Person\",\"name\":\"Betsy Church\"}],\n        \"datePublished\": \"2019-06-25\",\n      }",{"title":3555,"description":3556,"authors":3560,"heroImage":1825,"date":3563,"body":3564,"category":996,"tags":3565},[3561,3562],"Sarah Daily","Betsy Church","2019-06-25","\n\nWe're committed to [all-remote](/company/culture/all-remote/) work at GitLab – our whole work\nphilosophy is designed around it. So we're always happy to share when one of our team members\nis taking full advantage of the flexibility that remote work affords. We chatted with [Sarah Daily](/company/team/#sdaily) about\nher life on the road:\n\n### What’s your role at GitLab, and why did you want to join the team?\n\nI’m a [digital marketing programs manager](https://handbook.gitlab.com/job-families/marketing/online-growth-manager/index.html) focusing on conversion rate optimization and analysis for our email programs and website. Previously, I was a digital marketing manager for a non-profit organization in the education industry.\n\nI'm a remote work advocate and knew about some of the companies that are 100% remote (GitLab being prominent among them).\n\nThough I had a remote job at the time I applied to GitLab, I knew eventually my passion for technology and software development would lead me elsewhere. I decided to seek GitLab directly to see if they had any open positions in their marketing department. As fate would have it, they did, so I applied immediately.\n\nThe more I learned about the company and culture, the more I fell in love. GitLab is a model for how companies should implement remote work. The culture and values are so deeply integrated in how everyone works and behaves. Everything we do and how we work is centered around being a global workforce and allows us to move at the speed of innovation.\n\n### Tell us about your traveling home office and when you started life as a digital nomad.\n\nThree years ago, my partner and I were living in an 800-square-foot apartment with daily commute jobs. We no longer wanted to live where we were, but we didn’t want to choose a random place to move to without knowing whether we were actually going to like it there.\n\nWe needed to be able to visit family and friends with little hassle, and if we lived over a 1,000 miles away then that was going to be a considerable effort and cost. Before we could make any decisions, I needed the ability to work remotely and I ended up finding a remote job with a non-profit organization that had a hybrid remote work model.\n\nOne night, my partner came home from work and made the suggestion to live in an RV. It would be cheaper to live, we could travel and live anywhere we wanted* for as long as we wanted, and we would be able to visit family and friends, all while living in the comfort of our own home.\n\n![Sarah's truck and trailer](https://about.gitlab.com/images/blogimages/sdaily-truck-and-trailer.jpg){: .shadow.medium.center}\nSarah's truck and trailer\n{: .note.text-center}\n\nAfter researching blogs, Facebook groups, and other websites, we realized not only was it actually possible, but that thousands of other people, couples, and families were doing this and had been doing it for years.\n\nBut before we could start the process, we had to downsize a lot.\n\nWe sold a car, all our furniture, and gave the rest away to Goodwill or family and friends. In March 2016, we moved the rest of our belongings into a less than 200-square-foot space and hit the road. We’ve been all over the west coast of the US and Canada.\n\nOur rig is a 40-foot travel trailer that we haul with our truck. After living and traveling in it for three years, it actually has more space than we need.\n\nMore than anything, we love the freedom of being able to pick up and leave for a new location, all while being in our home. We’ll likely continue to do this for the foreseeable future.\n\n*Criteria: Has to have good internet and an airport nearby.\n{: .note}\n\n### How has working for GitLab enabled you to chase your passion for travel?\n\nThough we’ve been full-time traveling for over three years, GitLab makes this even easier because of the focus on asynchronous work. While some companies allow their employees to work remotely, it isn’t always flexible.\n\nAt my previous job, I was expected to work at least partially in a specific time zone. This is because there was a central HQ and only some employees worked remotely full time. This created a separation and isolation for remote employees. It made us feel like we weren’t always involved in meetings and conversations that happened at HQ.\n\nWith the asynchronous model, I don't have to worry about when I'm working because all my colleagues live in different time zones. This gives me the freedom to design my day around my peak productive hours and also have time to take care of general life stuff (appointments, house chores, etc.)\n\n![Sarah fishing in Grand Teton National Park, Wyoming](https://about.gitlab.com/images/blogimages/sarah-fishing-grand-teton-national-park-wy.jpg){: .shadow.medium.center}\nSarah fishing in Grand Teton National Park, Wyoming\n{: .note.text-center}\n\n### What makes GitLab unique?\n\nIt is so refreshing to work at GitLab. The culture really enables you to be the best version of yourself both as an employee and a human being outside of work. Everyone here fully embraces our ideals and values and it makes contributing a pleasure.\n\n>Everything we do and how we work is centered around being a global workforce and allows us to move at the speed of innovation\n\nYou really feel like you make a difference each day, [no matter how small or boring](https://handbook.gitlab.com/handbook/values/#boring-solutions).\n\nBut I think the biggest difference between GitLab and other companies I’ve worked for is the [transparency](https://handbook.gitlab.com/handbook/values/#transparency). By being transparent with our employees, customers, and community, we enable everyone to fall in love with the product and vision, and contribute to making it better every day.\n\nIt truly becomes a shared goal and I think that’s something that is missing from most company cultures. If you cannot enable everyone to have a say through transparency, you bottleneck the entire company for everyone.\n\n\n\nLearn more about [all-remote](/company/culture/all-remote/) work and [how it works at GitLab](/company/culture/all-remote/tips/#how-it-works-at-gitlab).\n\nWant to join the team? [Browse our vacancies](/jobs/).\n",[9,680,998],{"slug":3567,"featured":6,"template":683},"how-remote-work-at-gitlab-enables-location-independence","content:en-us:blog:how-remote-work-at-gitlab-enables-location-independence.yml","How Remote Work At Gitlab Enables Location Independence","en-us/blog/how-remote-work-at-gitlab-enables-location-independence.yml","en-us/blog/how-remote-work-at-gitlab-enables-location-independence",{"_path":3573,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3574,"content":3579,"config":3584,"_id":3586,"_type":13,"title":3587,"_source":15,"_file":3588,"_stem":3589,"_extension":18},"/en-us/blog/how-to-ask-smarter-devops-questions",{"title":3575,"description":3576,"ogTitle":3575,"ogDescription":3576,"noIndex":6,"ogImage":3288,"ogUrl":3577,"ogSiteName":670,"ogType":671,"canonicalUrls":3577,"schema":3578},"How to ask smarter DevOps questions","Take your DevOps practice to the next level by asking 10 critical questions.","https://about.gitlab.com/blog/how-to-ask-smarter-devops-questions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to ask smarter DevOps questions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-06-22\",\n      }",{"title":3575,"description":3576,"authors":3580,"heroImage":3288,"date":3581,"body":3582,"category":1513,"tags":3583},[1246],"2022-06-22","\n\nGitLab has [surveyed DevOps practitioners](/developer-survey/) for more than five years now. In that time, we have come to know what questions to ask to understand how well teams are doing with DevOps. In sharing these 10 questions, we aim to help you assess your own team’s capabilities and achieve smarter, faster DevOps.\n\n### How fast is your team releasing code today vs. one year ago?\n\nTracking release speed is like taking the temperature of your DevOps team. You’d like to think everything is going well, but you might be surprised. Occasionally DevOps teams report to us they are actually releasing code more slowly than in the past. \n\n### What stage(s) in the process are causing the most release delays?\n\nThis question will shine a spotlight on the areas in your DevOps practice that simply don’t work. Spoiler alert: The answer [will certainly be testing](/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook/), though other things, from planning to code development and code review, might pop up, too.\n\n### How automated is your DevOps process?\n\nAsk this, but don’t just focus on testing, tempting as that might be. Also think about what else in the software development lifecycle would [benefit from automation](/blog/cd-automated-integrated/). Consider what getting that time back would afford you. Could you assign your developers and ops pros to other business-critical projects?\n\n### What’s been added to your DevOps tech stack over the last year?\n\nIt’s good to look back and take inventory of the technology you have in play. This is also data that can help inform what your next steps might be, such as adopting [GitOps](/topics/gitops/), [observability](/blog/observability-vs-monitoring-in-devops/), or [AI](https://www.youtube.com/watch?v=C08QVI99JLo).\n\n### How are your DevOps roles changing?\n\nIf your team is like others we’ve heard from, (big) changes are happening. Devs are picking up tasks that have traditionally been owned by ops, ops is becoming anything from a DevOps coach to a [platform engineer](/topics/devops/what-is-a-devops-platform-engineer/) or a cloud expert, and security is likely now embedded in development teams.\n\n### How does security integrate with DevOps in your organization?\n\nThe most successful DevOps teams have figured out how to [bridge the dev and sec divide](/blog/developer-security-divide/). Whether your team has a [security champion](/blog/why-security-champions/) or actually embeds sec pros on the dev team, this is a critical piece in the process to release safer software faster.\n\n### What advanced technologies are you using (or considering) in your DevOps practice?\n\n“Bots” can test code, [AI can review code](/blog/ai-in-software-development/), and a [low code/no code tool](/blog/low-code-no-code/) will make [citizen developers](https://www.gartner.com/en/information-technology/glossary/citizen-developer) out of anyone in the organization. Now is definitely the time to make sure your DevOps team is future-proofing the tech stack.\n\n### Do you have a plan for governance and compliance of your software supply chain?\n\nTo keep the [software supply chain secure](/blog/elite-team-strategies-to-secure-software-supply-chains/), DevOps teams need visibility into and control over the entire development lifecycle. Can you easily deal with audits or attestations of compliance? Mature governance and compliance processes are essential in all industries today, not just those that are highly regulated.\n\n### What advanced practices are you using (or considering) in your DevOps environment?\n\nWhether it’s [Infrastructure as Code (IaC)](/topics/gitops/infrastructure-as-code/), GitOps, or [MLOps](/blog/introducing-modelops-to-solve-data-science-challenges/), cutting-edge practices can jumpstart your releases and bring new and interesting opportunities to DevOps teams.\n\n### Do you regularly assess DevOps careers and roles on your team?\n\nHappy team members [really are more productive](/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen/), so consider this a PSA to keep career growth conversations a priority. \n\nIn considering these 10 questions, your team will gain a fuller picture of your DevOps capabilities and how to address the technology and talent gaps you have identified.\n\n",[851,9,829],{"slug":3585,"featured":6,"template":683},"how-to-ask-smarter-devops-questions","content:en-us:blog:how-to-ask-smarter-devops-questions.yml","How To Ask Smarter Devops Questions","en-us/blog/how-to-ask-smarter-devops-questions.yml","en-us/blog/how-to-ask-smarter-devops-questions",{"_path":3591,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3592,"content":3598,"config":3605,"_id":3607,"_type":13,"title":3608,"_source":15,"_file":3609,"_stem":3610,"_extension":18},"/en-us/blog/how-to-avoid-broken-master-with-pipelines-for-merge-requests",{"title":3593,"description":3594,"ogTitle":3593,"ogDescription":3594,"noIndex":6,"ogImage":3595,"ogUrl":3596,"ogSiteName":670,"ogType":671,"canonicalUrls":3596,"schema":3597},"How to prevent broken master with merge trains & pipelines","Do you still run pipelines on source branches? Let's start running them on merge commits!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678366/Blog/Hero%20Images/merge-train.jpg","https://about.gitlab.com/blog/how-to-avoid-broken-master-with-pipelines-for-merge-requests","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to avoid broken master with Pipelines for Merged Results and Merge Trains\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Shinya Maeda\"}],\n        \"datePublished\": \"2019-09-11\",\n      }",{"title":3599,"description":3594,"authors":3600,"heroImage":3595,"date":3602,"body":3603,"category":849,"tags":3604},"How to avoid broken master with Pipelines for Merged Results and Merge Trains",[3601],"Shinya Maeda","2019-09-11","\nBroken master. This can happen when CI pipelines run on the master branch (or default branch), but don't\npass all tests. A red cross mark is shown in the project's top page, signalling unstable source\ncode and eroding the trust of users. Broken master could also be a blocker against\na continuous deployment/delivery stream line in which deployment jobs\nare executed after the test stage passed in master pipelines.\n\nAll maintainers want to avoid this critical state,\nbut how can we prevent it?\n\n## Let's look at how master is broken in the first place\n\nLet's say you're one of the maintainers of a project. It's a busy repository with hundreds of merges\nto master every day. A developer assigns a merge request (MR) to you. The MR passed all of the tests in the CI pipelines,\nhas been reviewed thoroughly by code reviewers, all open discussions have been resolved, and the MR has been\napproved by the relevant [code owners](https://docs.gitlab.com/ee/user/project/codeowners/).\n\nYou would press the \"Merge\" button without a second thought, but how are you confident that\na pipeline running on master branch after the merge will pass all tests again?\nIf your answer is \"It might break the master branch,\" then\nyou're right. This could happen, for example, if master has advanced by some\nnew commits, and one of them changed a lint rule. The MR in question\nstill contains an invalid coding style, but the latest pipeline on the MR passes,\nbecause the feature branch is based on an old version of master.\n\nEnter two new GitLab features: [Pipelines for Merged Results](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html)\nand [Merge Trains](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.html).\nLet me show you how they works and how to enable them.\n\n## How to continually run CI pipelines on the merge commit\n\nLet's break down what went wrong in the scenario above. Even though the pipeline on the\nmerge request passed all the tests, it ran on a source (feature) branch\nwhich could be based on an outdated version of master. In such a case,\nthe result of pipeline is considered as _untrusted_, because there may be a huge difference\nbetween an actual-and-future merge commit and the commit in question.\n\nAs a [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions), developers can continually rebase their MR\non the latest master, but this is annoying and inefficient, given the speed of\ngrowth of the master branch.\nIt causes a lot of friction between developers and maintainers, slowing down the development cycle.\n\nTo address this problem, we introduced [Pipelines for Merged Results](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html)\nin [GitLab 11.10](/releases/2019/04/22/gitlab-11-10-released/#pipelines-for-merged-results).\n\nSimply put, the main difference between pipelines for merged results and normal pipelines is that\n**pipelines run on merge commits, instead of source branches, before the actual merge happens**.\nThis merge commit is generated from the latest commits of target branch and\nsource branch and written in a temporary place (`refs/merge-requests/:iid/merge`).\nTherefore, we can run a pipeline on it without interfering with master.\n\nHere is a sample workflow with the above scenario:\n\n1. A developer pushes a new commit to a merge request.\n1. GitLab creates a merge commit from the HEAD of the source branch and HEAD of the target branch.\n   This merge commit is written in `refs/merge-requests/:iid/merge` and does not change commit history of master branch.\n1. GitLab creates a pipeline on the merge commit, but this pipeline fails because the latest master changed a lint rule.\n1. A maintainer sees a failed pipeline in the merge request.\n\nAs you can see, the maintainer was able to hold off merging the dangerous MR\nbecause the latest pipeline on the MR didn't pass. The feature actually saved\nmaster from a broken state.\n\nAs a bonus, this workflow freeds developers from continual\nrebasing of their merge requests.\nAll they need to do is develop features with [Pipelines for Merged Results](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html).\nGitLab automatically creates an expected merge commit and validates the merge request prior to\nan actual merge.\n\n### How to get started with Pipelines for Merged Results\n\nYou can [start using this feature](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html#enabling-pipelines-for-merged-results)\ntoday, with just two steps:\n\n1. Edit the `.gitlab-ci.yml` config file to enable [pipelines for merge requests / merge request pipelines](https://docs.gitlab.com/ee/ci/merge_request_pipelines/).\n1. Enable the \"Merge pipelines will try to validate the post-merge result prior to merging\" option at **Settings > General > Merge requests** in your project.\n\n**Note:** If the configurations in your `.gitlab-ci.yml` file are too complex, you might stumble at the first point.\nWe're currently working on [improving the usability of pipelines for merge requests / merge request pipelines](https://gitlab.com/gitlab-org/gitlab-ce/issues/60085).\nPlease leave your feedback in the issue if that's the case.\n\n## How to avoid race condition of concurrent merges\n\nWith [Pipelines for Merged Results](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html),\nwe can confidently say that MRs are continually tested against the latest master branch.\nHowever, what if multiple MRs have been merged at the same time?\nFor example:\n\n- There are two merge requests: MR-1 and MR-2. The latest pipelines have already passed in both MRs.\n- John (maintainer) and Cathy (maintainer) merge MR-1 and MR-2 at the same time, respectively.\n\nLater on, it turns out that MR-2 contains a coding offence which has just been introduced by MR-1.\nMaintainers hit merge without knowing that, and\nneedless to say, this will result in broken master. How can we handle this race condition properly?\n\nIn [GitLab 12.1](/releases/2019/07/22/gitlab-12-1-released/#parallel-execution-strategy-for-merge-trains), we introduced a new feature,\n[Merge Trains](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/).\nBasically, a Merge Train is a queueing system that allows you to avoid this kind\nof race condition.\nAll you need to do is add merge requests to the merge train, and it\nhandles the rest of the work for you.\nIt creates merge commits according\nto the sequence of merge requests and runs pipelines on the expected merge commits.\nFor example, John and Cathy could have avoided broken master with the following workflow:\n\n1. John and Cathy add MR-1 and MR-2 to their [Merge Train](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/), respectively.\n1. In MR-1, the Merge Train creates an expected merge commit from HEAD of the source branch and HEAD of the target branch.\n   It creates a pipeline on the merge commit.\n1. In MR-2, the Merge Train creates an expected merge commit from HEAD of the source branch and the expected merge commit of MR-1.\n   It creates a pipeline on the merge commit.\n1. The pipeline in MR-1 passes all tests and merged into master branch.\n1. The pipeline in MR-2 fails because it violates a lint check which was changed by MR-1. MR-2 is dropped from the Merge Train.\n1. Developer revisits MR-2, fixes the coding offence, and asks Cathy to add it to the Merge Train again.\n\nAs you can see, the Merge Train successfully rejected MR-2 before it could break the master\nbranch. With this workflow, maintainers can feel more confident when they\ndecide to merge something. Also, this doesn't slow down development lifecycle\nthat pipelines are built on optimistic assumption that, in the above case,\nthe pipeline in MR-1 and the pipeline in MR-2 **start almost simultaneously**.\nMR-2 builds a merge commit as if MR-1 has already been merged, so that maintainers\ndon't need to wait for long time until each pipeline finished. If one of the\npipelines failed, the problematic merge request is dropped from the merge train\nand the train will be reconstructed without it.\n\n### How to get started with Merge Trains\n\nYou can [start using Merge Train](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.html#how-to-add-a-merge-request-to-a-merge-train)\ntoday, if you've already enabled [Pipelines for merged results](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/index.html#enabling-pipelines-for-merged-results). Click [\"Start/Add merge train\" button](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.html#how-to-add-a-merge-request-to-a-merge-train) in merge requests.\n\n## A quick demonstration of Merge Trains\n\nHere is a demonstration video that explains the advantage of Merge Train feature.\nIn this video, we'll simulate the common problem in a workflow without\nMerge Trains, and later, we resolve the problem by enabling a Merge Train.\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/D4qCqXgZkHQ\" frameborder=\"0\" allowfullscreen=\"true\">\n\u003C/iframe>\n\u003C/figure>\n\n## Wrap up\n\nRunning pipelines on expected merge commits allows us to predict what will happen\nin the future and avoid broken master proactively. It soothes the headache of\nrelease managers and gives maintainers and developers more confidence that their code\nis reliable enough to be merged and shipped. In addition, Merge Trains allow you\nto merge things safely without slowing down the development cycle.\n\nGive this advanced CI/CD feature a try today!\n\nFor more information, check out [the documentation on merge trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) and [pipelines for merge requests / merge request pipelines](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html).\n\nCover image by [Dan Roizer](https://unsplash.com/@danny159) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[108,976,894,9],{"slug":3606,"featured":6,"template":683},"how-to-avoid-broken-master-with-pipelines-for-merge-requests","content:en-us:blog:how-to-avoid-broken-master-with-pipelines-for-merge-requests.yml","How To Avoid Broken Master With Pipelines For Merge Requests","en-us/blog/how-to-avoid-broken-master-with-pipelines-for-merge-requests.yml","en-us/blog/how-to-avoid-broken-master-with-pipelines-for-merge-requests",{"_path":3612,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3613,"content":3619,"config":3624,"_id":3626,"_type":13,"title":3627,"_source":15,"_file":3628,"_stem":3629,"_extension":18},"/en-us/blog/how-to-become-more-productive-with-gitlab-ci",{"title":3614,"description":3615,"ogTitle":3614,"ogDescription":3615,"noIndex":6,"ogImage":3616,"ogUrl":3617,"ogSiteName":670,"ogType":671,"canonicalUrls":3617,"schema":3618},"How to become more productive with Gitlab CI","Explore some CI/CD strategies that can make your team more efficient and productive.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667358/Blog/Hero%20Images/gitlab-productivity.jpg","https://about.gitlab.com/blog/how-to-become-more-productive-with-gitlab-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to become more productive with Gitlab CI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-06-21\",\n      }",{"title":3614,"description":3615,"authors":3620,"heroImage":3616,"date":3621,"body":3622,"category":849,"tags":3623},[1869],"2021-06-21","\nCI/CD pipelines are the preeminent solution to mitigate potential risks while integrating code changes into the repository. CI/CD pipelines help isolate the impact of potential errors, making it easier to fix them. Top that with a tool that provides effective visibility into the running tasks and there you have a recipe for success.\n\nSince the primary purpose of CI/CD pipelines is to speed up the development process and provide value to the end user faster, there's always room to make the process more efficient. This blog post unpacks some strategies that can help you get the most out of your pipeline definition in [GitLab CI](/solutions/continuous-integration/).\n\n## How Directed Acyclic Graphs (DAG) enable concurrent pipelines\n\n![By using Needs keyword you can define dependencies for jobs that need to be used from previous stages.](https://about.gitlab.com/images/blogimages/dag-explained.jpeg)\nBy using the \"Needs\" keyword you can define dependencies for jobs that need to be used from previous stages.\n{: .note.text-center}\n\nIn a [basic-pipeline](https://docs.gitlab.com/ee/ci/pipelines/pipeline_architectures.html#basic-pipelines) structure, all the jobs in a particular stage run concurrently and the jobs in the subsequent stage have to wait on those to finish to get started. This continues for all the stages.\n\nIn the image above, the first job in the second stage only depends on the first two job in the first stage to get started. But with the basic pipeline order in place, it has to wait for all three jobs in the first stage to complete before it can start executing, which slows down the overall pipeline considerably. However, by using `needs:` keywords, you can define a direct dependency for the jobs and they would only have to wait on the job they depend on to get started. By using the [DAG strategy](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/), you could shed out a few minutes from the processes for a certain project, thereby increasing the pipeline execution speed and bringing down the CI minutes consumption.\n\nBy using `needs: []` you can make the job in any stage run immediately, as it doesn't have to wait on any other job to finish.\n\n## Why parallel jobs increase productivity\n\nNot all the jobs in a pipeline have an equal run-time. While some may take just a few seconds, some take much longer to finish. When there are many team members waiting on a running pipeline to finish to be able to make a contribution to the project, the productivity of the team takes a hit.\n\nGitLab provides a method to make clones of a job and run them in parallel for faster execution using the `parallel:` keyword. While [parallel jobs](https://docs.gitlab.com/ee/ci/yaml/#parallel) may not help in reducing the consumption of [CI minutes](/pricing/faq-compute-credit/), they definitely help increase work productivity.\n\n## Break down big pipelines with parallel matrix Jobs\n\nBefore the release of [parallel matrix jobs](https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs), in order to run multiple instances of a job with different variable values, the jobs had to be manually defined in the `.gitlab-ci-yml` like this:\n\n```yaml\n.run-test:\n  script: run-test $PLATFORM\n  stage: test\n\ntest-win:\n  extends: .run-test\n  variables:\n    - PLATFORM: windows\ntest-mac:\n  extends: .run-test\n  variables:\n    - PLATFORM: mac\ntest-linux:\n  extends: .run-test\n  variables:\n    - PLATFORM: linux\n```\n\nParallel matrix jobs were released with GitLab 13.3 and allow you to create jobs at runtime based on specified variables. Let's say there is a need to run multiple instances a job with different variables values for each instance — with a combination of `parallel:` and `matrix:` you accomplish just that.\n\n```yaml\ntest:\n  stage: test\n  script: run-test $PLATFORM\n  parallel:\n    matrix:\n      - PLATFORM: [windows, mac, linux]\n```\n\nBy using `parallel:` and `matrix:`, big pipelines can be broken down into manageable parts for efficient maintainance.\n\n## Reduce the risk of merge conflicts with parent/child pipelines\n\n![Parent-child pipelines can include external YAML files in you configuration](https://about.gitlab.com/images/blogimages/parent-child-explained.jpeg)\nThe parent pipeline generates a child pipeline via the trigger:include keywords.\n{: .note.text-center}\n\nFor better management of dependencies, many organizations prefer a mono-repo setup for their projects. But mono-repos have a flip side too. If a repository hosts a large number of projects and a single pipeline definition is used to trigger different automated processes for different components, the pipeline performance is negatively affected. By using [parent-child pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) you can design more efficient pipelines, since you can have multiple child-pipelines that run in parallel. The keyword `include:` is used to include external YAML files in your CI/CD configuration for this purpose. In the image above a pipeline (the parent) generates a child pipeline via the trigger:include keywords.\n\nThis approach also reduces the chances of merge conflicts from happening, as it allows to only edit a section of the pipeline if necessary.\n\n## Merge trains help the target branch stay stable\n\nWhen there's a lot of merge requests flowing into a project, there is a risk of merge conflicts. [Merge trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) is a powerful feature by GitLab that allows users to automatically merge a series of (queued) merge requests without breaking the target branch. Using this feature, you can add an MR to the train, and it would take care of it until it is merged.\n\n## Use multiple caches in the same job\n\nStarting 13.11, GitLab CI/CD provides the ability to [configure multiple cache keys in a single job](/releases/2021/04/22/gitlab-13-11-released/#use-multiple-caches-in-the-same-job) which will help you increase your pipeline performance. This functionality could help you save precious development time when the jobs are running.\n\n## How can an efficient pipeline save you money?\n\nBy using CI/CD strategies that ensure safe merging of new changes and a green master, organizations can worry less about unanticipated downtimes caused by infrastructural failures and code conflicts.\n\nWith faster pipelines, developers end up spending lesser time in maintenance and find time and space to bring in more thoughtfulness and creativity in their work, leading to improvements in code quality and the company atmosphere and morale.\n\nIf you are looking to bring down the cost of running your CI/CD pipelines for a large project, look up the [Artifact and cache settings](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#artifact-and-cache-settings) and [Optimizing GitLab for large repositories](https://docs.gitlab.com/ee/ci/large_repositories/) sections in the documentation.\n",[1396,1397,9,680],{"slug":3625,"featured":6,"template":683},"how-to-become-more-productive-with-gitlab-ci","content:en-us:blog:how-to-become-more-productive-with-gitlab-ci.yml","How To Become More Productive With Gitlab Ci","en-us/blog/how-to-become-more-productive-with-gitlab-ci.yml","en-us/blog/how-to-become-more-productive-with-gitlab-ci",{"_path":3631,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3632,"content":3638,"config":3645,"_id":3647,"_type":13,"title":3648,"_source":15,"_file":3649,"_stem":3650,"_extension":18},"/en-us/blog/how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io",{"title":3633,"description":3634,"ogTitle":3633,"ogDescription":3634,"noIndex":6,"ogImage":3635,"ogUrl":3636,"ogSiteName":670,"ogType":671,"canonicalUrls":3636,"schema":3637},"Review Apps for Android with GitLab, fastlane & Appetize.io","See how GitLab and Appetize.io can bring Review Apps to your Android project","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to create Review Apps for Android with GitLab, fastlane, and Appetize.io\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Andrew Fontaine\"}],\n        \"datePublished\": \"2020-05-06\",\n      }",{"title":3639,"description":3634,"authors":3640,"heroImage":3635,"date":3642,"body":3643,"category":1353,"tags":3644},"How to create Review Apps for Android with GitLab, fastlane, and Appetize.io",[3641],"Andrew Fontaine","2020-05-06","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn a [previous look at GitLab and _fastlane_], we discussed how _fastlane_ now\nautomatically publishes the Gitter Android app to the Google Play Store, but at\nGitLab, we live on [review apps], and review apps for Android applications didn't\nreally exist... until [Appetize.io] came to our attention.\n\nJust a simple extension of our existing `.gitlab-ci.yml`, we can utilize\nAppetize.io to spin up review apps of our Android application.\n\nIf you'd rather just skip to the end, you can see\n[my MR to the Gitter Android project].\n\n## Setting up Fastlane\n\nFortunately for us, _fastlane_ has integrated support for Appetize.io, so all\nthat's needed to hit Appetize is the addition of a new `lane`:\n\n```diff\ndiff --git a/fastlane/Fastfile b/fastlane/Fastfile\nindex eb47819..f013a86 100644\n--- a/fastlane/Fastfile\n+++ b/fastlane/Fastfile\n@@ -32,6 +32,13 @@ platform :android do\n     gradle(task: \"test\")\n   end\n\n+  desc 'Pushes the app to Appetize and updates a review app'\n+  lane :review do\n+    appetize(api_token: ENV['APPETIZE_TOKEN'],\n+             path: 'app/build/outputs/apk/debug/app-debug.apk',\n+             platform: 'android')\n+  end\n+\n   desc \"Submit a new Internal Build to Play Store\"\n   lane :internal do\n     upload_to_play_store(track: 'internal', apk: 'app/build/outputs/apk/release/app-release.apk')\n```\n\n`APPETIZE_TOKEN` is an Appetize.io API token that can be generated on the\n[Appetize API docs] after signing up for an account. Once we add a new job and\nstage to our `.gitlab-ci.yml`, we will be able to deploy our APK to Appetize and\nrun them in the browser!\n\n```diff\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex d9863d7..e4d0ce3 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -5,6 +5,7 @@ stages:\n   - environment\n   - build\n   - test\n+  - review\n   - internal\n   - alpha\n   - beta\n@@ -81,6 +82,16 @@ buildRelease:\n   environment:\n     name: production\n\n+deployReview:\n+  stage: review\n+  image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n+  script:\n+    - bundle exec fastlane review\n+  only:\n+    - branches\n+  except:\n+    - master\n+\n testDebug:\n   image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n   stage: test\n```\n\nGreat! Review apps will be deployed when branches other than `master` build.\nUnfortunately, there is no `environment` block, so there's nothing linking these\ndeployed review apps to GitLab. Let's fix that next.\n\n## Dynamic Environment URLs\n\nPreviously, GitLab only liked environment URLs that used pre-existing CI\nvariables (like `$CI_COMMT_REF_NAME`) in their definition. Since 12.9, however,\na [new way of defining environment urls with alternative variables exists].\n\nBy creating a `dotenv` file and submitting it as an `artifact` in our build, we\ncan define custom variables to use in our environment's URL. As all Appetize.io\napp URLs take the pattern of `https://appetize.io.app/$PUBLIC_KEY`, where\n`$PUBLIC_KEY` is randomly generated when the app is created, we need to get the\npublic key from the Appetize response in our `Fastfile`, and put it in a\n`dotenv` file.\n\n```diff\ndiff --git a/fastlane/Fastfile b/fastlane/Fastfile\nindex 7b5f9d1..ae3867c 100644\n--- a/fastlane/Fastfile\n+++ b/fastlane/Fastfile\n@@ -13,6 +13,13 @@\n # Uncomment the line if you want fastlane to automatically update itself\n # update_fastlane\n\n+\n+def update_deployment_url(pub_key)\n+  File.open('../deploy.env', 'w') do |f|\n+    f.write(\"APPETIZE_PUBLIC_KEY=#{pub_key}\")\n+  end\n+end\n+\n default_platform(:android)\n\n platform :android do\n@@ -37,6 +44,7 @@ platform :android do\n     appetize(api_token: ENV['APPETIZE_TOKEN'],\n              path: 'app/build/outputs/apk/debug/app-debug.apk',\n              platform: 'android')\n+    update_deployment_url(lane_context[SharedValues::APPETIZE_PUBLIC_KEY])\n   end\n\n   desc \"Submit a new Internal Build to Play Store\"\n```\n\nWe also need to add an `environment` block to our `.gitlab-ci.yml` to capture an\nenvironment name and URL.\n\n```diff\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex f5a8648..c834077 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -85,12 +85,18 @@ buildCreateReleaseNotes:\n deployReview:\n   stage: review\n   image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n+  environment:\n+    name: review/$CI_COMMIT_REF_NAME\n+    url: https://appetize.io/app/$APPETIZE_PUBLIC_KEY\n   script:\n     - bundle exec fastlane review\n   only:\n     - branches\n   except:\n     - master\n+  artifacts:\n+    reports:\n+      dotenv: deploy.env\n\n testDebug:\n   image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n```\n\nOnce committed, pushed, and a pipeline runs, we should see our environment\ndeployed!\n\n![Our first review environment][first-review-app]\n\n## Optimizing Updates\n\nAfter running with this for a bit, we realized that we were accidentally\ncreating a new app on Appetize.io with every new build! Their docs\n[specify how to update existing apps], so we went about seeing if we could\nsmartly update existing environments.\n\nSpoiler alert: We could.\n\nFirst, we need to save the public key granted to us by Appetize.io somewhere. We\ndecided to put it in a JSON file and save that as an artifact of the build.\nFortunately, the `Fastfile` is just ruby, which allows us to quickly write it\nout to a file with a few lines of code, as well as attempt to fetch the artifact\nfor the last build of the current branch.\n\n```diff\ndiff --git a/fastlane/Fastfile b/fastlane/Fastfile\nindex ae3867c..61e9226 100644\n--- a/fastlane/Fastfile\n+++ b/fastlane/Fastfile\n@@ -13,8 +13,32 @@\n # Uncomment the line if you want fastlane to automatically update itself\n # update_fastlane\n\n+require 'net/http'\n+require 'json'\n+\n+GITLAB_TOKEN = ENV['PRIVATE_TOKEN']\n+PROJECT_ID = ENV['CI_PROJECT_ID']\n+REF = ENV['CI_COMMIT_REF_NAME']\n+JOB = ENV['CI_JOB_NAME']\n+API_ROOT = ENV['CI_API_V4_URL']\n+\n+def public_key\n+  uri = URI(\"#{API_ROOT}/projects/#{PROJECT_ID}/jobs/artifacts/#{REF}/raw/appetize-information.json?job=#{JOB}\")\n+  http = Net::HTTP.new(uri.host, uri.port)\n+  http.use_ssl = true\n+  req = Net::HTTP::Get.new(uri)\n+  req['PRIVATE-TOKEN'] = GITLAB_TOKEN\n+  response = http.request(req)\n+  return '' if response.code.equal?('404')\n+\n+  appetize_info = JSON.parse(response.body)\n+  appetize_info['publicKey']\n+end\n\n def update_deployment_url(pub_key)\n+  File.open('../appetize-information.json', 'w') do |f|\n+    f.write(JSON.generate(publicKey: pub_key))\n+  end\n   File.open('../deploy.env', 'w') do |f|\n     f.write(\"APPETIZE_PUBLIC_KEY=#{pub_key}\")\n   end\n@@ -42,6 +66,7 @@ platform :android do\n   desc 'Pushes the app to Appetize and updates a review app'\n   lane :review do\n     appetize(api_token: ENV['APPETIZE_TOKEN'],\n+             public_key: public_key,\n              path: 'app/build/outputs/apk/debug/app-debug.apk',\n              platform: 'android')\n     update_deployment_url(lane_context[SharedValues::APPETIZE_PUBLIC_KEY])\n```\n\nWhen we go to deploy our app to Appetize, we hit the [Jobs API] to see if we\nhave a public key for this branch. If the API returns a `404`, we know we are\nbuilding a fresh branch and return an empty string, else we parse the JSON and\nreturn our public key. The [Fastlane docs] state the `appetize` action can take\na `public_key` to update an existing app. Here, `''` is considered the same as\n_not_ providing a public key, so a new application is still deployed as we expect.\n\n**NOTE:** If you've read the `diff` closely, you'll notice the usage of an\nenvironment variable called `PRIVATE_TOKEN`. This is a GitLab private token\ncreated with the `read_api` scope and injected into our build as an environment\nvariable. This is required to authenticate with the GitLab API and fetch\nartifacts.\n\nOnce we update `.gitlab-ci.yml` to save the new `appetize-information.json` file\nas an artifact, later builds on the same branch will be smart and update the\nexisting Appetize app!\n\n```diff\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex c834077..54cf3f6 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -95,6 +95,8 @@ deployReview:\n   except:\n     - master\n   artifacts:\n+    paths:\n+      - appetize-information.json\n     reports:\n       dotenv: deploy.env\n```\n\n## Cleaning up\n\nAll that's left is to delete old apps from Appetize once we don't need them\nanymore. We can do that by leveraging `on_stop` and creating a `stop` job that\nwill delete our app from Appetize.io\n\n```diff\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 54cf3f6..f6ecf7e 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -10,6 +10,7 @@ stages:\n   - alpha\n   - beta\n   - production\n+  - stop\n\n\n .updateContainerJob:\n@@ -88,6 +89,7 @@ deployReview:\n   environment:\n     name: review/$CI_COMMIT_REF_NAME\n     url: https://appetize.io/app/$APPETIZE_PUBLIC_KEY\n+    on_stop: stopReview\n   script:\n     - bundle exec fastlane review\n   only:\n@@ -100,6 +102,22 @@ deployReview:\n     reports:\n       dotenv: deploy.env\n\n+stopReview:\n+  stage: stop\n+  environment:\n+    name: review/$CI_COMMIT_REF_NAME\n+    action: stop\n+  variables:\n+    GIT_STRATEGY: none\n+  when: manual\n+  only:\n+    - branches\n+  except:\n+    - master\n+  script:\n+    - apt-get -y update && apt-get -y upgrade && apt-get -y install jq curl\n+    - curl --request DELETE https://$APPETIZE_TOKEN@api.appetize.io/v1/apps/`jq -r '.publicKey' \u003C appetize-information.json`\n+\n testDebug:\n   image: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG\n   stage: test\n```\n\nOnce your MR is merged and your branch is deleted, the `stopReview` job runs,\ncalling the [`DELETE` endpoint of the Appetize.io API] with the public key that\nis contained in `appetize-information.json`. We don't need to fetch\n`appetize-information.json` because the artifact is already present in our build\ncontext. This is because the `stop` stage happens _after_ the `review` stage.\n\n![A merge request with a deployed review app][merge-request-with-review-app]\n\n## Conclusion\n\nThanks to some integration with _fastlane_ and the addition of a couple\nenvironment variables, having the ability to create review apps for an Android\nproject was surpsingly simple. GitLab's review apps are not _just_ for web-based\nprojects, even though it may take a little tinkering to get working. Appetize.io\nalso supports iOS applications, so all mobile native applications can be turned\ninto review apps. I would love to see this strategy be applied to a React Native\nproject as well!\n\n[previous look at gitlab and _fastlane_]: /blog/android-publishing-with-gitlab-and-fastlane/\n[my mr to the gitter android project]: https://gitlab.com/gitlab-org/gitter/gitter-android-app/-/merge_requests/167\n[review apps]: https://docs.gitlab.com/ee/ci/review_apps/#review-apps\n[appetize.io]: https://appetize.io\n[appetize api docs]: https://appetize.io/docs#request-api-token\n[new way of defining environment urls with alternative variables exists]: https://docs.gitlab.com/ee/ci/environments/index.html#set-dynamic-environment-urls-after-a-job-finishes\n[first-review-app]: /images/blogimages/how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io/first-review-app.png\n[specify how to update existing apps]: https://appetize.io/docs#updating-apps\n[jobs api]: https://docs.gitlab.com/ee/api/jobs.html#download-a-single-artifact-file-from-specific-tag-or-branch\n[fastlane docs]: https://docs.fastlane.tools/actions/appetize/\n[`delete` endpoint of the appetize.io api]: https://appetize.io/docs#deleting-apps\n[merge-request-with-review-app]: /images/blogimages/how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io/merge-request-with-review-app.png\n",[108,230,9,746],{"slug":3646,"featured":6,"template":683},"how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io","content:en-us:blog:how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io.yml","How To Create Review Apps For Android With Gitlab Fastlane And Appetize Dot Io","en-us/blog/how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io.yml","en-us/blog/how-to-create-review-apps-for-android-with-gitlab-fastlane-and-appetize-dot-io",{"_path":3652,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3653,"content":3659,"config":3664,"_id":3666,"_type":13,"title":3667,"_source":15,"_file":3668,"_stem":3669,"_extension":18},"/en-us/blog/how-to-include-file-references-in-your-ci-cd-components",{"title":3654,"description":3655,"ogTitle":3654,"ogDescription":3655,"noIndex":6,"ogImage":3656,"ogUrl":3657,"ogSiteName":670,"ogType":671,"canonicalUrls":3657,"schema":3658},"How to include file references in your CI/CD components","Learn how to include scripts and dependencies in your CI/CD components to minimize duplications and simplify maintenance. This tutorial takes you step-by-step through the process.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to include file references in your CI/CD components\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2024-10-16\",\n      }",{"title":3654,"description":3655,"authors":3660,"heroImage":3656,"date":3661,"body":3662,"category":701,"tags":3663},[1769],"2024-10-16","I’m frequently asked whether included CI/CD components can reference additional files stored outside of the pipeline repository. While including components in your configuration is straightforward since they’re just YAML, many users want to know if those included components can access and execute additional files referenced by the components, like shell scripts or other dependencies. \n\nThis challenge has been a common topic of discussion in threads across the [GitLab Forum](https://forum.gitlab.com/t/gitlab-ci-includes-a-file-from-another-project-that-executes-a-script-file/111698) and [Reddit](https://www.reddit.com/r/gitlab/comments/18ma13x/gitlab_components_question/).\n\nNow for the good news: CI/CD components not only allow you to reuse pipeline configurations, saving time and effort, but you can also go a step further. With the new [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/), you can directly reuse centralized automation scripts and dependencies in your pipelines. You'll gain even greater flexibility, making your pipelines more powerful and adaptable than ever.\n\nBy storing your scripts in a central location and wrapping them in CI/CD Steps, you can easily call these steps from your CI/CD components. This eliminates the need to duplicate scripts across multiple repositories and CI/CD configurations, streamlining your workflow and reducing redundancy.\n\nBefore we dive into the step-by-step guide, let’s briefly explore what CI/CD components and CI/CD Steps are.\n\n## What are CI/CD components?\n\n[CI/CD components](https://docs.gitlab.com/ee/ci/components/) are reusable units of pipeline configurations that get included in a pipeline when it’s created. The components bring additional jobs into the pipeline, however they can’t bring additional files as such reusable scripts. \n\n## What are CI/CD Steps?\n\n[CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/) are reusable units of a job. Each step defines structured inputs and outputs that can be consumed by other steps. Steps can come from local files, GitLab.com repositories, or any other Git source. Steps offer a structured alternative to shell scripts for running jobs. They are modular, can be composed, tested, and easily reused, providing greater flexibility and maintainability.\n\n## What are the differences between CI/CD Steps and CI/CD components?\n\n- Component and step definitions look very similar but they take effect at different phases in pipeline execution. \n\n- Components are used when a pipeline is created while steps are used when individual jobs are running. \n\n- When a step is running, the whole repository is being downloaded into the job environment along with extra files. \n\n## A step-by-step guide\n\nHere is how CI/CD Steps and Components work together to access additional files.\n\n![CI/CD Steps flow diagram](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/steps-diagram-for-blog.png)\n\nThis diagram illustrates the process flow: Jobs defined within components are imported into the pipeline configuration (`.gitlab-ci.yml`) when the pipeline is created. During the pipeline's execution, a job’s steps are executed, and the entire Git repository is downloaded to the [Step runner](https://docs.gitlab.com/ee/ci/steps/#using-steps) within the job’s context. This ensures that references to dependencies function correctly.\n\n**1\\. Define a component with `run` keyword that runs CI/CD Steps**\n\nRun is a new keyword that supports running steps, see the example code below. You can use [this guide](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/) to learn more on how to create Components. \n\n![template-yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/Screenshot_2024-10-13_at_8.22.00.png)\n\n**2\\. Create a `step.yml` file in the project where your scripts and dependencies are located.**\n\nIn this code example, format.sh exists in the same directory as the `step.yml`. \n\n![step.yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/Screenshot_2024-10-13_at_8.23.52.png)\n\n While the job is running, the Step runner will download the entire Git repository where the step is defined. The `${{ step_dir }}` step expression references the directory of the locally cached step files, allowing you to access other files from the repository. In the example above, the “format” step invokes the format.sh script.\n\n**3\\. Make sure that any files accessed by the step are located in the same repository as the `step.yml` file.**\n\n**4\\. Include the component in your CI/CD configuration.**\n\nSee this example code:\n\n![.gitlab-ci.yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675829/Blog/Content%20Images/Screenshot_2024-10-13_at_8.26.22.png)\n\nCode example: You can find the entire code demonstrated in this blog in this [GitLab Group](https://gitlab.com/gitlab-da/use-cases/ci-steps). \n\n**Important note:** The CI/CD Steps feature is currently [Experimental](https://docs.gitlab.com/ee/policy/experiment-beta-support.html#experiment), and the syntax may change as we continue to iterate and refine it based on user feedback. Any feedback should be provided via [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/493694).\n\n## Learn more\n\n- Watch [this walkthrough](https://youtu.be/qxTbeYXEQLM) by [Joe Burnett](https://about.gitlab.com/company/team/#josephburnett), principal engineer at GitLab, as he demonstrates the example discussed in the blog post.\n\n- [Introducing CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/)\n\n- [Introducing CI/CD components](https://about.gitlab.com/blog/introducing-ci-components/)",[108,851,9,701],{"slug":3665,"featured":6,"template":683},"how-to-include-file-references-in-your-ci-cd-components","content:en-us:blog:how-to-include-file-references-in-your-ci-cd-components.yml","How To Include File References In Your Ci Cd Components","en-us/blog/how-to-include-file-references-in-your-ci-cd-components.yml","en-us/blog/how-to-include-file-references-in-your-ci-cd-components",{"_path":3671,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3672,"content":3678,"config":3684,"_id":3686,"_type":13,"title":3687,"_source":15,"_file":3688,"_stem":3689,"_extension":18},"/en-us/blog/how-to-leverage-gitlab-duo-for-enhanced-security-reporting",{"title":3673,"description":3674,"ogTitle":3673,"ogDescription":3674,"noIndex":6,"ogImage":3675,"ogUrl":3676,"ogSiteName":670,"ogType":671,"canonicalUrls":3676,"schema":3677},"How to leverage GitLab Duo for enhanced security reporting","Learn how GitLab Duo enables efficient, real-world security reporting for development, operations, and security teams.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098339/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750098339103.png","https://about.gitlab.com/blog/how-to-leverage-gitlab-duo-for-enhanced-security-reporting","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to leverage GitLab Duo for enhanced security reporting\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valentine Mairet\"},{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":3673,"description":3674,"authors":3679,"heroImage":3675,"date":3681,"body":3682,"category":806,"tags":3683},[3680,1994],"Valentine Mairet","2024-12-03","Good security reporting is crucial to maintain a good security posture because it provides detailed insights into incidents. With this information, organizations can better understand vulnerabilities, improve defenses, and prevent similar threats in the future. At GitLab, the [Security division](https://handbook.gitlab.com/handbook/security/#division-structure) has created use cases for GitLab Duo to improve reporting capabilities and enhance operational efficiency. \n\n## GitLab Duo’s security capabilities\n\nThe GitLab Security division uses GitLab’s built-in [incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) to manage and report on security incidents. Incidents are handled, documented, and resolved in GitLab, enabling the use of AI-driven [GitLab Duo](https://about.gitlab.com/gitlab-duo/) as an assistant when performing security operations like incident response. \n\nParticularly in incident analysis and reporting, GitLab Duo is highly efficient and accurate at creating proper documentation and is a great “pair programmer” when solving security incidents.\n\n## GitLab Duo features for security reporting\n\nGitLab Duo offers many features that enhance security reporting:\n\n- **Root Cause Analysis:** GitLab Duo can explain vulnerabilities and understand the context of an incident issue, making it an excellent assistant for performing root cause analyses of security incidents.\n- **Vulnerability Explanation:** Provides detailed insights into identified vulnerabilities, including potential exploitation methods and remediation steps. This feature aids developers and security analysts in understanding and addressing security issues effectively.\n- **Vulnerability Resolution:** Assists in fixing vulnerabilities by generating merge requests that address the identified issues, streamlining the remediation process.\n- **Code Explanation:** Helps users comprehend specific code segments by offering clear explanations, which is particularly useful when dealing with complex or unfamiliar codebases.\n- **Test Generation:** Facilitates early bug detection by generating tests for selected code, ensuring that security vulnerabilities are identified and addressed promptly.\n- **Refactor Code:** Suggests improvements or refactoring for selected code to enhance its quality and maintainability, contributing to a more secure codebase.\n- **Fix Code:** Identifies and rectifies quality issues such as bugs or typos in the selected code, helping maintain a robust and secure codebase.\n\n## Practical use cases\n\nFor the purpose of demonstrating practical use cases, the Security Incident Response Team created a dummy incident with following limited information:\n\n![Incident report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098346/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098346297.png)\n\nSeveral comments were added as the team would normally proceed:\n\n![Comments added to report](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098346/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098346297.png)\n\n### Incident reporting\n\nGitLab Duo is able to comprehensively keep track of all information inside an incident issue, including the issue description, comments, and labels. When handling security incidents, information often is all over the place and can change over time. It can easily get lost or overlooked. GitLab Duo is excellent at finding relevant information again to create accurate incident reports. \n\nNavigate to your incident issue and open GitLab Duo Chat. You can engineer your prompt so that GitLab Duo takes your exact reporting requirements into account such as what sections you need and how they should be filled out. Here is an example of the prompt we use at GitLab Security:\n\n> Required sections:\n> - Executive Summary - bottom-line-up-front that is adequate for an audience like senior leadership and CISO\n> - Mitigations & Remediations\n> - Scope & Impact (Environments, customers, team members)\n> - Cause\n> - Detection Capabilities\n>\n> Based on the issue and the required section, write the security incident report. Flag any missing information. \n\nBelow is GitLab Duo’s output that we can use to create our extensive incident report:\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175975/Blog/zxiafech08ck9gqjubaz.png\" alt=\"root cause analysis output\" width=\"400\" height=\"1200\">\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175985/Blog/xjc9coah4oi7rz0daw2b.png\" alt=\"root cause analysis output\" width=\"400\" height=\"1200\">\n\n### Root Cause Analysis\n\nGitLab Duo is able to explain vulnerabilities and can understand the context of an incident issue. These capabilities make GitLab Duo an excellent assistant to perform root cause analyses of security incidents. \n\nAs seen above, GitLab Duo can write its own section on the cause of an incident based entirely on the issue contents. We can dig into this further with the assistance of GitLab Duo to identify several candidates for root cause(s).  \n\nOur prompt is built as such:\n\n> “The root cause of the incident was the exposure of a personal access token in CI job logs. The token was leaked in a project that was not included in the current list of projects for token detection, indicating a gap in the security monitoring process.”\n> Name a few potential root causes for a PAT finding itself in CI job logs.\n\nGitLab Duo’s response is the following:\n\n![GitLab Duo Root Cause Analysis response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098346/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098346298.png)\n\nGitLab Duo Root Cause Analysis can help security teams identify avenues worth investigating. It has a pretty good grasp on security concepts and how Root Cause Analysis is led in general, so it can be a great assistant for these situations where the exact root of the problem is unclear. \n\n> Learn more about [GitLab Duo Root Cause Analysis](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/).\n\n### On-demand updates\n\nSecurity incidents move fast and can be confusing, and information is constantly changing and shifting around. Higher severity incidents require a certain degree of thoroughness when it comes to reporting to senior leadership, especially when the audience is at the Director+ level. Engineers who are in the midst of a security incident can find it difficlut to condense the information such that it is digestable for executives. \n\nWe saw above that GitLab Duo is capable of delivering a pretty good executive summary. When the incident is ongoing, we need to deliver regular updates to senior leadership on the incident status and next steps. GitLab Duo is a great help for that, as well. If information is scattered across the issue in the form of a description or comments, GitLab Duo can help reassemble this information into the “bottom-line-up-front,” or BLUF summary, we need for executive updates. \n\nWe’ve taken the same incident right before token revocation and asked GitLab Duo for a BLUF summary where the audience is the Director of Security Operations. \n\n![Executive Summary - GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098346/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098346299.png)\n\n## Getting started with GitLab Duo for security\n\nGitLab Security has automated several parts of the reporting process with the help of GitLab Duo. But to get started, all you need is access to GitLab Duo Chat. GitLab Duo Chat can be your well-informed assistant for many security reporting cases and post-mortem analyses.\n\n## What’s next for GitLab Duo?\n\nGitLab is committed to continuously enhancing GitLab Duo’s capabilities. Future developments aim to integrate AI-driven features more deeply into the security workflow, providing proactive detection and resolution of vulnerabilities, streamlined incident management, and comprehensive reporting tools. These advancements will further empower security teams to maintain robust security postures and respond effectively to emerging threats.\n\n> [Try GitLab Duo for 60 days for free](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/)!\n",[786,746,704,9,478],{"slug":3685,"featured":6,"template":683},"how-to-leverage-gitlab-duo-for-enhanced-security-reporting","content:en-us:blog:how-to-leverage-gitlab-duo-for-enhanced-security-reporting.yml","How To Leverage Gitlab Duo For Enhanced Security Reporting","en-us/blog/how-to-leverage-gitlab-duo-for-enhanced-security-reporting.yml","en-us/blog/how-to-leverage-gitlab-duo-for-enhanced-security-reporting",{"_path":3691,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3692,"content":3698,"config":3703,"_id":3705,"_type":13,"title":3706,"_source":15,"_file":3707,"_stem":3708,"_extension":18},"/en-us/blog/how-to-migrate-gitlab-groups-and-projects-more-efficiently",{"title":3693,"description":3694,"ogTitle":3693,"ogDescription":3694,"noIndex":6,"ogImage":3695,"ogUrl":3696,"ogSiteName":670,"ogType":671,"canonicalUrls":3696,"schema":3697},"How to migrate GitLab groups and projects more efficiently","Learn about performance improvements to GitLab migration by direct transfer and what's next.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668760/Blog/Hero%20Images/migration2.jpg","https://about.gitlab.com/blog/how-to-migrate-gitlab-groups-and-projects-more-efficiently","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to migrate GitLab groups and projects more efficiently\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n        \"datePublished\": \"2023-08-02\",\n      }",{"title":3693,"description":3694,"authors":3699,"heroImage":3695,"date":3700,"body":3701,"category":1513,"tags":3702},[3330],"2023-08-02","Migrating groups and projects using direct transfer enables you to easily move GitLab resources between GitLab instances using either the UI or API. In a [previous blog post](https://about.gitlab.com/blog/try-out-new-way-to-migrate-projects/), we announced the release of migrating projects as a beta\nfeature **available to everyone**. We described the benefits of the method and steps to try it out.\n\nSince then, we have made further improvements, especially focusing on [efficient](https://gitlab.com/groups/gitlab-org/-/epics/8983) and\n[reliable](https://gitlab.com/groups/gitlab-org/-/epics/8927) migrations for large projects. In this blog, we'll elaborate on these improvements, as well as their impact on the overall process and speed of migrations. We'll also discuss estimating the duration of migrations.\n\n## Imports of CI/CD pipelines\n### Problem: Timing out\nWe received [a bug report about imports of CI/CD pipelines timing out](https://gitlab.com/gitlab-org/gitlab/-/issues/365702) and realized we needed to refine the underlying migration process. We considered the root cause of the problem and possible solutions, and ran proofs of concept. We concluded that we should tackle the\nproblem of having one massive archive file for a project with a large number of a certain relation types (for example, pipelines).\n\n### What we improved\nTo fix the problem of timeouts, we decided to introduce batching to the process of exporting and importing relations (for example, merge requests or pipelines).\n\nBefore we could fully complete the [epic for introducing the batching](https://gitlab.com/groups/gitlab-org/-/epics/9036), we had to introduce a couple of other optimizations\nto the process of exporting CI/CD pipelines.\n\nIn GitLab 15.10, we started:\n- [preloading associations when exporting CI/CD pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/391593)\n- [exporting commit notes as a separate relation](https://gitlab.com/gitlab-org/gitlab/-/issues/391601)\n\nWith these optimizations, exporting CI/CD pipelines sped up considerably. That allowed for a large number of pipelines in a project to be successfully exported to an archive file and then imported on the destination instance. However, because we were finally importing the pipelines, the overall duration of the migration increased.\n\nIn GitLab 16.3, we are introducing [exporting and importing relations in batches](https://gitlab.com/groups/gitlab-org/-/epics/9036). This has two benefits:\n- improves migration performance by creating and transferring smaller archive files, instead of one file per relation. These files can be very big if a project has thousands of pipelines.\n- enables more parallelism. For example, the CI pipeline data is now split into multiple batches and concurrent Sidekiq jobs (assuming the Sidekiq workers are available on the destination instance, see below) import each batch.\n\nThis improvement is already available by default on GitLab.com.\n- **Users migrating from a self-managed GitLab instance to GitLab.com** have to have their self-managed instance on at least GitLab 16.2, where batched export is available, to benefit from this improvement.\n- **Users migrating from GitLab.com to a self-managed GitLab instance** have to have their self-managed instance on at least GitLab 16.2 and enable the `bulk_imports_batched_import_export` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html) to benefit from this improvement.\n\n## Can we estimate the duration of a migration?\nThis question has been asked time and again. The answer is that duration of migration with direct transfer depends on many different factors. Some of them are: \n\n- Hardware and database resources available on the source and destination GitLab instances. More resources on the source and destination instances can result in shorter migration duration because:\n  - the source instance receives API requests, and extracts and serializes the entities to export\n  - the destination instance runs the jobs and creates the entities in its database\n- Complexity and size of data to be exported. For example, imagine you want to migrate two different projects with 1,000 merge requests each. The two projects can take very different amounts of time to migrate if one of the projects has a lot more attachments, comments, and other items on the merge requests. Therefore, the number of merge requests on a project is a poor predictor of how long a project will take to migrate.\n\nThere’s no exact formula to reliably estimate a migration. However, we checked the duration of each job importing a project relation to share with you the average numbers, so you can get an idea of how long importing your projects might take. Here is what we found:\n\n- importing an empty project takes about 2.4 seconds\n- importing one MR takes about 1 second\n- importing one issue takes about 0.1 seconds\n\nYou can find more project relations and the average duration to import them in the table below.\n\n| Project resource type | Average time (in seconds) to import a single record |\n| ---- | ---- |\n| Empty project\t| 2.4 |\n| Repository | 20 |\n| Project attributes\t| 1.5 |\n| Members\t| 0.2 |\n| Labels\t| 0.1 |\n| Milestones\t| 0.07 |\n| Badges\t| 0.1 |\n| Issues\t| 0.1 |\n| Snippets\t| 0.05 |\n| Snippet repositories | 0.5 |\n| Boards\t| 0.1 |\n| Merge requests\t| 1 |\n| External pull requests\t| 0.5 |\n| Protected branches\t| 0.1 |\n| Project feature\t| 0.3 |\n| Container expiration policy\t| 0.3 |\n| Service desk setting\t| 0.3 |\n| Releases | 0.1 |\n| CI/CD pipelines\t| 0.2 |\n| Commit notes\t| 0.05 |\n| Wiki\t| 10 |\n| Uploads |\t0.5 |\n| LFS objects\t| 0.5 |\n| Design\t| 0.1 |\n| Auto DevOps\t| 0.1 |\n| Pipeline schedules\t| 0.5 |\n| References\t| 5 |\n| Push rule\t| 0.1 |\n\n## How can we migrate efficiently?\nWe also know what is needed to achieve the most efficient migration possible. \n\nA single direct transfer migration runs up to five entities (groups or projects) per import at a time, independent of the number of Sidekiq workers available on the destination instance. Importing five concurrent entities is the maximum allowed per migration by direct transfer. This limit has been set to not overload the source GitLab instance, because\nwe saw network timeouts from source instances when we removed this limitation.\n\nThat doesn't mean that if more than five Sidekiq workers are available on the destination instance that they won't be utilized during a migration. On the contrary, more Sidekiq\nworkers help speed up the migration by decreasing the time it takes to import each entity. Import of relations is distributed across multiple jobs and a single project entity\nhas over 30 relations to be migrated. [Exporting and importing relations in batches](https://gitlab.com/groups/gitlab-org/-/epics/9036) mentioned above results in even more\njobs to be processed by the Sidekiq workers. \n\nIncreasing the number of Sidekiq workers on the destination instance helps speed up the migration until the source instance hardware resources are saturated. For more information on\nincreasing the number of Sidekiq workers (increasing concurrency), see [Set up Sidekiq instance](https://docs.gitlab.com/ee/administration/sidekiq/#set-up-sidekiq-instance).\n\nThe number of Sidekiq workers on the source instance should at least be enough to export the five concurrent entities in parallel (for each running import). Otherwise, there will\nbe delays and potential timeouts as the destination is waiting for exported data to become available.\n\nDistributing projects in different groups helps to avoid timeouts. If several large projects are in the same group, you can:\n1. Move large projects to different groups or subgroups.\n1. Start separate migrations each group and subgroup.\n\nThe GitLab UI can only migrate top-level groups. Using the API, you can also migrate subgroups.\n\n## What's next for migrating by direct transfer?\nOf course, we're not done yet! We will continue to improve the direct transfer method, aiming towards coming out of beta and into general availability. Next, we are working on:\n\n- [Moving hardcoded limits of direct transfer to settings](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) - Migration by direct transfer has some hardcoded limits that can be made configurable to allow self-managed GitLab administrators to tune them according to their needs. For GitLab.com, we could set these limits higher than their hardcoded setting.\n- [Removing a 90-minute export timeout](https://gitlab.com/gitlab-org/gitlab/-/issues/392725) - Removing this limit will allow exporting of even larger projects, because only projects that can be migrated in under 90 minutes are supported at the moment.\n\nMore details can be found on our [migrating by direct transfer roadmap direction page](https://about.gitlab.com/direction/manage/import_and_integrate/importers/). We are excited about this roadmap and hope you are too!\n\nWe want to hear from you. What's the most important missing piece for you? What else can we improve? Let us know\nin the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495) or [schedule time](https://calendly.com/gitlab-magdalenafrankiewicz/45mins) with the Import and Integrations group product manager, and we'll keep iterating!\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n\nCover image by [Adrien VIN](https://unsplash.com/fr/@4dr13nv1n?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/migration-birds?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[9,678,894,701],{"slug":3704,"featured":6,"template":683},"how-to-migrate-gitlab-groups-and-projects-more-efficiently","content:en-us:blog:how-to-migrate-gitlab-groups-and-projects-more-efficiently.yml","How To Migrate Gitlab Groups And Projects More Efficiently","en-us/blog/how-to-migrate-gitlab-groups-and-projects-more-efficiently.yml","en-us/blog/how-to-migrate-gitlab-groups-and-projects-more-efficiently",{"_path":3710,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3711,"content":3717,"config":3723,"_id":3725,"_type":13,"title":3726,"_source":15,"_file":3727,"_stem":3728,"_extension":18},"/en-us/blog/how-to-optimize-gitlab-s-culture-with-proper-values",{"title":3712,"description":3713,"ogTitle":3712,"ogDescription":3713,"noIndex":6,"ogImage":3714,"ogUrl":3715,"ogSiteName":670,"ogType":671,"canonicalUrls":3715,"schema":3716},"How to Optimize GitLab’s Culture Through Ideal Values","An outside perspective on GitLab’s highly collaborative and agile culture, and ways in which they should improve their values","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681397/Blog/Hero%20Images/artem-kniaz-Z9_pOnIbgjg-unsplash__1_.jpg","https://about.gitlab.com/blog/how-to-optimize-gitlab-s-culture-with-proper-values","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to Optimize GitLab’s Culture Through Ideal Values\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan Regan\"}],\n        \"datePublished\": \"2020-07-07\",\n      }",{"title":3712,"description":3713,"authors":3718,"heroImage":3714,"date":3720,"body":3721,"category":1353,"tags":3722},[3719],"Brendan Regan","2020-07-07","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nI was immediately impressed by how unique GitLab is compared to any organization I have seen. Their culture and methodical processes were clearly evident during my brief summer internship. Sure, it’s all-remote, but that alone is not what makes it so unique. GitLab is also nimble, collaborative, and ambitious as employees communicate nearly seamlessly across the world. Like many growing organizations, it needs to refine some of its fundamental principles. \n\n## Exciting Aspects of GitLab’s Culture\n\n### Transparency\n\nGitLab states their mission is [everyone can contribute](/company/mission/#mission). By “everyone,” they mean it. Even outsiders can access GitLab’s website, propose changes to their content, and see those changes work their way through the approval process. This is a truly novel concept and affords the company input from a wider array of contributors than more traditional companies. This transparency is even mentioned in the introduction paragraph of their easily accessible [handbook](/handbook/#introduction), which is also available to everyone. \n\nGitLab boasts incredibly high levels of asynchronous communication, which requires and reinforces transparency. Asynchronous communication enables them to accomplish large tasks through a continuous process [over time](https://handbook.gitlab.com/handbook/values/#iteration), updating their products with small chunks, or “[minimum viable changes](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc).” [Meetings and meeting preparation](/company/culture/all-remote/meetings/) are also unique signals to their asynchronous culture. Participants are granted access to a shared Google doc before, during, and after meetings to promote asynchronous work and collaboratively effectively. This is an easy tactic many organizations can adopt to increase meeting productivity. Shared documents are also a fantastic method to record meeting notes and assign action items. \n\n### Initiative\n\nWhen I started my first day as an intern, I was sent a few links, told to initiate onboarding, and was given time and space to work on my own. I started working through the 401 onboarding tasks for new hires, and although many weren’t applicable to my internship, I spent much of my time on many tangential topics. While doing so, I quickly noticed that GitLab employees wield significant autonomy and are rewarded for their initiative.\n\nI have seen many organizations suffer from retaining the authority to enact change at senior levels while junior employees possess little ability to make small changes. GitLab deviates from this convention. A few days into my onboarding I noticed a few minor errors in the handbook and was able to submit a merge request to correct them. While the changes were minor spelling errors, this process cemented their culture in my mind. Take action, make the change.\n\nI was especially curious about the culture that has enabled GitLab’s recent success, especially as an all-remote company. All of GitLab’s work is documented, so I began to peruse what other people had written about their culture and strategy. I read the handbook, scheduled a coffee chat with Head of Remote, Darren Murph, to discuss culture, and stumbled upon a helpful blog that introduced me to a technique on how to increase productivity using the “[E-factor](/blog/e-factor-productivity/).” I also found an article on how to sensibly prioritize and accomplish tasks using the [Ivy Lee Method](https://jamesclear.com/ivy-lee) linked from someone’s README. I wrote this very blog post that you’re reading with the help of [a video posted on GitLab’s website](https://www.youtube.com/watch?v=Cxs5EMHNf6g) about drafting and submitting a blog post MR. All of this was made possible because of GitLab’s ambitious and transparent culture. This was all very impressive. \n \n### Forging Proper Values\n\nGitLab’s values and their effect on culture were of particular interest to me as someone with more management experience than technical expertise. After reading through their values page, it was apparent that GitLab may have significant conflicts with some of their values. \n \nTo value something does not necessarily mean it should be adopted as a company value. A high-performance thermos is of great value on a cold day, especially when it’s filled with piping hot coffee, but it is not something that should be espoused. Integrity, selflessness, and courage are also of great value, but unlike a thermos, they should also be espoused. These attributes will ensure greater success in an organization than more specific, metric-driven values like efficiency or iteration.\n\nGitLab’s [values](https://handbook.gitlab.com/handbook/values/) are designed to ensure a positive work environment and deliver world class results to their customers. The values are explicitly stated as Collaboration, Results, Efficiency, Diversity, Inclusion, and Belonging (three values in one), Iteration, and Transparency (CREDIT). \n\nI argue that these are not ideal values. These are things in which GitLab _can place value_, but they are not fundamental values to which the company should anchor their behavior. GitLab seems to have adopted values that are means, tactics, or metrics but not tenets which ought to govern their operations. \n\n### Ideal Values Are Fixed\n\nThe idea of continuous improvement is good in many applications, but bad when it comes to organizational values. GitLab adjusts their values over time to more clearly define their ideal culture. However, proper values should not need improvement over time. Organizational values must be resolute and foundational attributes espoused by all employees. They should be guiding, not malleable. They define the culture, and in turn, employees must adopt them to maintain the culture. Once established, these values must be adhered to throughout the organization, applied in new, unforeseen situations, and serve as screening criteria to ensure new hires properly assimilate into GitLab. Continuously shifting values will place GitLab at a significant disadvantage as the company expands and hires new employees based on their values fit.\n\n### Proper Values Do Not Conflict\n\nHere’s a hypothetical example of how GitLab’s values may conflict. A potential new hire would clearly contribute to GitLab’s diversity, a tightly held company value. However, the potential new hire is less qualified than another potential hire who would clearly contribute to achieving results in the best interest of the company, which is required under GitLab’s [permission to play](https://handbook.gitlab.com/handbook/values/#permission-to-play). Does GitLab hire the less-qualified individual and hope their contributions to diversity somehow outweigh their lack of positive results? Should GitLab directly pursue a diverse workforce? What about diverse opinions that are not congruent with GitLab’s values? Diversity should not be pursued for the sake of diversity, especially when it does not improve the company's results. This is only one of a myriad of conflicts that arise when values are developed from good intentions rather than ethics. \n \nLet’s take a look at values that are derived from ethics, such as duty and respect. These values are tightly related and mutually supportive. It often becomes a duty to respect others, and respect is often shown through dutiful work. A pharmacist demonstrates a duty to customers by thoroughly researching medicinal ingredients and their side effects. They also show respect to patients by reviewing potential side effects with the patient before they are prescribed the drug. \n \nIn contrast, GitLab’s values of results and efficiency can conflict quite easily. GitLab might achieve better results with a less efficient process, or vice versa. Here’s the main problem: results are not inherently good or bad. There can be good results from bad actions, and bad results from good actions. The simple pursuit of results is not enough, GitLab must pursue the correct results. But what are good results for GitLab? This question should be answered through a well-defined business strategy and internal metrics. Ethically-derived values such as duty, respect, and integrity must lay the foundation for GitLab’s business strategy. \n\nHow does GitLab address value conflicts? Through their [value hierarchy](https://handbook.gitlab.com/handbook/values/#hierarchy). As the company expands, this hierarchy exposes GitLab to potential damage as employees pursue _results_ above all other values. GitLab can avoid this dilemma by guiding their pursuit of results with ethical values instead of metrics.\n\n### The Way Ahead\n\n \n\nGitLab's processes should be continuously refined but their core values should not change. Their value statement should be simple, with clear and foundational values to unite their remote workforce. I propose GitLab adopt the values of **Respect**, **Service**, and **Integrity**. These are a start, and leadership may want to include one or two more values than the three I propose, but all current values are encompassed by these three proposed values as seen in the table below:\n\n \n\n\n\u003Ctable>\n  \u003Ctr>\n   \u003Ctd>\u003Cstrong>Current Values\u003C/strong>\n   \u003C/td>\n   \u003Ctd>\u003Cstrong>Proposed Values\u003C/strong>\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>\u003Cp style=\"text-align: left\">\nCollaboration\u003C/p>\n\n   \u003C/td>\n   \u003Ctd>Respect\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>\u003Cp style=\"text-align: left\">\nResults\u003C/p>\n\n   \u003C/td>\n   \u003Ctd>Service\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>\u003Cp style=\"text-align: left\">\nEfficiency\u003C/p>\n\n   \u003C/td>\n   \u003Ctd>Service\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>\u003Cp style=\"text-align: left\">\nDiversity, Inclusion, and Belonging\u003C/p>\n\n   \u003C/td>\n   \u003Ctd>Respect\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>\u003Cp style=\"text-align: left\">\nIteration\u003C/p>\n\n   \u003C/td>\n   \u003Ctd>Service\n   \u003C/td>\n  \u003C/tr>\n  \u003Ctr>\n   \u003Ctd>\u003Cp style=\"text-align: left\">\nTransparency\u003C/p>\n\n   \u003C/td>\n   \u003Ctd>Integrity\n   \u003C/td>\n  \u003C/tr>\n\u003C/table>\n\n\n \n\nFurthermore, these new values provide GitLab the flexibility to adjust their methods if, say, innovation becomes more important than iteration. Without changing their entire value structure and their culture, they can remain committed to Respect, Service, and Integrity while they shift their processes to reinforce innovation more effectively. Hiring employees who respect others, serve selflessly, and conduct themselves with integrity will pay great dividends for GitLab’s culture, leadership, and reputation in an uncertain future. \n\nCover image by [Artem Kniaz](https://unsplash.com/photos/Z9_pOnIbgjg) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[9,9],{"slug":3724,"featured":6,"template":683},"how-to-optimize-gitlab-s-culture-with-proper-values","content:en-us:blog:how-to-optimize-gitlab-s-culture-with-proper-values.yml","How To Optimize Gitlab S Culture With Proper Values","en-us/blog/how-to-optimize-gitlab-s-culture-with-proper-values.yml","en-us/blog/how-to-optimize-gitlab-s-culture-with-proper-values",{"_path":3730,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3731,"content":3737,"config":3743,"_id":3745,"_type":13,"title":3746,"_source":15,"_file":3747,"_stem":3748,"_extension":18},"/en-us/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets",{"title":3732,"description":3733,"ogTitle":3732,"ogDescription":3733,"noIndex":6,"ogImage":3734,"ogUrl":3735,"ogSiteName":670,"ogType":671,"canonicalUrls":3735,"schema":3736},"How to scan a full commit history to detect sensitive secrets","Use GitLab Secret Detection to scan a repository's commit history, including branches. View results within the GitLab UI with just a few lines of code added to a pipeline file.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097948/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%281%29_2XDPsbkjQ3o6tcdom6IGxI_1750097948673.png","https://about.gitlab.com/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to scan a full commit history to detect sensitive secrets\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Noah Ing\"},{\"@type\":\"Person\",\"name\":\"Jerez Solis\"}],\n        \"datePublished\": \"2025-02-06\",\n      }",{"title":3732,"description":3733,"authors":3738,"heroImage":3734,"date":3740,"body":3741,"category":704,"tags":3742},[1911,3739],"Jerez Solis","2025-02-06","Secrets left exposed in outdated repositories pose significant risk for data breaches. For example, a still-active secret key can be exposed, leaving it vulnerable to exploitation. Secrets include access keys, API tokens, private keys, and other sensitive values. \n\nIn this article, you'll learn how to use GitLab Secret Detection to scan a repository’s full commit history, including all branches, to detect sensitive secrets. In addition, you will discover how to view the results directly within the GitLab UI without the need for any integration. All it takes is just a couple of lines of code in your `.gitlab-ci.yml` pipeline file. \n\n## Scan every corner of your repository\n\nWe will use the sample repository shown in the screenshot below as an example. To keep things simple, there is only a `README.md` file present in the default branch of this repository. \n\n![Sample repository to scan](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097956/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097955851.png)\n\nAt first glance, it may seem like the repository is empty and that there are probably no sensitive secrets in this repository. But what we are looking at is only the state of the default branch, which is the main branch in this example. There could be feature branches in this repository created weeks, months, or years ago with sensitive secrets. It is also possible that a file with a secret was accidentally pushed to the repo and then deleted right after. However, it likely was not deleted correctly and is still in the commit history.\n\nWe are going to enable GitLab Secret Detection scanner and set the `SECRET_DETECTION_HISTORIC_SCAN` variable to **true** so that the content of all branches in the repository is scanned.\n\n![Enable GitLab Secret Detection variable to true](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097956/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097955853.png)\n\n```\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\nsecret_detection:\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n```\n\nBy setting the `SECRET_DETECTION_HISTORIC_SCAN` variable to **true**, GitLab Secret Detection looks into every branch and commit of your repository. It ensures that no sensitive information — whether from a feature branch or an old commit — is left unchecked.\n\n## Results of the scan\n\nTwo sensitive secrets were identified in the repository. One is a password in a `.env` file that was deleted from the repository, but the commit containing it was not removed from the git history. The other is an AWS Access Token found in a feature branch. These exposed secrets could compromise the organization’s security. \n\n![AWS Access Token screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097956/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097955855.png)\n\nYou can click on the AWS Access Token result to see more details, including the file location. You can also create a GitLab issue to triage the vulnerability with one click. If you’re using the Jira integration, you can create a Jira ticket directly from the vulnerability page as well.\n\n## Why scanning for secrets matters\n\nAnyone with access to the repository can misuse the secret to gain unauthorized access to private resources and sensitive data. \n\nIn addition to scanning a repository’s full commit history across all branches, GitLab Secret Detection also helps you take a multilayered approach to detecting secrets:\n\n* [Secret push protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/index.html) - scans commits for secrets during a push and blocks it if secrets are detected, unless skipped, reducing the risk of leaks.  \n* [Pipeline secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html) - scans files after they’ve been committed and pushed to a GitLab repository.\n* [Client-side secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/client/index.html) - scans comments and descriptions in issues and merge requests for secrets before they're saved to GitLab.  * [Automatic response to leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html) - automatically revokes certain types of leaked secrets and notifies the partner that issued the secret. \n\nYou can adjust pipeline secret detection to suit your needs by modifying, extending, or replacing the default ruleset. For instance, you can define [custom rules](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#customize-analyzer-rulesets) using regex patterns to detect sensitive data like credit card numbers, phone numbers, or other information specific to your organization.\n\n## Try GitLab Secret Detection\n\n1. [Enable](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#enable-the-analyzer) Secret Detection in your GitLab pipeline.  \n2. Set `SECRET_DETECTION_HISTORIC_SCAN: true`.  \n3. Push and trigger a pipeline to scan all branches and commits.\n\nGitLab makes securing your code simple and comprehensive. Don’t let an old branch or commit compromise your security — give historical scans a try today!\n\n> #### [Sign up for a free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/) to get started with security scanners like Secret Detection.",[1813,746,478,9],{"slug":3744,"featured":6,"template":683},"how-to-scan-a-full-commit-history-to-detect-sensitive-secrets","content:en-us:blog:how-to-scan-a-full-commit-history-to-detect-sensitive-secrets.yml","How To Scan A Full Commit History To Detect Sensitive Secrets","en-us/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets.yml","en-us/blog/how-to-scan-a-full-commit-history-to-detect-sensitive-secrets",{"_path":3750,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3751,"content":3757,"config":3762,"_id":3764,"_type":13,"title":3765,"_source":15,"_file":3766,"_stem":3767,"_extension":18},"/en-us/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes",{"title":3752,"description":3753,"ogTitle":3752,"ogDescription":3753,"noIndex":6,"ogImage":3754,"ogUrl":3755,"ogSiteName":670,"ogType":671,"canonicalUrls":3755,"schema":3756},"How to stream logs through the GitLab Dashboard for Kubernetes","In GitLab 17.2, users can now view Kubernetes pod and container logs directly via the GitLab UI. This tutorial shows how to use this new feature to simplify monitoring Kubernetes infrastructure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662245/Blog/Hero%20Images/blog-image-template-1800x945__16_.png","https://about.gitlab.com/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to stream logs through the GitLab Dashboard for Kubernetes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2024-08-19\",\n      }",{"title":3752,"description":3753,"authors":3758,"heroImage":3754,"date":3054,"body":3760,"category":849,"tags":3761},[3759],"Daniel Helfand","Developers are context-switching more frequently, needing to understand and use multiple tools to accomplish complex tasks. These tools all have different user experiences and often do not present all the information needed to successfully develop, troubleshoot, and ship critical features. It is challenging enough to release and monitor software changes without also needing to understand so many tools.\n\nWith the addition of [pod log streaming through the GitLab Dashboard for Kubernetes in v17.2](https://about.gitlab.com/releases/2024/07/18/gitlab-17-2-released/#log-streaming-for-kubernetes-pods-and-containers), developers can go straight from a merge request review to watching a deployment rolled out to Kubernetes. This new feature will:\n- allow developers to avoid switching tooling\n- ease the process of troubleshooting and monitoring deployments and post-deployment application health\n- strengthen [GitOps workflows](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html) to easily manage application and infrastructure changes\n\nThe new feature allows GitLab users to view the logs of pods and containers directly via the GitLab UI. In previous versions of GitLab, users could configure a GitLab project to view pods deployed to certain namespaces on an associated cluster. This new feature allows users to further monitor workloads running on Kubernetes without needing to switch to another tool.\n\nIn the sections below, you will learn how to use this new feature by adding a Kubernetes cluster to a GitLab project, deploying a sample workload to a cluster, and viewing the logs of this workload running on a cluster. \n\n> Need to know the basics of Kubernetes? [Read this quick introductory blog](https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution/).\n\n## Configure a GitLab project to view Kubernetes resources\n\nBefore proceeding with this section, the following prerequisites are required:\n* a remote Kubernetes cluster (i.e., not running locally on your machine)\n* access to a GitLab v17.2 account\n* [this repository](https://gitlab.com/gitlab-da/tutorials/cloud-native/gitlab-k8s-log-streaming-example) forked to a GitLab group to which you have access\n* Helm CLI\n* kubectl CLI\n\nOnce you have satisfied the prerequisites involved, add an agent configuration file to the GitLab project you forked. The configuration file allows users to control permissions around how GitLab users may interact with the associated Kubernetes cluster.\n\nYou can use the configuration file included in this GitLab project by changing the following file: `.gitlab/agents/k8s-agent/config.yaml`. Replace the `\u003CGitLab group>` in the id property shown below with the group where you have forked the example project. This config file will allow [GitLab to access your cluster via an agent](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html) that can be installed on your cluster.\n\n```yaml\nuser_access:\n  access_as:\n    agent: {}\n  projects:\n    - id: \u003CGitLab group>/gitlab-k8s-log-streaming-example\n```\n\nOnce the above file is edited, you can commit and push these changes to the main branch of the project. \n\n## Add GitLab Kubernetes agent to cluster\n\nWith the agent configuration file added, now add the cluster to GitLab by installing an agent on your cluster. In the GitLab UI, go to your project and, on the left side of the screen, select **Operate > Kubernetes clusters**. Once on this page, select the **Connect a cluster** button on the right side of the screen. From the dropdown menu, you can then select the agent, which should be `k8s-agent`. Click **Register** to get instructions for how to install the agent on your cluster.\n\nThe instructions presented to you after registering the agent will be to run a helm command that will install the GitLab agent on your cluster. Before running the command locally, you will want to ensure your Kubernetes context is targeting the cluster you want to work with. Once you have verified you are using the correct kubeconfig locally, you can run the helm command to install the agent on your cluster.\n\nOnce both pods are running, GitLab should be able to connect to the agent. Run the following command to wait for the pods to start up:\n\n```shell\nkubectl get pods -n gitlab-agent-k8s-agent -w\n```\n\n## Deploy sample application to your cluster\n\nBefore you can view logs of a workload through GitLab, you first need to have something running on your cluster. To do this, you can run the following kubectl command locally. \n\n```shell\nkubectl apply -f https://gitlab.com/gitlab-da/tutorials/cloud-native/gitlab-k8s-log-streaming-example/-/raw/main/k8s-manifests/k8s.yaml\n```\n\nAfter the command runs successfully, you are now ready to complete the final step to set up a Kubernetes dashboard via GitLab.\n\n## View pod logs through the GitLab UI\n\nTo add the Kubernetes dashboard via the GitLab UI, go to your project and, on the left side of the screen, select **Operate > Environments**. On the top right side of the screen, select the **Create an environment**.\n\nNext, you can give your environment a name, select the GitLab agent (i.e. `k8s-agent`), and pick a namespace for the Kubernetes dashboard to focus on. Since the application is running in the `gitlab-k8s-log-streaming-example-dev` namespace, select this option from the namespace dropdown. After naming the environment and selecting the agent and namespace, click **Save**.\n\nAfter creating the environment, you should now see information about the application’s pods displayed via the GitLab UI.\n\n![Kubernetes logs - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676402/Blog/Content%20Images/Screenshot_2024-08-20_at_12.15.08_PM.png)\n\nGo to the right side of the screen and click **View Logs** to see logs for one of the pods associated with the application. \n\n![Kubernetes dashboard - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676402/Blog/Content%20Images/Screenshot_2024-08-20_at_12.16.56_PM.png)\n\n## Try it out and share feedback\n\nThe introduction of pod log streaming in GitLab v17.2 will help GitLab users get one step closer to managing complex deployments to Kubernetes, as well as monitoring and troubleshooting issues post deployment via a common user experience. We are excited to hear more about users’ experiences with this new enhancement and how it helps improve DevOps workflows around Kubernetes. To share your experience with us, you can open an issue to the [project associated with this tutorial](https://gitlab.com/gitlab-da/tutorials/cloud-native/gitlab-k8s-log-streaming-example). Or, [comment directly in the Kubernetes log streaming feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/478379) to report information to the GitLab engineering team.\n\nMore information on getting started with the GitLab Dashboard for Kubernetes can be found in the documentation [here](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html).\n\n> To explore the GitLab Dashboard for Kubernetes as well as other more advanced features of GitLab, sign up for [our free 30-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n",[9,533,1936,746],{"slug":3763,"featured":90,"template":683},"how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes","content:en-us:blog:how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes.yml","How To Stream Logs Through The Gitlab Dashboard For Kubernetes","en-us/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes.yml","en-us/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes",{"_path":3769,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3770,"content":3776,"config":3782,"_id":3784,"_type":13,"title":3785,"_source":15,"_file":3786,"_stem":3787,"_extension":18},"/en-us/blog/how-to-tailor-gitlab-access-with-custom-roles",{"title":3771,"description":3772,"ogTitle":3771,"ogDescription":3772,"noIndex":6,"ogImage":3773,"ogUrl":3774,"ogSiteName":670,"ogType":671,"canonicalUrls":3774,"schema":3775},"How to tailor GitLab access with custom roles","Find out the current capabilities of custom roles and what's to come, including initial grouping of permissions and templating from default roles.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098975/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_729993502_1Xe0pzHPX4C3b1Ycs2q7RP_1750098974565.jpg","https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to tailor GitLab access with custom roles\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joe Randazzo\"},{\"@type\":\"Person\",\"name\":\"Hannah Sutor\"}],\n        \"datePublished\": \"2024-02-13\",\n      }",{"title":3771,"description":3772,"authors":3777,"heroImage":3773,"date":3779,"body":3780,"category":1513,"tags":3781},[3778,2314],"Joe Randazzo","2024-02-13","At GitLab, we knew we had a big problem to solve. Our existing, default user roles were becoming roadblocks for our customers. The default roles, such as Guest, Reporter, Developer, Maintainer, and Owner, offer a predefined set of permissions that cannot be customized. Customers were forced to fit their specific needs into the existing roles, leading to either overly permissive access, which is a security risk, or under-privileged access, which required administrator overhead to temporarily elevate privileges of a user in order to perform a task, and remember to move them back down to their normal role afterwards.\n\nIn 15.9, we released our [first iteration for customizable roles](https://about.gitlab.com/blog/expanding-guest-capabilities-in-gitlab-ultimate/) within GitLab. It allowed customers to do one simple thing: Give the Guest user the ability to view code, without consuming a seat. Our hope was to give our customers the ability to add more privilege to the Guest role, if they so desired, while retaining the benefit of free Guest users with an Ultimate subscription.\n\nOur MVC was released almost a year ago now, so we wanted to provide an update on the progress we’ve made with customizable roles and an idea of where we are headed.\n\n![Custom roles - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098994/Blog/Content%20Images/Blog/Content%20Images/create_role_output__2__aHR0cHM6_1750098994380.gif)\n\n![Custom roles - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098994/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098994380.gif)\n\n## Looking at the next iteration of custom roles\n\nAs we build toward the next iteration of [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html) and permissions, we have gathered a lot of feedback from the MVC. Two common themes that have been uncovered are:\n- reducing privilege of Developer, Maintainer, and Owner roles\n- a wide range of access permutations\n\nHere's how we plan to address these challenges.\n\n### Consistent CRUD model\n\nIf you have designed role-based access control (RBAC) in Google Cloud Platform (GCP) or Kubernetes, you may have appreciated the predictable permission verbs on resource access. As we continue to build out the next groupings of permissions for custom roles, the permissions will follow a consistent Create, Read, Update, and Delete (CRUD) model so you can predictably design your resource access within your organization.\n\nIf we examine the table below, “Manage” would be given to select few in the department or organization, whereas \"Write\" and \"View\" would be a common contributor to that resource.\n\n| Permission    | Description     |\n| ---------- | ---------- |\n| Manage       | Full CRUD operations on resources. Plus configuring the settings of the resource. *Assumes Write/View/Delete* |\n| Write       | Add or update the resource. *Assumes View*     |\n| View       | View the resource      |\n| Delete      | Delete the resource. *Assumes View*      |\n\n\u003Cp>\u003C/p>\n\nBelow is a concrete example of permissions related to registries. While this table is coarse-grained as this groups all registry types together at first, this can become fine-grained over time by pulling out each registry type as requested.\n\n\u003Cp>\u003C/p>\n\n| Permission    | Description     |\n| ---------- | ---------- |\n| Manage       | CRUD operations on objects, including Registries, Proxy, Cleanup Policies, along with managing the settings      |\n| Write       | Ability to push a container, package, or terraform module to registry    |\n| View       | Ability to view, retrieve, and pull registry objects and metadata on repositories and images      |\n| Delete      | Ability to delete registry objects and metadata      |\n\n### Remove default role dependency\n\nDuring the custom role creation process, starting with a base default role can be a quick way to add permissions, but it’s limiting when reducing only one or two permissions from Maintainer or Owner. The next iteration will allow you to build your own custom role without the predefined permissions of default roles allowing for maximum flexibility.\n\n### Build your own role\n\nBuilding a custom role in a system should account for the number of permutations while isolating access for those in strict environments. As we group these resources, we are factoring in that there are a wide range of themes including project management, development, security, and operations.\n\nBelow is a sample of [groupings](https://gitlab.com/jrandazzo/build-your-own-permissions-survey) with a permission selection that could apply to a developer. These resource groups may become finer over time based on requests.\n\n![custom roles - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098994/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098994382.png)\n\n### Building a role from a template\n\nYou may have experienced building permission sets as a starting point to simplify the assignment of user access. As you build out a custom role, you could start with a template that copies predefined permissions from a default role or specific user types such as a Project Manager.\n\n## How to contribute\n\nWe value your feedback and there are multiple ways to contribute:\n- We created a “build your own role” survey to understand how an organization would create a least privilege user in GitLab. Here is a [survey link](https://forms.gle/ucx9CNqqUbVVyAse9) to validate our initial assumptions on permission groupings.\n- Would you like to submit ideas or share feedback based on custom roles? Here is the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/439638).\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[701,704,703,9],{"slug":3783,"featured":90,"template":683},"how-to-tailor-gitlab-access-with-custom-roles","content:en-us:blog:how-to-tailor-gitlab-access-with-custom-roles.yml","How To Tailor Gitlab Access With Custom Roles","en-us/blog/how-to-tailor-gitlab-access-with-custom-roles.yml","en-us/blog/how-to-tailor-gitlab-access-with-custom-roles",{"_path":3789,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3790,"content":3796,"config":3801,"_id":3803,"_type":13,"title":3804,"_source":15,"_file":3805,"_stem":3806,"_extension":18},"/en-us/blog/how-to-use-agent-based-gitops",{"title":3791,"description":3792,"ogTitle":3791,"ogDescription":3792,"noIndex":6,"ogImage":3793,"ogUrl":3794,"ogSiteName":670,"ogType":671,"canonicalUrls":3794,"schema":3795},"How to use a pull-based (agent-based) approach for GitOps","Learn how GitLab supports agent-based approach for GitOps","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682037/Blog/Hero%20Images/agent-based-gitops-cover-880x587.jpg","https://about.gitlab.com/blog/how-to-use-agent-based-gitops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use a pull-based (agent-based) approach for GitOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2021-06-23\",\n      }",{"title":3791,"description":3792,"authors":3797,"heroImage":3793,"date":3798,"body":3799,"category":849,"tags":3800},[803],"2021-06-23","\n\nIn the previous post, titled [3 ways to approach GitOps](https://about.gitlab.com/blog/gitops-done-3-ways/), we discussed the many benefits and options that GitLab supports for fulfilling the [GitOps](/topics/gitops/) requirements of customers, whose IT environments are composed of heterogeneous technologies and infrastructures. This post is a 3-part series, in which we delve deeper into these options. In this first part, we cover the pull-based or agent-based approach.\n\n## About a pull-based or agent-based approach\n\nIn this approach, an agent is installed in your infrastructure components to pull changes whenever there is a drift from the desired configuration, which resides in GitLab. Although the infrastructure components could be anything from a physical server or router to a VM or a database, we will focus on a Kubernetes cluster in this section.\n\nIn the following example, the [reconciliation loop](https://about.gitlab.com/solutions/gitops/) is made up of two components: an agent running on the Kubernetes cluster and a server-side service running on the GitLab instance. One of the benefits of this approach is that you don’t have to expose your Kubernetes clusters outside your firewall. Another benefit is its distributed architecture, in that agents running on the infrastructure components are in charge of correcting any drift relieving the server-side from resource consumption. This approach requires the maintenance and installation of agents on all infrastructure components you want to be part of your GitOps flows.\n\n### GitLab Agent for Kubernetes as a pull-based approach\n\n[Introduced](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#introducing-the-gitlab-kubernetes-agent) as part of GitLab 13.4, the GitLab Agent for Kubernetes runs on your Kubernetes cluster and pulls changes in your infrastructure configuration from GitLab to your cluster keeping your infrastructure configuration from drifting away from its desired state.\n\nGitLab Agent for Kubernetes (the feature) is currently implemented as two components ([architecture doc](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md)):\n\n- GitLab Agent for Kubernetes (agentk program): The component that users install into their cluster.\n\n- GitLab Agent for Kubernetes Server (kas program): The server-side counterpart, that runs \"next to GitLab.\"\n\nThe high-level architecture of the GitLab Agent for Kubernetes is depicted below:\n\n![GitLab K8s agent high-level architecture](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/0-K8s-agent-arch.png){: .shadow.small.center.wrap-text}\nGitLab K8s agent high-level architecture.\n{: .note.text-center}\n\nThe **agentk** is installed on your Kubernetes cluster and it is the component that applies updates to the infrastructure. The **kas** is installed on the GitLab instance and it manages the authentication and authorization between **agentk** instances and GitLab, monitors projects for any changes and gathers latest project manifests to send to **agentk** instances.\n\n> **NOTE:** on Gitlab.com, the **kas** is installed and maintained by GitLab. On self-managed instances, the customer needs to install it.\n\nIn the following self-managed instance example, we go through a GitOps flow that leverages the pull-based approach to GitOps.  After the **agentk** component has already been installed on the K8s cluster, the user proceeds to log on to the GitLab instance and creates a project called **gitops-project**:\n\n![Creating the gitops-project](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/1-create-gitops-proj.png){: .shadow.medium.center.wrap-text}\nCreating the gitops-project.\n{: .note.text-center}\n\nThe project **gitops-project** will be the one that will be monitored or observed by the **kas** component. Then, under **gitops-project**, the user creates an empty manifest file called **manifest.yaml**. This is the manifest file that will contain the Infrastructure as Code configuration for this project:\n\n![Manifest file created](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/2-manifest-file-created.png){: .shadow.medium.center.wrap-text}\nManifest file created.\n{: .note.text-center}\n\nNext, the user creates a Kubernetes agent configuration repository project, **kubernetes-agent**, which will contain information pertinent to the **kas** component.\n\n![Creating the kubernetes-agent project](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/3-create-K8s-agent-proj.png){: .shadow.medium.center.wrap-text}\nCreating the kubernetes-agent project.\n{: .note.text-center}\n\nWithin the **kubernetes-agent** project, the user creates a subdirectory **.gitlab/agents/agent1**, where **agent1** is the name given to this specific agent:\n\n![Config.yaml file created](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/4-config-yaml-created.png){: .shadow.medium.center.wrap-text}\nConfig.yaml file created.\n{: .note.text-center}\n\nNotice that in the screenshot above, the project to be observed, **gitops-project**, was created in an earlier step.\n\nThe next step consists of the creation of a GitLab Rails Agent record to associate it with the Kubernetes agent configuration repository project. In the following screenshot, you see the commands that the user enters to first identify the task-runner pod, to log into it, to enter the Rails Console, and finally to create the agent record and a token for it:\n\n![Agent record created](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/5-agent-record-created.png){: .shadow.medium.center.wrap-text}\nAgent record created.\n{: .note.text-center}\n\nIn the above screenshot, the last command uses the agent token to create a secret on the K8s cluster for secured communication between the **agentk** and the **kas** components.\n\nThe **agentk** pod creation on the K8s cluster is the next step. For this, the user creates a **resources.yml** file, in which the secured communication protocol between the **agentk** and the **kas** is specified as shown in the following snippet:\n\n![Websockets line](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/6-wss-line-in-resources-yml.png){: .shadow.medium.center.wrap-text}\nWebSockets communication specified in the resources.yml file.\n{: .note.text-center}\n\nIn the above snippet, secured WebSockets protocol is being used. GitLab also supports gRPC.\n\nOnce the **resources.yml** file is updated with the corresponding GitLab instance information, the user proceeds to create the pod:\n\n![Agentk pod created](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/7-agentk-created.png){: .shadow.medium.center.wrap-text}\nCreation of the **agentk** pod.\n{: .note.text-center}\n\nIn the screenshot above, you can see the execution of the **kubectl apply** that created the **agentk** pod in the K8s cluster.\n\nNow that the **agentk** and **kas** have been installed and are communicating securely with each other, the user can start performing some GitOps flows. Although the [GitLab Flow](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/) is the recommended approach for DevOps, it is also applicable to GitOps flows; after all GitOps is all about applying the goodness of DevOps to managing [Infrastructure as Code](/topics/gitops/infrastructure-as-code/).\n\nThis means that the user should create an issue and then a merge request, in which all stakeholders can collaborate towards the resolution of the issue. For the sake of brevity, in this technical blog post, we will skip all these steps and show you how updates to the Infrastructure as Code configuration files are automatically applied to the infrastructure components.\n\nNOTE: Fostering Collaboration is a great benefit of GitOps. For more information on this, check out this short [tech video](https://youtu.be/onFpj_wvbLM).\n\nFor example, the user can start making updates to the **manifest.yaml** file under the **gitops-project**, which is being observed by the kas component. Here you can see the user has pasted content into this file:\n\n![Manifest.yaml file updated](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/8-manifest-yaml-updated.png){: .shadow.medium.center.wrap-text}\nManifest.yaml file updated.\n{: .note.text-center}\n\nRemember that this file had been created as an empty file. As soon as the user commits the changes displayed above, the **kas** component will detect the changes and communicate these to the **agentk** component, which is running on the K8s cluster. The **agentk** will immediately apply these changes to the infrastructure. In this example, the user has updated the infrastructure configuration file to have 2 instances of an nginx. As shown in the screenshot below, the **agentk** has applied these updates by the instantiation of 2 nginx pods in the K8s cluster:\n\n![Two nginx pods up and running](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/9-two-nginx-running.png){: .shadow.medium.center.wrap-text}\nGitOps flow instantiates two nginx pods.\n{: .note.text-center}\n\nIf the user were to change the **manifest.yaml** file one more time and increment the replicas of the nginx pod to 3:\n\n![Manifest.yaml file updated with 3 nginx](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/10-manifest-yaml-updated-again.png){: .shadow.medium.center.wrap-text}\nManifest.yaml file updated with 3 nginx instances.\n{: .note.text-center}\n\nAgain, as soon as the commit takes place, the **kas** component detects the update and communicates this to the **agentk** component, which in turn, spins up a third nginx pod in the K8s cluster:\n\n![Three nginx pods up and running](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/11-three-nginx-running.png){: .shadow.medium.center.wrap-text}\nGitOps flow instantiates a third nginx pod.\n{: .note.text-center}\n\nLastly, the user can check the log files of the different components running on GKE, in this example. In the following screenshot, the user can see the **kas** component running on the GitLab instance:\n\n![kas running on GKE](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/12-kas-on-GKE.png){: .shadow.medium.center.wrap-text}\nThe **kas** component running on GKE.\n{: .note.text-center}\n\nAnd then the user can drill down into the log of the **kas** component, and see how it is detecting commits on the project it is observing:\n\n![kas log on GKE](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/13-kas-log-on-GKE.png){: .shadow.medium.center.wrap-text}\nThe **kas** log output on GKE.\n{: .note.text-center}\n\nLikewise, the user can navigate to the **agentk** component of the K8s cluster:\n\n![agentk running on GKE](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/14-agentk-on-GitLab.png){: .shadow.medium.center.wrap-text}\nThe **agentk** component running on GKE.\n{: .note.text-center}\n\nAnd, again drill down to its log to see, how the **agentk** component runs synchronizations with the **kas** component:\n\n![agentk log on GKE](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/15-agentk-log-top-on-GitLab.png){: .shadow.medium.center.wrap-text}\nThe **agentk** log output on GKE.\n{: .note.text-center}\n\nIn the following screenshot, the user sees the log statements indicating that the **agentk** is instantiating a third instance of an nginx pod:\n\n![agentk instantiating a third nginx pod](https://about.gitlab.com/images/blogimages/how-to-use-agent-based-gitops/16-agentk-log-synced-on-GitLab.png){: .shadow.medium.center.wrap-text}\nThe **agentk** instantiating a third nginx pod.\n{: .note.text-center}\n\nThe above sections described an example of the setup needed to install and run the GitLab Agent for Kubernetes as well as how projects are monitored and synchronized from GitLab to a running K8s cluster.\n\n## Conclusion\n\nWe have gone over the setup and use of the Agent, which is an integral part of our pull-based or agent-based approach to GitOps. We also covered a GitOps flow that leveraged this agent-based approach, which is a good choice for Kubernetes shops that need to keep their clusters secured and behind their firewall. This approach comes with its drawbacks in that you need to maintain the agents, which also consume the resources of your infrastructure components. In part two of this series, we will discuss the push-based or agentless approach to GitOps.\n\nCover image by [Vincent Ledvina](https://unsplash.com/@vincentledvina?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/grand-tetons?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[533,9,1396,851,976],{"slug":3802,"featured":6,"template":683},"how-to-use-agent-based-gitops","content:en-us:blog:how-to-use-agent-based-gitops.yml","How To Use Agent Based Gitops","en-us/blog/how-to-use-agent-based-gitops.yml","en-us/blog/how-to-use-agent-based-gitops",{"_path":3808,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3809,"content":3815,"config":3820,"_id":3822,"_type":13,"title":3823,"_source":15,"_file":3824,"_stem":3825,"_extension":18},"/en-us/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":3810,"description":3811,"ogTitle":3810,"ogDescription":3811,"noIndex":6,"ogImage":3812,"ogUrl":3813,"ogSiteName":670,"ogType":671,"canonicalUrls":3813,"schema":3814},"How to use GitLab's Custom Compliance Frameworks in your DevSecOps environment","Explore how new frameworks, along with more than 50 out-of-the-box controls, transform regulatory requirements from burdensome checkboxes to integrated, automated workflow components.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use GitLab's Custom Compliance Frameworks in your DevSecOps environment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }",{"title":3810,"description":3811,"authors":3816,"heroImage":3812,"date":3817,"body":3818,"category":704,"tags":3819},[2234],"2025-04-30","Compliance isn't just a checkbox — it's a critical business function that affects everything from operational risk to customer trust. For development teams, balancing compliance requirements with velocity can be particularly challenging. GitLab's [Custom Compliance Frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) offer a powerful way to integrate compliance verification directly into your development workflow. In this article you'll learn what they are and how to use them for maximum efficiecy.\n\n## What are GitLab Custom Compliance Frameworks?\n\nGitLab Custom Compliance Frameworks allow organizations to define, implement, and enforce compliance standards directly within their GitLab instance. This feature extends GitLab's built-in compliance capabilities by enabling teams to create customized frameworks that align with specific regulatory requirements, internal policies, or industry standards.\n\nCustom Compliance Frameworks have the following benefits:\n* Reduce manual tracking  \n* Accelerate audit readiness  \n* Enforce compliance controls natively\n\n![Compliance center screenshot with frameworks listed](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nWith this release, more than 50 out-of-the-box (OOTB) controls are provided (with more coming soon) that can be tailored to your organization's unique compliance needs, including HIPAA in healthcare, GDPR for data privacy, SOC2 for service organizations, or industry-specific regulations. Some examples of OOTB controls include:\n\n* Separation of duties (e.g., at least two approvers and author approved merge request)  \n* Security scanners running (e.g., [SAST](https://docs.gitlab.com/user/application_security/sast/) running and [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) running)  \n* Authentication/authorization (e.g., project visibility not public and AuthSSO required)  \n* Application configuration (e.g., status checks required and Terraform required)\n\nAdditionally, you can configure external environmental controls using the GitLab API to check the status and details of an external environment.\n\n## Creating a Custom Compliance Framework from scratch\n\nNow that we understand the value, let's explore how to implement Custom Compliance Frameworks in your GitLab environment. We will use this demo application and you can follow along in this video. \n\n**Note:** A GitLab Ultimate subscription is required.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Step 1: Define your compliance requirements**\n\nBefore building your custom framework, you need to clearly define your compliance requirements:\n\n1. **Identify applicable regulations:** Determine which regulations and standards apply to your organization (e.g., GDPR, PCI DSS, and HIPAA). \n2. **Map requirements to controls:** Break down each regulation into specific, actionable controls.  \n3. **Prioritize requirements:** Focus on high-risk areas and requirements with the greatest impact.\n\n**Step 2: Create your Custom Compliance Framework**\n\nTo create a custom compliance framework in GitLab:\n\n1. Navigate to your GitLab group's **Secure > Compliance Center** section.  \n2. Press the **New framework** button.  \n3. Select **Create blank framework**.\n\n![Create a custom compliance framework screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Provide a name, description, and color for your framework.\n\n![New compliance framework screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Add a requirement to the framework:  \n   a. Scroll down to the **Requirements** tab.\n\n   b. Press the **New requirement** button.\n\n   c. Provide a name and description.  \n   d. Under the **Controls** section, select **Choose a GitLab control**.  \n   e. Select a control from the list (e.g., at least two approvals, SAST running).  \n   f. Press the **Create requirement** button.\n\n![Create new requirement button](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Press the **Create framework** button.\n\nThe framework will be created as specified and will now be available to add to projects. Additionally, compliance frameworks can be [imported](http://TODO) using a JSON with the appropriate schema.\n\n**Step 3: Apply the framework to projects**\n\nOnce your framework is created:\n1. From the Compliance Center, select the **Projects** tab.  \n2. Use the search bar to **Search** or **Filter** results.  \n3. Select the project(s) you wish to apply your framework to.  \n4. Press the **Choose one bulk action** button.  \n5. Select **Apply frameworks to selected projects**.  \n6. Press the **Select frameworks** button.  \n7. Select your framework(s) from the list.  \n8. Press the **Apply** button.\n\n![Compliance center screen with SOC 2 framework dropdown](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nThe framework will now be applied to the project, making its requirements visible and trackable.\n\n**Step 4: Monitor and report on compliance**\n\nWith your framework in place, you can now:\n\n1. Use the **Compliance Center** to track compliance status across projects including details and suggested fixes for failed controls.\n2. Generate **compliance reports** for audits and stakeholder reviews.  \n3. Set up **compliance alerts** to notify stakeholders of potential compliance issues. \n4. Review **audit events** to overview action taken on compliance settings.\n\n![Compliance Center screen showing SOC2 test framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Real-world example: Implement a SOC2 compliance framework\n\nSystem and Organization Controls 2, better known as SOC2, is a rigorous auditing standard developed by the American Institute of Certified Public Accountants that assesses a service organization's controls related to security, availability, processing integrity, confidentiality, and privacy. You can read my [Guide to fulfilling SOC 2 security requirements with GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/) to learn more.\n\nNow, let's review a practical example of using a Custom Compliance Framework to verify SOC2 security compliance, which requires:\n\n* implementation of controls to protect against unauthorized access  \n* establishment of procedures for identifying and mitigating risks  \n* setting up systems for detecting and addressing security incidents\n\n**Disclaimer:** This is only an example showcasing some of the controls possible for adhering to SOC2. Be sure to consult with your security/compliance team before moving any implementation to production.\n\nA Custom Compliance Framework for SOC2 will look as follows using some GitLab OOTB controls:\n\n* **Name:** SOC2 Security Requirements  \n* **Description:** Adds the security requirements for SOC2 framework compliance  \n* **Requirements:**  \n  * **Implement controls to protect against unauthorized access**  \n    * Auth SSO enabled  \n    * CI/CD job token scope enabled  \n    * Require MFA at org level  \n  * **Establish procedures for identifying and mitigating risks**  \n    * At least two approvals  \n    * Author approved merge request  \n    * Committers approved merge request  \n    * Default branch protected  \n  * **Setting up systems for detecting and addressing security incidents**  \n    * Dependency Scanning running  \n    * SAST running  \n    * DAST running\n\nWhen applied to your project(s), this framework allows you to oversee if/and when they fall out of compliance and what can be done to bring them back into compliance. Note that you can create and apply multiple compliance frameworks to a project(s). For example, you can have one for SOC2 process integrity requirements.\n\n## Implement security policies to ensure compliance requirements are met\n\nAlthough not required, security policies can be applied to projects containing a Custom Compliance Framework. This allows you to assure that certain compliance criteria will be enforced via security policies. For example, you can force security scanners to run on projects that contain a Custom Compliance Framework requiring security scanning. \n\nGitLab provides various different security policies:\n\n* [Scan execution policy](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/): Enforces security scans, either as part of the pipeline or on a specified schedule.  \n* [Merge request approval policy](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/): Enforces project-level settings and approval rules based on scan results.  \n* [Pipeline execution policy](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/): Enforces CI/CD jobs as part of project pipelines. \n* [Vulnerability management policy](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/): Automatically resolves vulnerabilities that are no longer detected in the default branch.\n\nLet’s go ahead and force a SAST scanner to run in order to automatically adhere to any requirements that require SAST scanning. To create a security policy and apply it to a project with a particular framework:\n\n1. Navigate to a project that has a Custom Compliance Framework requiring **SAST scanning**. \n2. In the sidebar, select **Secure > Policies**.  \n3. Press the **New policy** button.  \n4. Under **Scan execution policy**, press the **Select policy** button. \n5. Fill in the **Name** and **Description**. \n6. Under **Actions**, select **SAST** as the scan to run.\n\n![Actions screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Under **Conditions**, select the pipeline to be triggered when a pipeline runs for all branches.\n\n![Conditions screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Press the **Configure with a merge request** button.  \n9. An MR is now created in a separate project containing all the security policies scoped to this project.\n10. Press the **Merge** button.\n\nNow SAST will run for every branch, assuring you are compliant in that area. Be sure to review all the different types of security policies and see how they can suit your requirements.\n\n## 5 best practices to follow\n\nTo maximize the value of Custom Compliance Frameworks:\n\n1. **Start small:** Begin with one critical regulation or standard before expanding.  \n2. **Involve key stakeholders:** Include compliance, security, and development teams in framework creation.  \n3. **Automate where possible:** Use GitLab CI/CD to automate compliance checks.  \n4. **Document thoroughly:** Maintain clear documentation of how your framework maps to regulatory requirements.  \n5. **Review regularly:** Update your frameworks as regulations evolve or new requirements emerge.\n\n## Get started today\n\nGitLab Custom Compliance Frameworks represent a significant advancement in DevSecOps by bringing compliance directly into the development workflow. By implementing custom frameworks, organizations can reduce compliance overhead, improve risk management, and accelerate development cycles while maintaining robust compliance with regulatory requirements.\n\nThe ability to define and enforce Custom Compliance Frameworks gives teams the flexibility they need to address their specific regulatory landscape while providing the structure necessary to ensure consistent compliance practices across the organization.\n\nAs regulatory requirements continue to grow in complexity, tools like GitLab Custom Compliance Frameworks will become increasingly essential for organizations looking to balance compliance requirements with development velocity in a sustainable way.\n\n> To try Custom Compliance Frameworks today, sign up for your [free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n\n## Learn more\n\nVisit these resources to learn more about Custom Compliance Frameworks and how they can benefit your organization:\n\n* [Custom Compliance Frameworks documentation](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)  \n* [Custom Compliance Frameworks epic](https://gitlab.com/groups/gitlab-org/-/epics/13295)  \n* [Security Policies documentation](https://docs.gitlab.com/user/application_security/policies/)  \n* [GitLab Security and Compliance solutions](https://about.gitlab.com/solutions/security-compliance/)",[704,746,478,9,701],{"slug":3821,"featured":90,"template":683},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","content:en-us:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","en-us/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","en-us/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"_path":3827,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3828,"content":3834,"config":3840,"_id":3842,"_type":13,"title":3843,"_source":15,"_file":3844,"_stem":3845,"_extension":18},"/en-us/blog/how-visualization-improves-the-gitlab-merge-train-experience",{"title":3829,"description":3830,"ogTitle":3829,"ogDescription":3830,"noIndex":6,"ogImage":3831,"ogUrl":3832,"ogSiteName":670,"ogType":671,"canonicalUrls":3832,"schema":3833},"How visualization improves the GitLab merge train experience","Merge train visualization lets users closely track merge train activities and take actions with a better understanding of the impact on other MRs in the queue.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098825/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2824%29_1KuzZLH1aSgBZsGVXGPIjf_1750098824773.png","https://about.gitlab.com/blog/how-visualization-improves-the-gitlab-merge-train-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How visualization improves the GitLab merge train experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Payton Burdette\"},{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2024-07-25\",\n      }",{"title":3829,"description":3830,"authors":3835,"heroImage":3831,"date":3837,"body":3838,"category":701,"tags":3839},[3836,1869],"Payton Burdette","2024-07-25","GitLab's merge train feature on the DevSecOps platform has worked wonders for organizations looking for a solution to automatically manage conflicts among different merge requests that are merged in close proximity to each other. [Merge trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) support all merge methods and ensure all MRs work together, which saves time and reduces the stress of breaking the default branch, especially for teams dealing with long build times or a small fleet of runners. Merge trains also alleviate some of the burden on developers who have to track the progress of other MRs before pushing the \"Merge\" button.\n\nDespite the benefits of a merge train, without having a UI to visualize its inner workings, users find it hard to trust the process. Sometimes it is difficult to distinguish failures caused by user actions from those due to flaky runs. \n\nMoreover, the lack of visibility into what else is queued before or after a particular MR has made users less confident when taking actions such as merging immediately or removing MRs from the merge train.\n\nTo address this gap in user experience, we are introducing merge train visualization in GitLab (Premium and Ultimate tiers) for better visibility into and tracking of the merge train queue.\n\n## Merge train visualization\n\nBased on findings from user research and feedback, we have defined a set of requirements for the first iteration of this feature. Here’s what you can expect.\n\n### View merge trains\n\nCurrently, when a merge request is added to the train, a link to the merge train details page is surfaced on the pipeline widget.\n\n![Merge train running](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098833102.png)\n\n### View list of MRs queued in a train\n\nWith the new merge train visualization, users can see a list of all MRs queued in the train. This transparency helps developers understand the order of merges and anticipate potential conflicts or issues. Knowing what is queued provides clarity and allows for better planning and coordination among team members.\n\n![List of MRs queued in the train](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098833102.png)\n\n### View list of MRs already merged by the train\n\nIn addition to seeing what is queued, users can also view a list of MRs that have already been successfully merged by the train. This historical context is valuable for tracking progress and understanding the sequence of changes that have been integrated into the default branch.\n\n![List of merged MRs in the train](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098833104.png)\n\n### Remove a merge request from the train straight from visualization\nThe new visualization also enables quick actions. The first action implemented is removing an MR from the merge train. This streamlined workflow reduces the time and effort required to manage merge trains, making it easier to respond to issues as they arise and maintain a smooth CI/CD pipeline.\n\n![Remove a merge request screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098833/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098833107.png)\n\n## The benefits of merge train visualization\n\nMerge train visualization has the following benefits: \n\n1. Enhanced transparency and trust\n- By visualizing the merge train, GitLab provides users with the transparency they need to trust the system. Understanding what is happening within the merge train reduces uncertainty and builds confidence in the automated process.\n2. Improved efficiency and collaboration\n- Teams can work more efficiently by having a clear view of the merge train. Developers can better coordinate their efforts, avoid redundant work, and quickly address issues. This collaborative approach ensures smoother and faster integration of changes.\n3. Reduced risk of failures\n- With visibility into the merge train, users can identify and address potential conflicts or failures early. This proactive approach minimizes the risk of breaking the default branch, leading to more stable and reliable builds.\n\n## What’s next?\n\nAs we learn more about how users interact with the merge train visualization, we intend to [add more capabilities](https://gitlab.com/gitlab-org/gitlab/-/issues/277391/designs/mr-visualization-as-a-list.png) to the list view. Early ideas include displaying estimated time to merge, ability to re-order, and displaying removed merge requests from the train. If you have ideas that you want to share, don’t forget to leave a comment on [our feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/464774).\n\nWe believe that the merge train visualization will significantly enhance the user experience for developers using GitLab. By providing a clear and actionable view of the merge train, we aim to make the merge process more transparent, efficient, and reliable.\n\n> Sign up for a [free 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial) to test-drive merge train visualization.\n",[108,9,701],{"slug":3841,"featured":90,"template":683},"how-visualization-improves-the-gitlab-merge-train-experience","content:en-us:blog:how-visualization-improves-the-gitlab-merge-train-experience.yml","How Visualization Improves The Gitlab Merge Train Experience","en-us/blog/how-visualization-improves-the-gitlab-merge-train-experience.yml","en-us/blog/how-visualization-improves-the-gitlab-merge-train-experience",{"_path":3847,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3848,"content":3854,"config":3860,"_id":3862,"_type":13,"title":3863,"_source":15,"_file":3864,"_stem":3865,"_extension":18},"/en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"title":3849,"description":3850,"ogTitle":3849,"ogDescription":3850,"noIndex":6,"ogImage":3851,"ogUrl":3852,"ogSiteName":670,"ogType":671,"canonicalUrls":3852,"schema":3853},"How we are closing the gap on replicating *everything* in GitLab Geo","Developing an internal framework to enable other teams to add Geo support for their features","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669673/Blog/Hero%20Images/engineering.png","https://about.gitlab.com/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we are closing the gap on replicating *everything* in GitLab Geo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Kozono\"}],\n        \"datePublished\": \"2021-04-29\",\n      }",{"title":3849,"description":3850,"authors":3855,"heroImage":3851,"date":3857,"body":3858,"category":1353,"tags":3859},[3856],"Michael Kozono","2021-04-29","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn early 2020, it took 3.5 months of solid work to implement replication of a new data type in Geo. One year later, support can be added within a month -- including development and all required reviews. How did we do it? First, let me introduce you to Geo.\n\n## What is Geo?\n\n[GitLab Geo](https://about.gitlab.comhttps://docs.gitlab.com/ee/administration/geo/index.html) is the solution for widely distributed development teams and for providing a warm-standby as part of a disaster recovery strategy. Geo replicates your GitLab instance to one or more local, read-only instances.\n\n## What are data types?\n\n[GitLab Geo was released in June 2016 with GitLab 8.9](https://about.gitlab.com/releases/2016/06/22/gitlab-8-9-released/#gitlab-geo-new-product) with the ability to replicate project repositories to a read-only secondary GitLab site. Developers located near secondary sites could fetch project repositories as quickly as if they were near the primary.\n\nBut what about wiki repositories? What about LFS objects or CI job artifacts? In GitLab, each of these things is represented by different Ruby classes, database tables, and storage configurations. In Geo, we call these data types.\n\n## Is it really that hard to copy data?\n\nWhen we say a new data type is supported by Geo, this is what we mean:\n\n* Backfill existing data to Geo secondary sites\n* As fast as possible, replicate new or updated data to Geo secondary sites\n* As fast as possible, replicate deletions to Geo secondary sites\n* Retry replication if it fails, for example due to a transient network failure\n* Eventually recover missing or inconsistent data, for example if Sidekiq jobs are lost, or if infrastructure fails\n* Exclude data according to [selective sync settings](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) on each Geo secondary site\n* Exclude remote stored data unless [Allow this secondary node to replicate content on Object Storage](https://docs.gitlab.com/ee/administration/geo/replication/object_storage.html#enabling-gitlab-managed-object-storage-replication) is enabled on a Geo secondary site\n* Verify data integrity against the primary data, after replication\n* Re-verify data integrity at regular intervals\n* Report metrics to Prometheus\n* Report metrics in the Admin UI\n* View replication and verification status of any individual record in the Admin UI\n* Replication and verification job concurrency is configurable in Admin UI\n* Retry replication if data mismatch is detected ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/301244))\n* Allow manual re-replication and re-verification in the Admin UI ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/216100))\n* And more\n\n## How to iterate yourself into a problem\n\n[Iteration is a core value](https://handbook.gitlab.com/handbook/values/#iteration) at GitLab. In the case of Geo, by [GitLab 12.3](https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#geo-natively-supports-docker-registry-replication) we had added replication support for the most important data types, for example:\n\n* Project Git repositories\n* Project wiki Git repositories\n* Issue/MR/Epic attachments\n* LFS objects\n* CI job artifacts\n* Container/Docker registry\n\nAnd we had added a slew of features around these data types. But suddenly it was clear we had a problem. **We were falling behind in the race to replicate and verify all of GitLab's data.**\n\n* A new data type was being added by other teams, every few months. It was painful to prioritize 3 months of development time only to add replication to one data type. And even if we caught up, the latest features would always be unsupported by Geo for 3 months.\n* Automatic verification of Project and Wiki repositories was implemented, but adding it to a single data type was going to take 3 months.\n* Maintenance and other new features were increasing in effort due to the amount of code duplication.\n* Our event architecture needed too much boilerplate and overhead to add new events\n\n## How to iterate yourself out of a problem\n\nJust because it's possible to iterate yourself into a problem doesn't mean iteration failed you. Yes, ideally we would have seen this coming earlier. But consider that fast and small iteration has likely saved many hours of upfront work on features that have been quickly validated, and have since been changed or removed. It's also possible to [DRY up](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) code too soon into bad abstractions, which can be painful to tear apart.\n\nBut we reached a point where everyone agreed that the most efficient way forward required consolidating existing code.\n\n### Do the design work\n\n[Fabian](https://gitlab.com/fzimmer), our esteemed product manager, [proposed an epic](https://gitlab.com/groups/gitlab-org/-/epics/2161):\n\n> to build a new geo replication and verification framework with the explicit goal of enabling teams across GitLab to add new data types in a way that supports geo replication out of the box\n\nMost of the logic listed above in [Is it really that hard to copy data?](#is-it-really-that-hard-to-copy-data) is exactly the same for all data types. An internal framework could be used to significantly reduce duplication, which could deliver huge benefits:\n\n* Bugs in the framework only have to be fixed once, increasing reliability and maintainability.\n* New features could be added to the framework for all data types at once, increasing velocity and consistency.\n* Implementation details would be better hidden. Changes outside the framework become safer and easier.\n\nThe proposal went further than making it easy for *ourselves* to add Geo support to new data types. The goal was to make it easy for *non-Geo engineers* to do so. To achieve this goal, the framework must be easy to use, easy to understand, and well-documented. Besides the usual benefits of reducing duplication, this higher standard would help:\n\n* Minimize the effort to implement Geo support of new features, whether it's done by a Geo engineer or not.\n* Minimize lag time to add Geo support. If it's easy to do, and anyone can do it, then it's easy to prioritize.\n* Increase awareness in other teams that new features may require Geo support.\n* Influence the planning of new features. There are ways to make it more difficult to add Geo support. This is much easier to avoid during initial planning.\n\nAs a first step, Fabian [proposed creating a proof of concept of a framework](https://gitlab.com/gitlab-org/gitlab/-/issues/35540) leveraging lessons learned and incorporating improvements we already wanted to make to the existing architecture. The issue stimulated lots of design discussion in the team, as well as multiple POCs riffing off one another.\n\nThe biggest change was the introduction of a `Replicator` class which could be subclassed for every data type. The subclasses would contain the vast majority of the specifics to each data type.\n\nIn order to further reduce duplication, we also introduced the concept of a `Replicator strategy`. Most data types in GitLab could be categorized as blobs (simple files) or Git repositories. Within these categories, there was relatively little logic that needed to be specific to each data type. So we could encapsulate the logic specific to these categories in strategies.\n\nAnother significant decision was to make the event system more flexible and lightweight. We wanted to be able to quickly implement new kinds of events for a `Replicator`. We decided to do this without rewriting the entire event processing layer, by packaging and transmitting `Replicator` events within a single, generic event leveraging the existing heavyweight event system. We could then leave the old system behind, and after migrating all data types to the framework, we could easily replace it.\n\nOnce a vision is chosen, it can be difficult to see how to get there with small iterations. But there are often many ways to go about it.\n\n### Code\n\n#### High-level approach\n\nAt a high-level, we could have achieved our goal by taking two data types that were already supported, DRYing up their code, and refactoring toward the desired architecture. This is a proven, safe, and effective method.\n\nBut to me it felt more palatable overall to deliver customer value along the way, by adding support for a brand-new data type while developing the reusable framework. We already had practice implementing many data types, so there was little risk that we would, for example, take too long or use suboptimal abstractions. So we decided to do this with [Package registry](https://docs.gitlab.com/ee/user/packages/).\n\n#### Lay the foundation\n\nOur POCs already answered the biggest open questions about the shape of the architecture. The next step was to get enough of a skeleton merged, as quickly as possible, so that we could unlock further parallel work. To ensure correctness, we aimed to get something working end-to-end. We decided to implement \"replication of newly created Package files\". Much was left out, for example:\n\n* Replication of changes. (Most Blob types, including Package files, are immutable anyway)\n* Replication of deletes\n* Backfill of existing files\n* Verification was left out entirely from the scope of the first epic, since we already knew replication alone provides most of the value to users.\n\nSince the work still required many specific design decisions, we decided to [pair program](https://en.wikipedia.org/wiki/Pair_programming). [Gabriel Mazetto](https://gitlab.com/brodock) and I used [Zoom](https://zoom.us/) and [Visual Studio Live Share](https://visualstudio.microsoft.com/services/live-share/), which worked well for us, though there are many options available. [See a recording of our first call](https://www.youtube.com/watch?v=2XedCiU634s).\n\n[The spike](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23447) was merged and we thought ourselves safe under the feature flag. Looking back on this particular merge request, we did make a couple mistakes:\n\n1. An [autoloading bug was discovered](https://gitlab.com/gitlab-org/gitlab/-/issues/202044). The merge request was reverted, fixed, and remerged. Thanks to [CI](https://docs.gitlab.com/ee/ci/) and end-to-end QA tests using actual builds, the impact was limited.\n1. The size of the spike was unnecessarily large and difficult to review for a single merge request. As it grew, we should have used it as a \"reference\" merge request from which we could break out smaller merge requests. Since then, GitLab policies have further emphasized [smaller iterations](https://about.gitlab.com/handbook/product/product-principles/#iteration).\n\n#### Build on the foundation\n\nWith the skeleton of the framework in the main branch, we could implement multiple features without excessive conflicts or coordination. The feature flag was enabled on [GitLab's staging environment](https://about.gitlab.com/handbook/engineering/development/enablement/systems/geo/staging.html), and each additional slice of functionality was tested as it was merged. And new issues for bugs and missing features were opened.\n\nWe built up the [developer documentation](https://docs.gitlab.com/ee/development/geo/framework.html) as we went along. In particular, we documented specific instructions to implement a new data type, aimed at developers with no prior knowledge of Geo. These instructions have since been moved to issue templates. For example, [this is the template for adding support to a new Git repository type](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Geo%20Replicate%20a%20new%20Git%20repository%20type.md). This caught a lot of would-be pain points for users of the framework.\n\nFinally, we released [Geo supports replicating GitLab Package Registries in GitLab 13.2](https://about.gitlab.com/releases/2020/07/22/gitlab-13-2-released/#geo-supports-replicating-gitlab-package-registries)!\n\n## Reaping the benefits\n\nFollowing the release of Geo support for Package Registries, we added support for many new data types in quick succession. Automatic verification was added to the framework. This recently culminated in a non-Geo engineer implementing replication *and verification* for a new data type, within one month!\n\n* In GitLab 13.5, [Geo replicates external merge request diffs and Terraform state files](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#geo-replicates-external-merge-request-diffs-and-terraform-state-files). These were added by Geo engineers who had been less involved in building the framework. Many refinements to the framework, and especially to the documentation, came out of this.\n* In GitLab 13.7, [Geo supports replicating Versioned Snippets](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#geo-supports-replicating-versioned-snippets). This was also added by a Geo engineer, and it was the first Git repository type in the framework, so it required more work than adding new Blob types.\n* In GitLab 13.10:\n  * [Geo supports replicating Group wikis](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-supports-replicating-group-wikis) was implemented by a non-Geo engineer.\n  * [Geo verifies replicated package files](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-verifies-replicated-package-files). This was a big new feature in the framework, adding automatic verification to any data type that can be checksummed.\n* GitLab 13.11:\n  * [Geo supports Pipeline Artifacts](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-supports-pipeline-artifacts) was implemented by a non-Geo engineer.\n  * [Geo verifies replicated Versioned Snippets](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-verifies-replicated-versioned-snippets).\n* GitLab 13.12:\n  * [An already supported data type, LFS objects, is migrated to the framework under feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/276696). Following this will be the migration of \"Uploads\" and \"CI Job artifacts\", and then **deleting thousands of lines of code**. This should improve both reliability and velocity, for example, verification will be added to these data types.\n\nIn aggregate:\n\n* In GitLab 12.9, we replicated ~56% of all data types (13 out of 23 in total) and verified ~22%.\n* In GitLab 13.11, we replicate ~86% of all data types (25 out of 29 in total) and verify ~45%.\n* **In the last year, GitLab released six new features that needed Geo support. We replicate 100% of those new features and verify ~57%.**\n\n## What did it cost?\n\nFor comparison, it took around 3.5 months to [implement replication of Design repositories](https://gitlab.com/groups/gitlab-org/-/epics/1633). It took around 6 months to [implement the framework for replication of Package files](https://gitlab.com/groups/gitlab-org/-/epics/2346). So the cost to produce the framework for replication was roughly 2.5 months of work.\n\nWe don't really have a comparable for [implementation of verification](https://gitlab.com/groups/gitlab-org/-/epics/1817), but it looked like it would take about 3 months to implement for a single data type, while it took about 4 months total to implement for Package files and simultaneously add to the framework, for a cost of about 1 month.\n\nGiven that new data types now take about 1 month to implement replication *and verification*, the work to produce the framework **paid for itself with the implementation of a single data type**. All the rest of the benefits and time saved are more icing on the cake.\n\nMy only regret is that we should have done it sooner. I intend to be more cognizant of this kind of opportunity in the future.\n\n## What to expect in the future\n\n* [Already supported data types will be migrated into the framework](https://gitlab.com/groups/gitlab-org/-/epics/3588)\n* New features will be added more quickly, for example, verification will be rolled out for all [Blob](https://gitlab.com/groups/gitlab-org/-/epics/5285) and [Git repository](https://gitlab.com/groups/gitlab-org/-/epics/5286) data types\n* Duplication will be further reduced, for example, by [leveraging Rails generators](https://gitlab.com/gitlab-org/gitlab/-/issues/326842)\n\nHuge thanks to everyone who contributed to closing the gap on replicating *everything* in Geo!\n",[1164,829,3138,9,680,998,894],{"slug":3861,"featured":6,"template":683},"how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","content:en-us:blog:how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","How We Are Closing The Gap On Replicating Everything In Gitlab Geo","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"_path":3867,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3868,"content":3874,"config":3879,"_id":3881,"_type":13,"title":3882,"_source":15,"_file":3883,"_stem":3884,"_extension":18},"/en-us/blog/how-we-built-gitlab-geo",{"title":3869,"description":3870,"ogTitle":3869,"ogDescription":3870,"noIndex":6,"ogImage":3871,"ogUrl":3872,"ogSiteName":670,"ogType":671,"canonicalUrls":3872,"schema":3873},"How we built GitLab Geo","Take a deep dive into the many architectural decisions we made while building GitLab Geo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678985/Blog/Hero%20Images/how-we-built-geo-cover.jpg","https://about.gitlab.com/blog/how-we-built-gitlab-geo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we built GitLab Geo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gabriel Mazetto\"}],\n        \"datePublished\": \"2018-09-14\",\n      }",{"title":3869,"description":3870,"authors":3875,"heroImage":3871,"date":3216,"body":3877,"category":849,"tags":3878},[3876],"Gabriel Mazetto","\n[Geo](https://docs.gitlab.com/ee/administration/geo/index.html), our solution for read-only mirrors of your GitLab instance, started with our co-founder [Dmitriy Zaporozhets](/company/team/#dzaporozhets)’ crazy idea of making not only the repositories, but the entire GitLab instance accessible from multiple geographical locations.\n\nAt that time (Q4 of 2015) there were only a few competitors trying to provide an *automatic mirroring* solution for repositories and/or issue trackers, and they were mostly built around an additional independent instance and a bunch of webhooks to replicate events. Also, in those cases, no other data was shared outside this asynchronous replication channel, and you had to set up the webhook per project and take care of the users yourself. Long story short: this was not practical for any instance with more than a couple of projects.\n\nWe also had a previous experience early that year [using DRBD to migrate 9 TB of data](/blog/moving-all-your-data/) from our dedicated co-location hosting to the AWS cloud,\nwhich didn't provide the scale, performance, or the UX we had in mind for the future.\n\nHere's the history of how we built Geo:\n\n## Phase 1: MVP\n\nGeo's first mission was to provide people who were located in satellite offices, or in distant locations, with fast access to the tools they need to get work done. The plan was not only to make it faster for Git clones to occur in remote offices but also to provide a fully functional read-only version of GitLab: all project issues, Git repositories, Wikis, etc. automatically synchronized from the primary with as little delay as possible.\n\nTo get there we made a few architectural decisions:\n\n#### 1. Use native database replication\n\nThis would allow us to replicate any user-visible information, user content, user and permissions, projects, any project relation to groups/namespaces, etc. Basically, any data ever written to the database in the primary node made readily available to the others, without any extra communication overhead in the webhooks.\n\nIt is also the most [Boring Solution](https://handbook.gitlab.com/handbook/values/#efficiency), as it uses proven technologies developed for databases in the past two decades. To simplify the endeavor we decided to support only PostgreSQL.\n\n#### 2. Use API calls to notify any secondary node of changes that should happen on disk\n\nThis is the second synchronization mechanism. If a new project is created or a repository updated, this notification lets any other node know they have this pending action, and should replicate the new data on disk.\n\n#### 3. Use Git itself to replicate the repositories\n\nWe investigated many alternatives to replicate our repositories, from using basic UNIX tools (like `rsync` or equivalent) to specific distributed file-systems features. We were aiming for a simple solution, as ideally we had to support the lowest common denominator, which is a Linux machine running the default filesystem (ext3 or 4). That limitation ruled out any distributed file-system based implementation.\n\nWe considered `rsync` and its variants as well, which could potentially work for our use case, but that would add significant CPU for each synchronization operation, and we expect it to increase as the repositories get bigger and bigger.\n\nBy using `rsync` we would need to grant more on-disk permissions than we were comfortable doing, and restricting its reach could be an engineering challenge in itself.\n\nThe same can be said for `scp` and its variants. In the end, we decided to use Git itself and benefit from its internal protocol. This was a no-brainer and very easy decision to make. We understood the protocol enough and we already had the required safeguards in place. All we needed was a slightly different authentication mechanism for the node-to-node synchronization.\n\n#### 4. Always push code to the primary, pull code from anywhere\n\nWhen we started Geo, there was no bundled Git support for having a multi-repository \"transactional\" replication, or information on how to implement one.\n\nWe figured out quickly that to implement something on that line it would require either a *global lock* or to implement a variant of [RAFT](https://raft.github.io/)/[PAXOS](https://en.wikipedia.org/wiki/Paxos_(computer_science)) on top of Git internal protocol.\n\nBoth solutions have their downsides and tradeoffs, and adding to that the time and effort to build it correctly, led us to opt for the simplest implementation: always push to the primary, notify secondaries that repository data changed, and have the secondaries fetch the changes. This is also in line with our motto of [Boring Solutions](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nThe initial repository synchronization is no different than doing a `git clone \u003Cremote> --mirror`. The same idea goes for the repository updates, they behave very similarly to a `git fetch \u003Cremote> --prune`. The difference is that we need to replicate additional, internal metadata as well, that is not normally exposed to a regular user.\n\n![GitLab Geo - MVP Synchronization Architecture Diagram](https://about.gitlab.com/images/blogimages/how-we-built-geo/geo-architecture-mvp.png){: .medium.center}\n\n#### 5. Don’t replicate Redis data between nodes\n\nWe initially thought we could replicate Redis as well as the main database in order to share cached data, session information, etc. This would allow us to implement a Single Sign-On solution very easily, and by reusing the cache we would speed up the initial page load.\n\nAt that time Redis only supported **Leader** to **Follower** replication mode and even though it is usually super fast when used in a local network, the fact remains that replicating data across disparate geographical locations can add significant latency.\n\nThis additional latency would impact on the initial objective of simplifying the Single Sign-On implementation. If you simply log in on the primary node and get redirected to the secondary, chances are that the session information would still not be available on the secondary node due to the replication latency.\n\nThat would eventually fix itself by redirecting back and forth, but if the latency is significant enough, your browser will terminate the connection based on the redirect loop prevention feature. Another downside of this approach is that it creates a hard dependency on the primary node being online, or otherwise the secondary node would be inaccessible and/or completely broken.\n\nIn addition to all these issues, we needed an additional Redis instance that supports writing data to it, in order to persist Jobs to our Jobs system on the secondary node.\n\nSo it made sense, in the end, to give up on the idea of replicating Redis, and we started looking for a solution to the authentication problem.\n\n#### 6. Authenticate on the primary node only\n\nBecause we can’t write on the main database of secondary nodes, any auditing logs, brute force protection mechanism, password recovery tokens, etc. can’t have their data and state persisted inside secondary nodes. The only viable solution then is to authenticate on the primary and redirect the user to the secondary.\n\nThis decision also helped with the integration of any company-specific authentication systems. If a company uses internal authentication based on LDAP, CAS or SAML for instance, then they wouldn't have to replicate that system to the other location or configure firewall rule exceptions to accept traffic over the internet.\n\n#### 7. Implement Single Sign-On and Single Sign-Off using OAuth\n\nWith the previous Redis limitations in mind, we looked into alternatives to implement the authentication. We had to choose between either CAS or an OAuth-based one. As we already had OAuth Provider support inside GitLab, we decided to go with that.\n\nBasically, for any Geo node configured in the database we also have a corresponding OAuth application inside GitLab, and whenever a new user tries to log into a Geo node, they get redirected to the primary node and need to \"allow\" the \"Geo application\" to have access to their account credentials at the first login.\n\nThe shortcoming here is that if you are not logged in already and the primary goes down, you can't log in again until the primary node connectivity issue is fixed.\n\n#### 8. Build a read-only layer on the application side to prevent accidents\n\nWe needed this safeguard in place in case any required subsystem was misconfigured. With the read-only layer, we can prevent the instance from diverging from the primary in a non-recoverable way. It's also this layer that prevents anyone from pushing a repository change to the secondary node directly.\n\n#### 9. Don’t replicate any user attachments yet, just redirect to the primary\n\nInstead of trying to replicate user attachments at this stage, we decided to just rewrite the URLs pointing the resource to the primary node instead. This allowed us to iterate faster and still provide a decent experience to the end users.\n\nThey would still enjoy faster access to the repository data and have the web UI rendering the content from a closer location, with the exception of the issue/merge request attachments, avatars etc, which were still being fetched from the primary. But as they are also highly cachable the impact is minimal.\n\nThis was the initial foundation that allowed us to validate Geo as a viable solution. Later on, we took care of replicating the missing data as well.\n\n### Bonus trivia\n\nThe term **Geo** came only after a while, it was previously named as **GitLab RE** (*Read-Only Edition*), followed by **GitLab RO** (*Read Only*) before getting its final name: **GitLab Geo**.\n\n## Phase 2: First-generation synchronization mechanism\n\nWith the MVP implementation done, we needed to pave the way for a stable release. The first part we decided to improve was the notification mechanism for pending changes. During the MVP, we built a custom API endpoint and a buffered queue. That queue was also optimized to store only unique, idempotent events. If a project received three push events in the last few seconds, we only needed to store and process one event notification.\n\nWe decided that instead of building our own custom notification \"protocol\" and implementing some early optimizations, we should leverage existing GitLab internal capabilities: our own webhooks system.\n\n![GitLab Geo - First Generation Synchronization Architecture Diagram](https://about.gitlab.com/images/blogimages/how-we-built-geo/geo-architecture-first-gen.png){: .medium.center}\n\nBy taking that route, we would be forced to \"[drink our own champagne](https://en.wikipedia.org/wiki/Eating_your_own_dog_food#Alternative_terms)\" and as a result, improve our existing functionality. That decision actually resulted in improvements to our system-wide webhooks in a few ways. We added new system-wide webhook events, expanded the granularity of the information available, and fixed some performance issues.\n\nWe've also improved the security of our webhooks implementation by adding ways of verifying that the notification came from a trusted source. Previously the only way to do that relied on whitelisting the originating IP address as a way to establish trust.\n\nThis security limitation was not present in the MVP version, as we reused the admin personal token as the authorization mechanism for the API, which is also not ideal, but better than previous webhook implementation.\n\nI consider this to be the first generation of the synchronization mechanism that was used in the wild. It had a few characteristics: it reacted almost like real-time for small updates, webhook was fast enough and parallelizable to be used on the scale we wanted to support.\n\nAs the very first version of Geo was only concerned with getting repositories available and in-sync, from one location to the other, that's where we focused all of our efforts. At that time, setting up a new Geo node required an almost identical clone of the primary to be available in advance. That included not only replicating the database but also *rsyncing* the repositories from one node to the other. For improved consistency, we required initially a *stop the world* phase in order to not lose changes made during the time between when the backup started and when the secondary node got completely set up.\n\nWhile this was still closer to a barebones solution, it already provided value for remote teams working together in a shared repository or simply in any project that needed to synchronize code between different locations. We had a few customers trying it out and evaluating the potential, but it was still not ready for production use as we were still missing a lot of functionality.\n\nThe *stop the world* phase previously mentioned got phased out later with the help of improved setup documentation. Much later, a good chunk of the initial cloning step got simplified by leveraging some improvements in the next-generation synchronization and by introducing a backfilling mechanism.\n\n### First-generation synchronization pitfalls\n\nWhile our first-generation solution worked fine for the highly active repositories, the use of webhooks as a notification mechanism had some really obvious drawbacks.\n\nIf, for any reason, the notification failed to be delivered, it had to be rescheduled and retried. Also because we were using our internal Jobs system to dispatch the webhooks, having a node go dark for a few hours meant our Jobs system would be busy retrying operations over an unreachable destination for at least that same amount of time.\n\nDepending on the volume of data and how long it has been accumulating changes, that could even fill up the Redis instance disk storage. If that ever happened we would have to resync the whole instance again and start from scratch.\n\nWe've improved the retrying mechanism with custom Geo logic to alleviate the problem, but it was clear to us that this was not going to be a viable solution for a Generally Available (*stable*) release.\n\nAlso because of backoff algorithm in the retrying logic, in conjunction with the asynchronicity aspect of the system, it could lead to important changes taking a lot of time to replicate, especially in less active projects. The busiest ones were less affected, as any update to the repository would get it to the current state rather than to the state when the update notification was issued. And because the project is receiving many updates during the day, it's expected to generate also many notification events.\n\nAny implementation misstep between sending the webhook or receiving and processing it on the other side could mean we would lose that information forever. This was again not a major issue with highly active projects, as it would eventually receive a new, valid update notification which would sync it to the current state, but the outliers could miss it until someone notices or another update arrives much later.\n\nWe also wanted to make Geo a viable Disaster Recovery solution in the long term, so missing updates without a way to recover from it was not an option.\n\n## Phase 3: Second-generation synchronization mechanism\n\nWe started looking for alternative ways of notifying the secondary nodes and also considered switching to other standalone queue systems instead. We were also worried about the lack of control over the order in which the operations would happen in a parallel and asynchronous replication system and on the effect it had on the data on disk.\n\nA few examples of situations that can happen because of the parallelism and the async nature of it:\n\n1. A project removal event can be processed before a project update for the same repository\n1. Renaming, creating a project with the new name and sending new content to it, if processed in an incorrect order, can lead to temporary data loss\n\nThere was also the case when the notification arrived before the database had replicated the required data. As an example, when the node receives the notification for new project creation, but the database doesn't have it yet.\n\nThat required the secondary node to keep a \"mailbox\" until the received events are ready to be processed. As they were basically Jobs, that meant keep retrying until the job succeeded.\n\nConsidering all the complexity we had brought to the application layer, we investigated a few standalone queue systems to which we could offload the burden, but decided ultimately to build an event queue mechanism in PostgreSQL instead, as it had three important advantages:\n\n#### 1. No extra dependencies\nWe were already replicating the database, so there is no need to install, configure and maintain another process, worry about backing up yet another component, integrate it in our Omnibus package, and provide support for our users.\n\n#### 2. No more delayed processing\nIf the event arrives on the other side, the data associated with it will already be there as well. We can also guarantee consistency with transactions and repeat less information than with the webhooks implementation.\n\n#### 3. Easy to retry/restore from backup or in a disaster situation\nWith a standalone queue system, to have a consistent backup solution you either need some sort of \u003Cabbr title=\"Write-Ahead Logging\">WAL\u003C/abbr> files that could help rebuild a consistent state between the systems or do backups in a \"stop the world\" way, otherwise, you may lose data.\n\n### Our implementation\n\nWe took inspiration from how other log-based replication systems work (like the database) and implemented it with a central table as the main source of truth and a few others to hold bookkeeping for specific event types. Any relevant information we used to ship with the webhook notification is now part of this implementation, with extras to support the missing replicable events.\n\nOn the secondary node, these new tables are read by a specific daemon (we call it the Geo Log Cursor), and as the name suggests, it holds a persistent pointer of the last processed event. This allows us to also report the state of replication and monitor if our replication is broken. We also made it highly available, so you can boot up one as **Active** and keep a few extras as **Standby**. If the Active daemon stops responding for a specified amount of time a new election starts and one of the Standbys takes place as the new Active.\n\nThe second part of the new system requires a persistent layer on the secondary node to keep any synchronization state and metadata. This was done by using another PostgreSQL instance.\n\nWe couldn’t reuse the same main instance, as we were replicating with *Streaming replication* mode. With *Streaming replication*, the whole instance is replicated, and you can’t perform any change in it. The alternative to being able to replicate and write in the same instance is to use *Logical replication* mode, but at that time, there was no official *Logical Replication* support available in the PostgreSQL versions we supported (PgLogical was also not a viable alternative back then).\n\nWith the new persistence layer (we call it the *Geo Tracking Database*), we had the foundations built to be able to actively compare the \"desired vs actual\" state, and find missing data on any secondary instance. We built a more robust backfilling mechanism based on that as well.\n\nQuerying between the two database instances (the replicated Secondary, and the Tracking Database), were made much faster and scalable by enabling Postgres FDW ([Foreign Data Wrapper](https://www.postgresql.org/docs/9.6/static/postgres-fdw.html)). That allowed us to query data using a few **LEFT JOIN** operations among the two instances, instead of pooling with multiple queries from the application layer against the two databases in isolation.\n\n![GitLab Geo - Second Generation Synchronization Architecture Diagram](https://about.gitlab.com/images/blogimages/how-we-built-geo/geo-architecture-second-gen.png){: .medium.center}\n\n### Other improvements\n\nAnother important shortcoming fixed was how we replicated the SSH Keys. This was technical debt we needed to pay since the first implementation. Historically, GitLab built the SSH authorization mechanism as with many other Git implementations, by writing each user-provided SSH Key to the `AuthorizedKeys` file on the server and pointing each one to our [gitlab-shell](https://gitlab.com/gitlab-org/gitlab-shell) application.\n\nThis implementation allowed us to authenticate the authorized users, and because we control how the Shell application is invoked, we can pass a specific key ID to it, that can be used later to identify the user on our database and authorize/deny operations to specific repositories.\n\nThe problem with this approach, in general, is that the bigger the user base is, the slower the initial request will be, as OpenSSH will have to perform a scan to the whole file (**O(N)** complexity). With Geo, that's not just about speed but any delay in updating this file either to add a new key or to revoke an existing one is very undesirable.\n\nWhen we decided to fix that we did for both Geo and GitLab Core by using an interesting feature present in newer versions of OpenSSH (6.9 and above), that allows overriding the `AuthorizedKeys` step, switching from reading the keys from a file to invoke a specified CLI instead (*O(1)* complexity). You can read more about it [in the documentation here](https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html#doc-nav).\n\nWe fixed another shortcoming around the repository synchronization, switching from Git over SSH protocol, to Git over HTTPS. The initial motivation was to simplify the setup steps, but that decision also allowed us to shape the synchronization differently when it was originated from a Geo node, vs a regular request. Internally we store additional metadata in the repository and also commits that may no longer exist in your regular branches, but were part of a previous merge request, or had user comments associated with them.\n\nBy also switching to full HTTP(S), it made it simpler to run our development instances locally with [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit), which helped to improve our own internal development process as well.\n\n## Phase 4: Third-generation synchronization and the path to a Disaster Recovery solution\n\nWhile still working in Phase 3, we discovered another major limitation around how we stored files on disk. GitLab, for historical reasons, stored repositories and file attachments in a similar disk structure as the base URL routes. For group and project `gitlab-org/gitlab-ce` there would be a path on disk that would include `gitlab-org/gitlab-ce` as part of it. The same is true for file attachments.\n\nKeeping both the database and disk in sync, even not considering Geo replication, means that at any time a project is renamed, several things have to be renamed on disk as well.\n\nThis is not only slow and error prone: what should we do if something fails to rename in the middle of the \"transaction?\" This is also problematic when replication comes into place as we are susceptible again to processing it in the correct order or risk a temporarily inconsistent state.\n\nWe tried to find a solution to problems around the order of execution of the events and we came up with three ideas:\n\n1. **Find or build a queue system that is guaranteed to process things in the same order they were scheduled**\n2. **Detect and recover from any replication failure or data corruption**\n3. **Make every replication operation idempotent, removing the queue-ordering requirement completely**\n\nThe first one was easily ruled out, as even if we switched to a queue system with that type of guarantee, it would be either slow due to the lack of parallelism in order to guarantee the order requirement, or will be extremely complex and hard to use as it would require extra care to have the same guarantees while also working in parallel.\n\nWe found no system that satisfied our needs, and even if we considered a standalone queue solution, we would lose the Postgres advantage from the previous generation, of having both the main database and the queue system always in sync.\n\nRuling out the first one, we considered the second idea of detecting and recovering from failures and data corruption as we concluded we needed it for *Disaster Recovery* anyway. Any robust *Disaster Recovery* solution needs to guarantee that the data it is holding is the exact one it's supposed to have. If, for any reason, that data gets corrupt or someone removes it from disk, it needs a way of detecting it and restores it to the desired state.\n\nTo achieve that, we built a robust verification mechanism that generates a checksum of the state of the repository and is stored in a separate table in the primary node. That table gets replicated to secondary nodes, where another checksum is also calculated (and stored in the Tracking Database). If both checksums match, we know the data is consistent. The checksum is recalculated automatically when an update event is processed, but can also be triggered manually.\n\n![Screen Capture - Repository Verification Status](https://about.gitlab.com/images/blogimages/how-we-built-geo/verification-status-primary.png){: .medium.center}\n\nWe used that mechanism to validate all repositories in `gitlab.com` when successfully [migrating from Azure to GCP](/blog/gcp-move-update/), last month.\n\nThe verification mechanism is not enough and while it gives us the guarantees we need, we can do better, which is why we also decided to implement the third idea as well, and make every replication operation idempotent in order to remove any situation where processing the incorrect order of events would put data in a temporarily inconsistent state.\n\nWe are calling that solution the [Hashed Storage](https://docs.gitlab.com/ee/administration/repository_storage_types.html). This is a complete rewrite of how GitLab stores files on disk. Instead of reusing the same paths as present in the URLs, we use the internal IDs to create a hash instead and derive the disk path from that hash. With the Hashed Storage, renaming a project or moving it to a new group requires only the database operations to be persisted, as the location on disk never changes.\n\n![Hashed Storage and Legacy Storage example](https://about.gitlab.com/images/blogimages/how-we-built-geo/hashed-storage-disk-path-example.png){: .medium.center}\n\nBy making the paths on disk immutable and non-conflicting, any `create`, `move` or `remove` operations can happen in any order, and they will never put the system in an inconsistent state. Also replicating a project rename or moving a project from one group/owner to another will require only the database change to be propagated to take full effect on a secondary node.\n\n## What to expect from Geo in the near future\n\nImplementing Geo has been an important effort at GitLab that involved many different areas. It is a crucial infrastructure feature that allowed us to migrate from one cloud provider to another. We also believe it's an important component to support the needs of many organizations today, from providing peace of mind regarding data safety in the events of a Disaster Recovery, to easing the burdens of distributed teams across the globe.\n\nWe've been using the feature ourselves and this allowed us to stress-test the biggest and most challenging GitLab installation, GitLab.com, making sure it will work just as fine for any other customer.\n\nOver the upcoming months we will be focusing on the following items:\n\n* Release a push proxy for Geo secondary nodes: [Pull and push from the same remote transparently](https://gitlab.com/groups/gitlab-org/-/epics/124)\n* Release [Hashed Storage as *Generally Available*](https://gitlab.com/groups/gitlab-org/-/epics/75)\n* Improve configuration: We want to reduce the steps and make it [simpler via automating most steps](https://gitlab.com/groups/gitlab-org/-/epics/367)\n* Improve the verification step: [Improve the signals we use for the checksum](https://gitlab.com/gitlab-org/gitlab-ee/issues/5196)\n* [Improve the Geo UX and UI](https://gitlab.com/groups/gitlab-org/-/epics/369)\n* Keep improving performance and reliability\n* Support replication of [GitLab Pages](https://gitlab.com/gitlab-org/gitlab-ee/issues/4611) and the internal [Docker Registry](https://gitlab.com/gitlab-org/gitlab-ee/issues/2870)\n\nCover photo by [NASA](https://unsplash.com/photos/Q1p7bh3SHj8) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[9,680],{"slug":3880,"featured":6,"template":683},"how-we-built-gitlab-geo","content:en-us:blog:how-we-built-gitlab-geo.yml","How We Built Gitlab Geo","en-us/blog/how-we-built-gitlab-geo.yml","en-us/blog/how-we-built-gitlab-geo",{"_path":3886,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3887,"content":3893,"config":3898,"_id":3900,"_type":13,"title":3901,"_source":15,"_file":3902,"_stem":3903,"_extension":18},"/en-us/blog/how-we-reduced-mr-review-time-with-value-stream-management",{"title":3888,"description":3889,"ogTitle":3888,"ogDescription":3889,"noIndex":6,"ogImage":3890,"ogUrl":3891,"ogSiteName":670,"ogType":671,"canonicalUrls":3891,"schema":3892},"How we reduced MR review time with Value Stream Management ","The GitLab engineering team leverages VSM to pinpoint bottlenecks in the merge request review process and streamline software delivery. See how we do it and what we've learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097876/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097875817.png","https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we reduced MR review time with Value Stream Management \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2025-02-20\",\n      }",{"title":3888,"description":3889,"authors":3894,"heroImage":3890,"date":3895,"body":3896,"category":849,"tags":3897},[2014],"2025-02-20","At GitLab, we're passionate about using our own products internally, a.k.a. dogfooding. Dogfooding has led to significant improvements in accelerating our software delivery cycle time for customers. This article spotlights a specific use case where [GitLab Value Stream Management (VSM)](https://about.gitlab.com/solutions/value-stream-management/) has driven significant improvements for our engineering team. You'll learn how VSM helped us tackle two critical challenges: measuring the journey from idea conception to merge request completion, and streamlining our deployment workflows.\n\n## The Challenge: Identifying bottlenecks in MR reviews\n\nDespite having well-defined workflows, one team noticed that MRs were taking longer than expected to be reviewed and merged. The challenge wasn’t just about the delays themselves, but about understanding *where* in the review process these delays were happening and *why*.\n\nOur team’s goal was clear:\n\n- Identify where time was being spent from the initial idea to the final merge of an MR.  \n- Pinpoint specific bottlenecks in the review process.  \n- Understand how MR size, complexity, or documentation quality affect review time.\n\n## The Approach: Measures the MR review time in GitLab Value Stream Analytics\n\nValue Stream Analytics (VSA) enables organizations to map their entire workflow from idea to delivery, distinguishing between value-adding activities (VA) and non-value-adding activities (NVA) in the process flow. By calculating the ratio of value-added time to total lead time, the team can identify wasteful activities resulting in delays in MR reviews.\n\nTo obtain the necessary metrics, the team customized GitLab VSA to gain better visibility into our MR review process.\n\n### 1. Setting up a custom stage for MR review\n\nThe team added a [new custom stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events) in VSA called **Review Time to Merge** to specifically track the time from when a reviewer was first assigned to when the MR was merged.\n\n* Start event: MR first reviewer assigned  \n* End event: MR merged\n\nBy defining this stage, VSA began measuring the duration of the MR review process, giving us precise data on where time was being spent.\n\n![Defining stage of VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097883929.png)\n\n### 2. Using the Total Time Chart for clarity\n\nWith the custom stage in place, the team used the [**Total Time Chart** on the VSA Overview page](https://about.gitlab.com/blog/value-stream-total-time-chart/) (**Analyze > Value Stream**) to visualize how much time was spent during the new MR Review stage. By comparing the values represented by each area on the chart, the team could quickly identify how this stage contributed to the total software delivery lifecycle (SDLC) time.\n\n![total time chart for VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097883930.png)\n\n### 3. Drilling down for deeper insights\n\nTo investigate specific delays, the team used the **Stage Navigation Bar** to dive deeper into the MR Review stage. This view allowed them to:\n\n- Sort MRs by review time: The stage table showed all related MRs, sorted by review duration, making it easy to detect slow MRs.  \n- Analyze individual MRs: For each MR, that team could examine factors such as reviewer assignment delays, multiple rounds of feedback, idle time after approval, and MR size/complexity.\n\n## The outcome: Actionable insights and improvements\n\nBy customizing VSA to track [MR review time](https://docs.gitlab.com/user/project/merge_requests/reviews/), the team uncovered several key insights:\n\n- **Delays in reviewer assignment:** Some MRs experienced delays because reviewers were assigned late, or reviewers had too many MRs in their queue.  \n- **Slow review start times:** Even after assignment, certain MRs sat idle before reviews began, often due to context switching or competing priorities.  \n- **Multiple feedback loops:** Larger MRs often required multiple rounds of feedback, which extended review time significantly.  \n- **Idle time post-approval:** Some MRs were approved but not merged promptly, often due to deployment coordination issues.\n\nFor the engineering manager on the team, VSA proved to be transformational/valuable in managing their team's workflow: *\"I've used the VSA to justify where we were spending time in MR completion. We have VSA customized to our needs, and it's been very beneficial to our investigations for opportunities for improvements.”* \n\nAlso, from this dogfooding experience, we’re now developing a key enhancement to improve visibility into the review process. We're adding a new event to VSA — [Merge request last approved at](https://gitlab.com/gitlab-org/gitlab/-/issues/503754) — which creates a stage that breaks down MR review steps even further for granular visibility.\n\n## The power of data-driven decisions\n\nBy leveraging GitLab’s VSA, we didn’t just identify bottlenecks – we gained actionable insights that led to measurable improvements in MR review time and overall developer productivity. We optimized merge request review cycles and increased developer throughput, validating our commitment to continuous improvement through measurement.\n\n> Want to learn more about how VSA can help your team? [Start a free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/), customize your value streams, and see how you can make improvements throughout the SDLC for your teams. Then, make sure to [share your feedback and experiences in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/520962).\n\n## Read more\n\n- [Optimize value stream efficiency to do more with less, faster](https://about.gitlab.com/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/)\n- [New Scheduled Reports Generation tool simplifies value stream management](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Value stream analytics documentation](https://docs.gitlab.com/user/group/value_stream_analytics/)\n- [Value stream management: Total Time Chart simplifies top-down optimization flow](https://about.gitlab.com/blog/value-stream-total-time-chart/)\n",[701,9,478,894,1813],{"slug":3899,"featured":6,"template":683},"how-we-reduced-mr-review-time-with-value-stream-management","content:en-us:blog:how-we-reduced-mr-review-time-with-value-stream-management.yml","How We Reduced Mr Review Time With Value Stream Management","en-us/blog/how-we-reduced-mr-review-time-with-value-stream-management.yml","en-us/blog/how-we-reduced-mr-review-time-with-value-stream-management",{"_path":3905,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3906,"content":3912,"config":3918,"_id":3920,"_type":13,"title":3921,"_source":15,"_file":3922,"_stem":3923,"_extension":18},"/en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"title":3907,"description":3908,"ogTitle":3907,"ogDescription":3908,"noIndex":6,"ogImage":3909,"ogUrl":3910,"ogSiteName":670,"ogType":671,"canonicalUrls":3910,"schema":3911},"How we turned a dull weekly all-hands into a podcast","We love asynchronous communication so much that we turned a uninspiring department-wide meeting into an engaging podcast – here's why and how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671055/Blog/Hero%20Images/headphones-colorful-background.jpg","https://about.gitlab.com/blog/how-we-turned-40-person-meeting-into-a-podcast","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we turned a dull weekly all-hands into a podcast\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lyle Kozloff\"}],\n        \"datePublished\": \"2019-06-03\",\n      }",{"title":3907,"description":3908,"authors":3913,"heroImage":3909,"date":3915,"body":3916,"category":996,"tags":3917},[3914],"Lyle Kozloff","2019-06-03","\nWe’ve all been there: A department all-hands. At GitLab, we’ve got them too. They’re important: There’s information you need to know, and there’s really only one way to handle it. While it’s true that we’re [all-remote](/company/culture/all-remote/), and everyone joins from their location of choice, they’re still:\n\n - Slow\n - Synchronous\n - Soul-sucking\n\nA few months ago, one of our Support Engineering Managers ([Lee](/company/team/#leematos)) proposed that we try and embrace our value of [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) and [transition this agenda-driven meeting into a pure agenda](https://gitlab.com/gitlab-com/support/support-team-meta/issues/1394), and remove the need for face-to-face communication.\n\nMaking a big transition like this did leave us with some concerns:\n\n### Synchronous meetings can be a chance for people to connect\n\nAt GitLab we recognize the value of getting to know one’s teammates. Employees are encouraged to schedule [coffee chats](/company/culture/all-remote/tips/#coffee-chats) throughout their time at GitLab to get to know one another. (In fact, we think it’s so important that it’s one of the key tasks in [new employee onboarding](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/onboarding.md#all-gitlabbers) ) We even have a consistent small group of people many of us meet up with (on video) four days a week [to connect on a purely personal level](/handbook/communication/#breakout-call) built into the company calendar. These calls aren’t forced, but attendance is organic and inviting, because you will start to build connections. This is especially important in an all-remote organization.\n\nTeam-level meetings can also be an important time to sync up and have time to banter and share personalities. However, we noticed that as the room grew these interactions became less natural. Within the structure of the meeting we tried to correct this with process: Rotating meeting chairs, asking people to post a “Friday Song,” and including a specific meeting section called “Cheerful Banter.” It didn’t work.\n\nUltimately it was a subset of voices who felt comfortable participating in these ways. Meetings beyond a certain size appear to lose their value as a chance for connection. They were less a conversation and more an address. As a result, we felt that we’d have more results concentrating on other avenues for the support team to express themselves and get to know one another.\n\n>We tried rotating meeting chairs, asking people to post a “Friday Song,” and including a specific meeting section called “Cheerful Banter.” It didn’t work.\n\n### Synchronous meetings are a scheduled touchpoint\n\nWhile all of our meetings are recorded and can be watched after the fact, there’s still something about having a cadence to the week. If there’s a meeting every Friday, I know that my brain will be getting new information on Fridays.\n\nTransitioning to a meeting where there is no actual meeting left us with the challenge of making sure people read the document regularly.\n\nTo solve this, we have two touch points during the week: On Wednesdays we have an automated Slack reminder to put things in the document. On Fridays, we have an automated cut-off message that starts a Slack thread for discussion of the week's items. This structure gives a little bit of “rails” that really help package up the meeting.\n\n### Synchronous meetings (at GitLab) can be a chance to absorb while working on something else\n\nThere’s something about having the ability to turn off your camera (or watch the video after the fact). I, personally, enjoy having the space that being an inactive participant in a conversation allows. I’ll often chop vegetables, fold laundry, or go for a run while listening along.\n\nIn fact, this type of passive listening while working on something else is not discouraged at GitLab, in fact it’s [actively encouraged in our handbook](/handbook/communication/#video-calls).\n\nAs we discussed the idea of changing this meeting, we thought it would work best if there was a format that would be efficient and multi-channel. As a big fan of podcasts myself, I thought that the format might work well.\n\n### Putting it together\n\nIf you’re interested in the nitty gritty details, we’ve made a [workflow about how the podcast is actually put together](/handbook/support/workflows/how-to-WIR-podcast.html) in the Handbook.\n\n![Slackbot reminder](https://about.gitlab.com/images/blogimages/slackbot-week-in-review.png){: .shadow.medium.center}\nSlackbot reminds us to add content to the document every Wednesday\n{: .note.text-center}\n\nBriefly, one or more team members will first take a look at each of the links in a the \"Week in Review\" document and the surrounding narrative to build out a script. They'll next pull metrics from our dashboards surrounding our [performance indicators](https://about.gitlab.com/company/kpis/#engineering-kpis) and other numbers we're tracking, like the [number of pairing sessions](https://gitlab.com/gitlab-com/support/support-training/milestones/7). Finally, all together the final recording, mixing and exporting happens – all before 12:00pm PST when a Slackbot announces the release.\n\nAll said, in many ways the ‘new’ format mirrors the old. We still move issues forward, make announcements, thank one another, review our metrics, and tell personal stories. Managers still wax poetic about the things that managers wax poetic about. Team members (probably) still roll their eyes. The biggest difference is that we’ve compressed an hour of “chair time” for 40 people into 10-15 minutes of anything time. And the data is still shareable, and readable too. I call that a win/win/win.\n\nWant to hear what it actually sounds like? Check out our [Support Week in Review from May 31, 2019](https://drive.google.com/open?id=1irQgehSpD2lxxYHQoQh4gBsHnZQLLMj9).\n\nIn what ways can you more efficiently organize and disseminate information in your organization? Do you think a podcast would help? Let us know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\nPhoto by Matthieu A on Unsplash\n{: .note}\n",[829,9,680,998],{"slug":3919,"featured":6,"template":683},"how-we-turned-40-person-meeting-into-a-podcast","content:en-us:blog:how-we-turned-40-person-meeting-into-a-podcast.yml","How We Turned 40 Person Meeting Into A Podcast","en-us/blog/how-we-turned-40-person-meeting-into-a-podcast.yml","en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"_path":3925,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3926,"content":3931,"config":3936,"_id":3938,"_type":13,"title":3939,"_source":15,"_file":3940,"_stem":3941,"_extension":18},"/en-us/blog/impact-of-the-file-type-variable-change-15-7",{"title":3927,"description":3928,"ogTitle":3927,"ogDescription":3928,"noIndex":6,"ogImage":1387,"ogUrl":3929,"ogSiteName":670,"ogType":671,"canonicalUrls":3929,"schema":3930},"Understanding the file type variable expansion change in GitLab 15.7","Learn how the change to file type variable expansion can impact CI jobs that rely on the file contents and what to do.","https://about.gitlab.com/blog/impact-of-the-file-type-variable-change-15-7","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understanding the file type variable expansion change in GitLab 15.7\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Eastman\"}],\n        \"datePublished\": \"2023-02-13\",\n      }",{"title":3927,"description":3928,"authors":3932,"heroImage":1387,"date":3933,"body":3934,"category":678,"tags":3935},[1392],"2023-02-13","\n\nIn GitLab 15.7, we stopped expanding `file type` variables in CI jobs. CI jobs that rely on the old expansion method will generate errors and not work. Here is a look at how this change came about, the difference in job outputs, and what to do next.\n\n## Background\n\nGitLab CI has long-supported file type CI/CD variables. This is a helpful feature for CI jobs, as a file variable is a simple way to pass values to an external system. In cases where there is a concern about environment variable size limits, putting the information in a file and using an environment variable to reference the file is a good option.\n\nBefore 15.7, variable expansion expanded the contents of the file referenced in a file type variable. Some users found this expansion behavior to be quite valuable. In looking at some metrics on GitLab.com, for example, we saw over 1,000 unique projects that used a file variable inside another variable. However, other users did not find this unintended behavior helpful and implemented workarounds.\n\nAs expected, a file referenced in a file type variable may contain sensitive data. So performing variable expansion on the file contents could expose that data in the build environment. Even though the risk could be somewhat mitigated, continuing to expand file type variables was not the right approach to ensure the most secure system.\n\n## Example of the job output before and after 15.7\n\n1. Create a file variable via the GitLab UI. For example: `A_FILE_VAR` with the value `this is some super secret content`.\n1. Create a CI job with this content:\n\n```\ntest_job:\n   stage: test\n   variables:\n     REF_FILE_VAR: $A_FILE_VAR\n   script:\n     - echo $A_FILE_VAR\n     - cat $A_FILE_VAR\n     - echo $REF_FILE_VAR\n     - cat $REF_FILE_VAR\n\n```\n\n**Results before 15.7:**\n\n```\n$ echo $A_FILE_VAR\n/builds/test-project-repo/test-project.tmp/A_FILE_VAR\n$ cat $A_FILE_VAR\nthis is some super secret content\n$ echo $REF_FILE_VAR\nthis is some super secret content\n$ cat $REF_FILE_VAR\ncat: can't open 'this': No such file or directory\ncat: can't open 'is': No such file or directory\ncat: can't open 'some': No such file or directory\ncat: can't open 'super': No such file or directory\ncat: can't open 'secret': No such file or directory\ncat: can't open 'content': No such file or directory\n\n```\n\n**Results after 15.7:**\n\n```\n$ echo $A_FILE_VAR\n/builds/test-project-repo/test-project.tmp/A_FILE_VAR\n$ cat $A_FILE_VAR\nthis is some super secret content\n$ echo $REF_FILE_VAR\n/builds/test-project-repo/test-project.tmp/A_FILE_VAR\n$ cat $REF_FILE_VAR\nthis is some super secret content\n\n```\n\nYou will notice in the 15.7+ job output the echo command no longer prints the contents of the file.\n\n## What is the current status of the change?\n\nWe [deprecated](https://docs.gitlab.com/ee/update/deprecations.html#file-type-variable-expansion-in-gitlab-ciyml) this feature in 15.5 and removed it from the code base in [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/29407). However, we neglected to include a follow-up removal notice in the 15.7 release, so some self-managed customers now upgrading to 15.7+ may have missed the initial deprecation notice.\n\n## What do I need to do before upgrading to 15.7 or higher?\n\n1. Check your CI jobs for any instances where a file variable is referenced inside another variable.\n2. Change the references and test the CI jobs.\n\n## What’s next\n\nSecrets and variable handling are likely some of the most complex areas in a DevSecOps platform. On our end, we are continuously refining our processes to effectively communicate the potential impact of new features or the removal of existing ones. We also recommend that you reach out to us (the Verify team) directly on issues referenced in a release or deprecation notice if it's not clear how a change might affect your CI workflows.\n",[1396,1397,9],{"slug":3937,"featured":6,"template":683},"impact-of-the-file-type-variable-change-15-7","content:en-us:blog:impact-of-the-file-type-variable-change-15-7.yml","Impact Of The File Type Variable Change 15 7","en-us/blog/impact-of-the-file-type-variable-change-15-7.yml","en-us/blog/impact-of-the-file-type-variable-change-15-7",{"_path":3943,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3944,"content":3950,"config":3955,"_id":3957,"_type":13,"title":3958,"_source":15,"_file":3959,"_stem":3960,"_extension":18},"/en-us/blog/improve-security-auditing-with-gitlab-operational-container-scanning",{"title":3945,"description":3946,"ogTitle":3945,"ogDescription":3946,"noIndex":6,"ogImage":3947,"ogUrl":3948,"ogSiteName":670,"ogType":671,"canonicalUrls":3948,"schema":3949},"Improve security auditing with GitLab Operational Container Scanning","Learn how to conduct container vulnerability scans post-deployment to raise awareness of existing threats and to track resolution of vulnerabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664654/Blog/Hero%20Images/AdobeStock_1172300481.jpg","https://about.gitlab.com/blog/improve-security-auditing-with-gitlab-operational-container-scanning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Improve security auditing with GitLab Operational Container Scanning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-01-29\",\n      }",{"title":3945,"description":3946,"authors":3951,"heroImage":3947,"date":3952,"body":3953,"category":704,"tags":3954},[3759],"2025-01-29","Conducting security scans is a regular part of any software development process. Whether scanning source code (e.g., Java, Python, or other languages), configuration files (e.g., YAML files), or [container images](https://cloudnativenow.com/kubecon-cnc-na-2024/unlocking-the-full-potential-of-container-vulnerability-scans/), these scanning tools help development teams be proactive about understanding and addressing security threats. \n\nTraditionally, developers run these [security scans as part of CI/CD pipelines](https://docs.gitlab.com/ee/user/application_security/container_scanning/). By including these scans in CI/CD, every change to a project will be reviewed to see if any vulnerabilities are introduced. Understanding security concerns during development helps to assure that changes are addressed before they are deployed to a live environment, but there are many additional benefits to conducting container vulnerability scans post deployment as well.\n\n[GitLab's Operational Container Scanning](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html) feature allows DevSecOps practitioners to run container vulnerability scans against containers running in a Kubernetes environment. The benefits of conducting a vulnerability scan on deployed containers include regularly scanning the images for new vulnerabilities that are discovered, tracking which environments certain vulnerabilities are deployed to, and also tracking the progress of resolving these vulnerabilities. \n\nThe scans can be configured to run on a regular cadence and on containers in specific namespaces on a Kubernetes cluster. The results of these scans are then sent back to GitLab projects to be viewed via the GitLab UI. To show exactly how the feature works, the next steps in this article will demonstrate how to apply the Operational Container Scanning feature using a GitLab project, sample application, and a Kubernetes cluster. \n\n## Prerequisites\n\nTo get started, you will need the following:   \n* [GitLab Ultimate account](https://about.gitlab.com/free-trial/)   \n* Kubernetes cluster that meets [GitLab’s Kubernetes version requirements](https://docs.gitlab.com/ee/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features)  \n* [kubectl CLI](https://kubernetes.io/docs/tasks/tools/#kubectl)\n* [helm CLI](https://helm.sh/docs/intro/install/)\n\nAdditionally, the walkthrough below will use a [GitLab project](https://gitlab.com/gitlab-da/tutorials/cloud-native/operational-container-scanning-tutorial) that can be forked into a [GitLab group](https://docs.gitlab.com/ee/user/group/) where you have appropriate permissions to carry out the steps that follow. \n\n## Deploy a sample application\n\nThe first action we will carry out is to deploy a sample application to the Kubernetes cluster you will use in this tutorial. Before running the `kubectl` command to deploy a sample application, take a moment to make sure your `KUBECONFIG` is set to the cluster you would like to use. Once you are set up to use your cluster, run the following command:\n\n```bash  \n$ kubectl apply -f\nhttps://gitlab.com/gitlab-da/tutorials/cloud-native/go-web-server/-/raw/main/manifests/go-web-server-manifests.yaml\n\nnamespace/go-web-server-dev created  \ndeployment.apps/go-web-server created  \nservice/go-web-server created  \n```\n\nWait for all the pods to be running in the `go-web-server-dev` namespace by running the command below:\n\n```bash  \n$ kubectl get pods -n go-web-server-dev -w  \n```\n\nYou should see output similar to what is shown below:\n\n```  \nNAME                            READY   STATUS    RESTARTS   AGE  \ngo-web-server-f6b8767dc-57269   1/1     Running   0          18m  \ngo-web-server-f6b8767dc-fkct2   1/1     Running   0          18m  \ngo-web-server-f6b8767dc-j4qwg   1/1     Running   0          18m  \n```\n\nOnce everything is running, you can set up your forked GitLab project to connect to your Kubernetes cluster and configure the Operational Container Scanning properties. \n\n## Connect Kubernetes cluster\n\nIn this section, you will learn how to connect a Kubernetes cluster to your GitLab project via the [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/). By configuring and installing the agent on your Kubernetes cluster, you will be able to also configure Operational Container Scanning. \n\n### Change the id property for GitLab’s Kubernetes agent\n\nIn the forked GitLab project you are using, change the [`id` property in the config.yaml file](https://gitlab.com/gitlab-da/tutorials/cloud-native/operational-container-scanning-tutorial/-/blob/main/.gitlab/agents/k8s-agent/config.yaml?ref\\_type=heads\\#L5) to match the group where you have forked the project. By doing this, you will configure the GitLab Agent for Kubernetes to pass information about your cluster back to your GitLab project. Make sure to commit and push this change back to the main branch of the forked project.\n\n### Navigate to Kubernetes clusters page of the project\n\nIn the GitLab UI, select the **Operate > Kubernetes clusters** tab of the forked project. Click the **Connect a cluster (agent)** button. Add the name of the agent to the input box under `Option 2: Create and register an agent with the UI` and then click **Create and register**. In this case, the name of the agent is `k8s-agent` since the folder under agents with the `config.yaml` file is named `k8s-agent`. Note that this folder can have any name that follows [Kubernetes naming restrictions](https://docs.gitlab.com/ee/user/clusters/agent/install/#create-an-agent-configuration-file) and that `k8s-agent` is just being used for simplicity.\n\n### Install the GitLab Kubernetes agent\n\nAfter registering the agent, you will be asked to run a helm command shown in the GitLab UI from your command line against your Kubernetes cluster. Before running the command, make sure your `KUBECONFIG` is still connected to the same cluster where you deployed the sample application. \n\nAfter running the helm command successfully, wait for all pods to be running in the `gitlab-agent-k8s-agent` namespace on your cluster. You can wait for everything to be running using the following command: \n\n```bash  \n$ kubectl get pods -n gitlab-agent-k8s-agent -w  \n``` \n\nYou should see similar output to what is shown below:\n\n```  \nNAME                                         READY   STATUS    RESTARTS   AGE  \nk8s-agent-gitlab-agent-v2-6bb676b6bf-v4qml   1/1     Running   0          10m  \nk8s-agent-gitlab-agent-v2-6bb676b6bf-xt7xh   1/1     Running   0          10m  \n```\n\nOnce the pods are running, your GitLab project should be connected to your Kubernetes cluster and ready to use the Operational Container Scanning feature. Before proceeding, continue running the `kubectl get pods -n gitlab-agent-k8s-agent -w` command to help explain concepts in the next section.\n\n## Operational Container Scanning\n\nIn addition to the pods for the GitLab agent running in the `gitlab-agent-k8s-agent` namespace, there should eventually be another pod named `trivy-scan-go-web-server-dev`. This pod will start and run on a regular cadence and conduct a container vulnerability scan using a tool named [trivy](https://trivy.dev/latest/) against the `go-web-server-dev` namespace where the sample application deployed earlier is running. \n\nThe Operational Container Scanning properties are defined in the [`config.yaml` file](https://gitlab.com/gitlab-da/tutorials/cloud-native/operational-container-scanning-tutorial/-/blob/main/.gitlab/agents/k8s-agent/config.yaml?ref_type=heads#L6-L10) used to set up the GitLab agent for Kubernetes on your cluster. \n\nThe two main properties to define are `cadence`, which specifies how frequently to run the container vulnerability scan, and also the `namespaces` property nested under `vulnerability_report`, which defines one or more namespaces to conduct the scan on. You can see how this looks in `config.yaml` below:\n\n```yaml  \ncontainer_scanning:  \n  cadence: '*/5 * * * *'  \n  vulnerability_report:  \n    namespaces:  \n      - go-web-server-dev  \n```\n\nThe cadence follows a cron format. In this case, `*/5 * * * *` means the scan will be run every five minutes, but this can be changed to any amount of time (e.g., every 24 hours).  \n\nThe vulnerabilities revealed by the scan for containers running in the `go-web-server-dev` namespace are sent back to your GitLab project. To see the results, go to the GitLab UI and select your forked project. Select the **Secure > Vulnerability report** option for the project and then select the **Operational vulnerabilities** tab to view scan results. \n\nThe scan results will include information on the severity of the common vulnerabilities and exposures (CVEs), along with the name of the image. By using the tag of the image to include the version of the deployed software along with what environment it is deployed to, you can begin to audit what known vulnerabilities exist in your Kubernetes environments and keep track of how they are being addressed by engineering teams.\n\nWatch this demo for more information:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/2FVQec2J-Ew?si=T6kwPMnPAGwKlkfP\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Share your feedback\n\nAdding GitLab’s Operational Container Scanning to your Kubernetes environments can help development, security, and infrastructure teams have a consistent picture of container security in Kubernetes environments across an organization. In addition to GitLab’s CI container scanning capabilities and the ability to [scan containers pushed to GitLab’s container registry](https://www.youtube.com/watch?v=Zuk7Axs-CRw), GitLab has solutions at every phase of the software development lifecycle to address container security concerns.\n\nYou can share your feedback on Operational Container Scanning in this [forum post](https://forum.gitlab.com/t/operational-container-scanning-feedback/119479), which we will share with our product and engineering teams supporting this feature. You can get started with Operational Container Scanning by reading the [documentation on the feature](https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html) and [starting a 60-day free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).",[9,703,746,704,701],{"slug":3956,"featured":6,"template":683},"improve-security-auditing-with-gitlab-operational-container-scanning","content:en-us:blog:improve-security-auditing-with-gitlab-operational-container-scanning.yml","Improve Security Auditing With Gitlab Operational Container Scanning","en-us/blog/improve-security-auditing-with-gitlab-operational-container-scanning.yml","en-us/blog/improve-security-auditing-with-gitlab-operational-container-scanning",{"_path":3962,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3963,"content":3969,"config":3975,"_id":3977,"_type":13,"title":3978,"_source":15,"_file":3979,"_stem":3980,"_extension":18},"/en-us/blog/incident-management-design-facilitation",{"title":3964,"description":3965,"ogTitle":3964,"ogDescription":3965,"noIndex":6,"ogImage":3966,"ogUrl":3967,"ogSiteName":670,"ogType":671,"canonicalUrls":3967,"schema":3968},"How we used design facilitation to understand incident management","The group responsible for the Monitor stage at GitLab recently got together to decide on new product features with a facilitated design session.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678649/Blog/Hero%20Images/incident_management-blog-image.jpg","https://about.gitlab.com/blog/incident-management-design-facilitation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we used design facilitation to understand incident management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n        \"datePublished\": \"2019-03-15\",\n      }",{"title":3964,"description":3965,"authors":3970,"heroImage":3966,"date":3972,"body":3973,"category":996,"tags":3974},[3971],"Amelia Bauerly","2019-03-15","\nBefore starting to design a new product feature, it’s useful to get everyone on the same page by asking a few important questions: What is the problem we are trying to solve?\nWho are we solving this problem for?\nWhat are the steps we should take in trying to solve this problem?\n\nAs we work remotely, collaborating on these questions synchronously isn’t generally an option.\n\nRecently, the [Monitor group](/handbook/engineering/development/ops/monitor/) was given the opportunity to gather in Berlin for a Fast Boot.\nWe took advantage of everyone being in the same place and time zone to host a [facilitated design session](https://gitlab.com/gitlab-org/gitlab-ce/issues/55663) on incident management, where we could answer these questions together.\n\n## How the facilitated design session works\n\nThe session involved walking the group through three exercises, each focusing on one of the core questions we needed to solve.\n\n### We tackled problem definition through running a boundary critique exercise\n\nUsing the [1-2-4-All](http://www.liberatingstructures.com/1-1-2-4-all/) technique, we came up with a list of things incident management is and is not.\nSince we had engineers, designers, and product managers all working together, we were able to benefit from diverse perspectives and experience levels.\nWe finished the exercise by agreeing on a definition of the space we wanted to work on together.\n\n### Next, we did an exercise to build empathy with our users\n\nWe took our four [ops personas](/handbook/product/personas/), broke into groups, and compiled [empathy map canvases](https://gamestorming.com/wp-content/uploads/2017/07/Empathy-Map-Canvas-006.pdf) for each.\nWe then took our deepened understanding of our assigned users and applied it to an imagined incident.\nWe shared our users’ pain points, concerns, and goals with the group.\n\n### Finally, brainstorming product features\n\nHaving established a scope for our work and a sense of our users’ needs, our final exercise involved brainstorming product features that would fit the requirements we had established.\nWe finished the session with everyone dot-voting on features, which left us with a prioritized list of features to work on as we move forward with this project.\n\nThough working this way isn’t a part of our normal flow, the facilitation was a great chance for us all to engage with a product discovery process together.\nBy tackling these questions as a group, we could all come to alignment on what was needed going forward.\nParticipating in these early stages of planning also generates an extra level of commitment to seeing these features through the development process, since we had all agreed on the necessity for them.\n\nWe will continue to explore how to inject the energy and enthusiasm generated by this process into our normal, asynchronous workflow.\n",[829,9,680],{"slug":3976,"featured":6,"template":683},"incident-management-design-facilitation","content:en-us:blog:incident-management-design-facilitation.yml","Incident Management Design Facilitation","en-us/blog/incident-management-design-facilitation.yml","en-us/blog/incident-management-design-facilitation",{"_path":3982,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":3983,"content":3989,"config":3994,"_id":3996,"_type":13,"title":3997,"_source":15,"_file":3998,"_stem":3999,"_extension":18},"/en-us/blog/incident-management-with-gitlab",{"title":3984,"description":3985,"ogTitle":3984,"ogDescription":3985,"noIndex":6,"ogImage":3986,"ogUrl":3987,"ogSiteName":670,"ogType":671,"canonicalUrls":3987,"schema":3988},"Understand incident management with GitLab","GitLab Incident Management helps your response teams focus on the problem and shorten the mean time to repair rather than waste time on the process itself.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681208/Blog/Hero%20Images/incident-management-blog-cover.jpg","https://about.gitlab.com/blog/incident-management-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Understand incident management with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Waldner\"}],\n        \"datePublished\": \"2020-04-03\",\n      }",{"title":3984,"description":3985,"authors":3990,"heroImage":3986,"date":3991,"body":3992,"category":1249,"tags":3993},[2294],"2020-04-03","\n\nManaging incidents can be stressful! While you’re busy trying to restore service for your customers, you are also likely juggling several competing priorities: digging through multiple tools to understand the problem, communicating with stakeholders, and updating tickets in different systems. Did you know that you can use GitLab to help manage the chaos?\n\nGitLab Incident Management, which recently became a [viable category](/direction/maturity/), aims to decrease the overhead of managing an incident so response teams can spend more time actually resolving problems. We do this by enabling teams to quickly gather the resources in one central, aggregated view. We facilitate communication and enable teams to have dialogs that can be captured all in the same tool they already use to collaborate on development. Ultimately, GitLab Incident Management can help response teams to shorten [MTTR](https://en.wikipedia.org/wiki/Mean_time_to_repair).\n\n## Why Incident Management within GitLab?\n\nGitLab is a complete [DevOps platform](/topics/devops/), delivered as a [single application](/handbook/product/single-application/). As such, we believe there are additional benefits for DevOps users to manage incidents within GitLab.\n\n1. Co-location of code, CI/CD, monitoring tools, and incidents reduces context switching and enables GitLab to correlate what would be disparate events or processes within one single control pane.\n1. The same interface for collaboration for development and incident response streamlines the process. The developers who are on call can use the same interface that they already use every day; this prevents the incident responders from having to use a tool that they are unfamiliar with and thus hampering their ability to respond to the incident.\n\n## GitLab Incident Management Capabilities\n\nAvailable today, GitLab Incident Management includes the following highlighted capabilities:\n* [Incident issues](https://docs.gitlab.com/ee/operations/incident_management/index.html#configuring-incidents) as the one place to capture all data and information related to the incident.\n* [Integration with Slack](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#gitlab-slack-application-free-only) to facilitate intuitive team communication\n* [Link Zoom calls to GitLab issues](https://docs.gitlab.com/ee/operations/incident_management/index.html#zoom-in-issues) to facilitate synchronous communication\n* [Embed GitLab-managed Kubernetes metrics](https://docs.gitlab.com/ee/operations/incident_management/index.html#gitlab-hosted-metrics) directly within the GitLab Incident Issue\n* [Embed generic Grafana metrics](https://docs.gitlab.com/ee/operations/incident_management/index.html#grafana-metrics) directly within the GitLab Incident Issue\n* [The GitLab alerts endpoint](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-endpoint) can accept alerts from any source via a generic webhook receiver\n* Prometheus Recovery alerts can [automatically close issues](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#taking-action-on-incidents) that were created when you receive notification that the alert is resolved.\n\n## How to use GitLab Incident Management\n\nThere are numerous entry points to a potential incident. As an incident responder, once you are aware of an ongoing incident, you can manually create an incident issue by simply tagging the issue with the `incident` label.\n\nAlternatively, you can also configure GitLab to automatically create incidents based on alerts from your monitoring tool. When an alert is posted to the GitLab [Alerts endpoint](https://docs.gitlab.com/ee/operations/incident_management/integrations.html), GitLab can create incidents using an [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html), populating important information useful to the incident response team.\n\nThe incident issue template can be customized using [quick actions](https://docs.gitlab.com/ee/user/project/description_templates.html) to label, mention team members, or assign to specific people automatically. Doing so will help create incidents that have a consistent baseline set of information to help jumpstart the incident response.\n\nAs more details for the ongoing incident emerge, you can directly embed GitLab-managed Kubernetes cluster metrics and application metrics in the incident. You can also embed other Grafana metrics in the incident if this is a critical tool for your team. Sharing up to date information in a central location will help facilitate understanding and enable the incident response team to move forward armed with the latest information. Having embedded charts can also enable more effective retrospectives by having relevant information within the same view.\n\nAs the firefight progresses, the incident response team is encouraged to add timeline events, updates, questions, and answers to the incident. These interactions help create an audit trail and enable shared understanding across the team.\n\nAt the end, an incident can be automatically closed once GitLab receives a recovery alert via the enabled Prometheus recovery alert integration. As the team reconvenes to determine actionable next steps, it  can leverage the completed incident ticket to find improvement areas instead of relying on a separate tool. Furthermore, a team can directly create and link action items to the incident issue in the form of related issues and merge requests to improve the resiliency of the system.\n\n## Next Steps\n\nGet started by visiting the [Incident Management documentation page](https://docs.gitlab.com/ee/operations/incident_management/index.html) and create an issue template. Adopt a new process or amend the existing process for incident management to take advantage of the capabilities within GitLab.\n\nIncident Management is a [focus area](/direction/maturity/#monitor) for GitLab in 2020. We plan to continue iterating and improving this category. We’d love your help in prioritizing work on the most valuable improvements to the incident management solution. Keep an eye on [Incident Management Issues](https://gitlab.com/groups/gitlab-org/-/epics/349) and upvote or share your experiences in relevant issues.\n\nTo report a bug or request a feature or enhancement, follow these steps:\n\n* Open an issue in the [GitLab project](https://gitlab.com/gitlab-org/gitlab/issues).\n* Describe the feature enhancement and, if possible, include examples.\n* Add these labels to the issue: Category:Incident Management, devops::monitor, group::health\n* Tag @abellucci on the issue.\n\nCover image by [Tine Ivanic](https://unsplash.com/photos/u2d0BPZFXOY) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[851,9],{"slug":3995,"featured":6,"template":683},"incident-management-with-gitlab","content:en-us:blog:incident-management-with-gitlab.yml","Incident Management With Gitlab","en-us/blog/incident-management-with-gitlab.yml","en-us/blog/incident-management-with-gitlab",{"_path":4001,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4002,"content":4008,"config":4013,"_id":4015,"_type":13,"title":4016,"_source":15,"_file":4017,"_stem":4018,"_extension":18},"/en-us/blog/inside-gitlab-security-dashboards",{"title":4003,"description":4004,"ogTitle":4003,"ogDescription":4004,"noIndex":6,"ogImage":4005,"ogUrl":4006,"ogSiteName":670,"ogType":671,"canonicalUrls":4006,"schema":4007},"Security dashboards secure applications at DevOps speed","GitLab Security Dashboards enable security professionals to view vulnerabilities across a project. Here’s an inside look.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678710/Blog/Hero%20Images/inside-gitlab-security-dashboards.jpg","https://about.gitlab.com/blog/inside-gitlab-security-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How can teams secure applications at DevOps speed? Security Dashboards are here to help.\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2018-09-14\",\n      }",{"title":4009,"description":4004,"authors":4010,"heroImage":4005,"date":3216,"body":4011,"category":849,"tags":4012},"How can teams secure applications at DevOps speed? Security Dashboards are here to help.",[3370],"\nBusiness survival today depends on a radically faster DevOps lifecycle, but how can teams secure applications at DevOps speed? It’s a thorny problem for a number of reasons: applications are a prime target for cyber attacks; most [application security](/topics/devsecops/) tools are resource intensive, requiring integration of both technology and processes; and testers face the dilemma of when and how often to test code that is iteratively changed right up until it’s deployed. Many are faced with weighing the need to test each iteration against the speed and cost of doing so, while the possibility of a rollback looms in the case of an unforeseen security vulnerability.\n\n>Many are faced with weighing the need to test each iteration against the speed and cost of doing so\n\nWe know that shifting left and discovering vulnerabilities earlier in the development process is important, but it’s tough to find the perfect balance, where teams can be confident they’re truly creating business value and not becoming a business inhibitor. It’s clear that our existing application security tools are colliding with modern development. So what if you could scan all code, every time for development, using fewer tools instead of more, and have developers and operations on the same page instead of adversarial?\n\n### Built-in security products\n\nIt’s going to take a fundamental shift by companies towards proactive security. With security issues reported directly in merge requests, one license cost for integrated security, and zero context-switching to proactively secure applications, we believe GitLab can help get you there.\n\nUsing multiple tools forces developers to switch away from their primary objective of developing code, or requires integrated workflows with security pros. We believe successful tools will add high value while minimizing distraction for engineers. With GitLab, [SAST](https://docs.gitlab.com/ee/user/application_security/sast/), [DAST](https://docs.gitlab.com/ee/user/application_security/dast/), [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/), [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), and [license management](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html) are all built in. Because there’s one tool for the software development lifecycle, you can automatically run tests on all code commits, early in the development process.\n\n### Security Dashboard demo\nIn 11.1, [we shipped Security Dashboards](/releases/2018/07/22/gitlab-11-1-released/), to help serve security professionals. Traditionally we’ve focused on the developer, but the Security Dashboard is meant to enable security professionals to view vulnerabilities across a project. Here’s a quick look at our first iteration of the Security Dashboard:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/U2_dqwTRUVk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nKeep an eye out for [improvements](https://gitlab.com/gitlab-org/gitlab-ee/issues/6709), and let us know what you think by tweeting us [@gitlab](https://twitter.com/gitlab)!\n\nCover photo by [Christian EM](https://unsplash.com/photos/J7EUjSlNQtg) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[851,9,680,704],{"slug":4014,"featured":6,"template":683},"inside-gitlab-security-dashboards","content:en-us:blog:inside-gitlab-security-dashboards.yml","Inside Gitlab Security Dashboards","en-us/blog/inside-gitlab-security-dashboards.yml","en-us/blog/inside-gitlab-security-dashboards",{"_path":4020,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4021,"content":4027,"config":4033,"_id":4035,"_type":13,"title":4036,"_source":15,"_file":4037,"_stem":4038,"_extension":18},"/en-us/blog/inside-look-how-gitlabs-test-platform-team-validates-ai-features",{"title":4022,"description":4023,"ogTitle":4022,"ogDescription":4023,"noIndex":6,"ogImage":4024,"ogUrl":4025,"ogSiteName":670,"ogType":671,"canonicalUrls":4025,"schema":4026},"Inside look: How GitLab's Test Platform team validates AI features","Learn how we continuously analyze AI feature performance, including testing latency worldwide, and get to know our new AI continuous analysis tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099033/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750099033422.png","https://about.gitlab.com/blog/inside-look-how-gitlabs-test-platform-team-validates-ai-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside look: How GitLab's Test Platform team validates AI features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Lapierre\"},{\"@type\":\"Person\",\"name\":\"Vincy Wilson\"}],\n        \"datePublished\": \"2024-06-03\",\n      }",{"title":4022,"description":4023,"authors":4028,"heroImage":4024,"date":2095,"body":4031,"category":806,"tags":4032},[4029,4030],"Mark Lapierre","Vincy Wilson","AI is increasingly becoming a centerpiece of software development - many companies are integrating it throughout their DevSecOps workflows to improve productivity and increase efficiency. Because of this now-critical role, AI features should be tested and analyzed on an ongoing basis. In this article, we take you behind the scenes to learn how [GitLab's Test Platform team](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/) does this for [GitLab Duo](https://about.gitlab.com/gitlab-duo/) features by conducting performance validation, functional readiness, and continuous analysis across GitLab versions. With this three-pronged approach, GitLab aims to ensure that GitLab Duo features are performing optimally for our customers.\n\n> Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Watch today!](https://about.gitlab.com/seventeen/)\n\n## AI and testing\n\nAI's non-deterministic nature, where the same input can produce different outputs, makes ensuring a great user experience a challenge. So, when we integrated AI deep into the GitLab DevSecOps Platform, we had to adapt to our best practices to address this challenge. \n\nThe [Test Platform team's mission ](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/) is to help enable the successful development and deployment of high-quality software applications with continuous analysis and efficiency to help ensure customer satisfaction. The key to achieving this is by delivering tools that help increase standardization, repeatability, and test consistency. \n\nApplying this to GitLab Duo, our AI suite of tools to power DevSecOps workflows, means being able to continuously analyze its performance and identify opportunities for improvement. Our goal is to gain clear, actionable insights that will help us to enhance GitLab Duo's capabilities and, as a result, better meet our customers' needs. \n\n## The need for continuous analysis of AI\n\nTo continuously assess GitLab Duo, we needed a mechanism for analyzing feature performance across releases. Therefore, we created an AI continuous analysis tool to automate the collection and analysis of data to achieve this. \n\n![diagram of how the AI continuous analysis tool works](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099041/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099041503.png)\n\n\u003Ccenter>\u003Ci>How the AI continuous analysis tool works\u003C/i>\u003C/center>\n\n### Building the AI continuous analysis tool\n\nTo gain detailed, user-centric insights, we needed to gather data in the appropriate context – in this case, the integrated development environment (IDE), as it is where most of our users access GitLab Duo. We narrowed this down further by opting for the Visual Studio Code IDE, a popular choice within our community. Once the environment was chosen, we automated entering code prompts and recording the provided suggestions. The interactions with the IDE are handled by the [WebdriverIO VSCode service](https://github.com/webdriverio-community/wdio-vscode-service), and CI operations are handled through [GitLab CI/CD](https://docs.gitlab.com/ee/ci/). This automation significantly scaled up data collection and eliminated repetitive tasks for GitLab team members. To start, we have focused on measuring the performance of GitLab Duo Code Suggestions, but plan to expand to other GitLab AI features in the future.\n\n### Analyzing the data\n\nAt the core of our AI continuous analysis tool is a mechanism for collecting and analyzing code suggestions. This involves automatically entering code prompts, recording the suggestions provided, and logging timestamps of relevant events. We measure the time from when the tool provides an input until a suggestion is displayed in the UI. In addition, we record the logs created by the IDE, which report the time it took for each suggestion response to be received. With this data, we can compare the latency of suggestions in terms of how long it takes the backend AI service to send a response to the IDE, and how long it takes for the IDE to display the suggestion for the user. We then can compare latency and other metrics of GitLab Duo features across multiple releases. The GitLab platform has the ability to analyze [code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) and [application security](https://docs.gitlab.com/ee/user/application_security/), so we leverage these capabilities to enable the AI continuous analysis tool to analyze the quality and security of the suggestions provided by GitLab Duo.\n\n### Improving AI-driven suggestions\n\nOnce the collected data is analyzed, the tool automatically generates a single report summarizing the results. The report includes key statistics (e.g., mean latency and/or latency at various percentiles), descriptions of notable differences or patterns, links to raw data, and CI/CD pipeline logs and artifacts. The tool also records a video of each prompt and suggestion, which allows us to review specific cases where differences are highlighted. This creates an opportunity for the UX researchers and development teams to take action on the insights gained, helping to improve the overall user experience and system performance.\n\nThe tool is at an early stage of development, but it's already helped us to improve the experience for GitLab Duo Code Suggestions users. Moving forward, we plan to expand our tool’s capabilities, incorporate more metrics and consume and provide input to our [Centralized Evaluation Framework](https://about.gitlab.com/direction/ai-powered/ai_model_validation/ai_evaluation/), which validates AI models, to enhance our continuous analysis further.\n\n## Performance validation\n\nAs AI has become integral to GitLab's offerings, optimizing the performance of AI-driven features is essential. Our performance tests aim to evaluate and monitor the performance of our GitLab components, which interact with AI service backends. While we can monitor the performance of these external services as part of our production environment's observability, we cannot control them. Thus, including third-party services in our performance testing would be expensive and yield limited benefits. Although third-party AI providers contribute to overall latency, the latency attributable to GitLab components is still important to check. We aim to detect changes that might lead to performance degradation by monitoring GitLab components. \n\n### Building AI performance validation test environment\n\nIn our AI test environments, the [AI Gateway](https://docs.gitlab.com/ee/architecture/blueprints/ai_gateway/#summary), which is a stand-alone service to give access to AI features to GitLab users, has been configured to return mocked responses, enabling us to test the performance of AI-powered features without interacting with third-party AI service providers. We conduct AI performance tests on [reference architecture environments of various sizes](https://docs.gitlab.com/ee/administration/reference_architectures/). Additionally, we evaluate new tests in their own isolated environment before they're added to the larger environments.\n\n### Testing multi-regional latency\n\nMulti-regional latency tests need to be run from various geolocations to validate that requests are being served from a suitable location close to the source of the request. We do this today with the use of the [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit). The toolkit provisions an environment in the identified region to test (note: both the AI Gateway and the provisioned environment are in the same region), then uses the [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) to run tests to measure time to first byte (TTFB). TTFB is our way of measuring time to the first part of the response being rendered, which contributes to the perceived latency that a customer experiences. To account for this measurement, our tests have a check to help ensure that the [response itself isn't empty](https://gitlab.com/gitlab-org/quality/performance/-/blob/cee8bef023e590e6ca75828e49f5c7c596581e06/k6/tests/experimental/api_v4_code_suggestions_generation_streaming.js#L70). \n\nOur tests are expanding further to continue to measure perceived latency from a customer’s perspective. We have captured a set of baseline response times that indicate how a specific set of regions performed when the test environment was in a known good state. These baselines allow us to compare subsequent environment updates and other regions to this known state to evaluate the impact of changes. These baseline measurements can be updated after major updates to ensure they stay relevant in the future. \n\nNote: As of this article's publication date, we have AI Gateway deployments across the U.S., Europe, and Asia. To learn more, visit our [handbook page](https://handbook.gitlab.com/handbook/engineering/development/data-science/ai-powered/ai-framework/#-aigw-region-deployments).\n\n## Functionality\n\nTo help continuously enable customers to confidently leverage AI reliably, we must continuously work to ensure our AI features function as expected.\n\n### Unit and integration tests\n\nFeatures that leverage AI models still require rigorous automated tests, which help engineers develop new features and changes confidently. However, since AI features can involve integrating with third-party AI providers, we must be careful to stub any external API calls to help ensure our tests are fast and reliable.\n\nFor a comprehensive look at testing at GitLab, look at our [testing standards and style guidelines](https://docs.gitlab.com/ee/development/testing_guide/). \n\n### End-to-end tests \n\nEnd-to-end testing is a strategy for checking whether the application works as expected across the entire software stack and architecture. We've implemented it in two ways for GitLab Duo testing: using real AI-generated responses and mock-generated AI responses.\n\n![validating features - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099041/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099041504.png)\n\n\u003Ccenter>\u003Ci>End-to-end test workflow\u003C/i>\u003C/center>\n\n#### Using real AI-generated responses\n\nAlthough costly, end-to-end tests are important to help ensure the entire user experience functions as expected. Since AI models are non-deterministic, end-to-end test assertions for validating real AI-generated responses should be loose enough to help ensure the feature functions without relying on a response that may change. This might mean an assertion that checks for some response with no errors or for a response we are certain to receive.\n\nAI-driven functionality is not accessible only from within the GitLab application, so we must also consider user workflows for other applications that leverage these features. For example, to cover the use case of a developer requesting code suggestions in [IntelliJ IDEA](https://www.jetbrains.com/idea/) using the GitLab Duo plugin, we need to drive the IntelliJ application to simulate a user workflow. Similarly, to ensure that the GitLab Duo Chat experience is consistent in VS Code, we must drive the VS Code application and exercise the GitLab Workflow extension. Working to ensure these workflows are covered helps us maintain a consistently great developer experience across all GitLab products. \n\n#### Using mock AI-generated responses\n\nIn addition to end-to-end tests using real AI-generated responses, we run some end-to-end tests against test environments configured to return mock responses. This allows us to verify changes to GitLab code and components that don’t depend on responses generated by an AI model more frequently.\n\n> For a closer look at end-to-end testing, read our [end-to-end testing guide](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/). \n\n### Exploratory testing and dogfooding\n\nAI features are built by humans for humans. At GitLab, exploratory testing and dogfooding greatly benefit us. GitLab team members are passionate about what features get shipped, and insights from internal usage are invaluable in shaping the direction of AI features.\n\n[Exploratory testing](https://about.gitlab.com/topics/devops/devops-test-automation/#test-automation-stages) allows the team to creatively exercise features to help ensure edge case bugs are identified and resolved. Dogfooding encourages team members to use AI features in their daily workflows, which helps us identify realistic issues from realistic users. For a comprehensive look at how we dogfood AI features, look at [Developing GitLab Duo: How we are dogfooding our AI features](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/).\n\n## Get started with GitLab Duo\nHopefully this article gives you insight into how we are validating AI features at GitLab. We have integrated our team's process into our overall development as we iterate on GitLab Duo features. We encourage you to try GitLab Duo in your organization and reap the benefits of AI-powered workflows.\n\n> Start a [free trial of GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial) today!\n\n_Members of the GitLab Test Platform team contributed to this article._\n",[786,9,478,680,1124,2018],{"slug":4034,"featured":90,"template":683},"inside-look-how-gitlabs-test-platform-team-validates-ai-features","content:en-us:blog:inside-look-how-gitlabs-test-platform-team-validates-ai-features.yml","Inside Look How Gitlabs Test Platform Team Validates Ai Features","en-us/blog/inside-look-how-gitlabs-test-platform-team-validates-ai-features.yml","en-us/blog/inside-look-how-gitlabs-test-platform-team-validates-ai-features",{"_path":4040,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4041,"content":4047,"config":4052,"_id":4053,"_type":13,"title":4054,"_source":15,"_file":4055,"_stem":4056,"_extension":18},"/en-us/blog/insights",{"title":4042,"description":4043,"ogTitle":4042,"ogDescription":4043,"noIndex":6,"ogImage":4044,"ogUrl":4045,"ogSiteName":670,"ogType":671,"canonicalUrls":4045,"schema":4046},"GitLab: New Tool to Visualize High-Level Project Trends","How our easy to configure Insights technology takes data from issues and merge requests to build visually appealing charts.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681053/Blog/Hero%20Images/birdseyeview.jpg","https://about.gitlab.com/blog/insights","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We're dogfooding a tool to help visualize high-level trends in GitLab projects\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2020-01-30\",\n      }",{"title":4048,"description":4043,"authors":4049,"heroImage":4044,"date":973,"body":4050,"category":849,"tags":4051},"We're dogfooding a tool to help visualize high-level trends in GitLab projects",[675],"\n\nOur policy at GitLab is to [dogfood everything](/handbook/engineering/development/principles/#dogfooding) – meaning we aren't going to introduce a new product or feature to our [DevOps platform](/solutions/devops-platform/) before our engineering team tests it out. Sometimes though, the development process happens in reverse: The product and engineering teams need a specific tool or functionality to help us run GitLab better and discover a tool that has the capacity to solve many different customer use cases.\n\n[Insights](https://docs.gitlab.com/ee/user/project/insights/), which is available to [GitLab Ultimate](/pricing/ultimate/) users, is an example of such a tool. Insights is a flexible feature of GitLab that allows our users to visualize different trends in workflows, bugs, merge request (MR) throughput, and issue activity that is based upon the underlying labeling system of a group. In this blog post, we'll go in-depth on how and why we built this tool, how we use the tool at GitLab, and explain how to configure Insights for your own projects.\n\n\n- [Why we built Insights](#why-we-built-insights)\n- [Labels powers Insights](#why-label-hygiene-matters)\n- [How to configure Insights](#configuring-your-insights-dashboard)\n- [How GitLab uses Insights](#how-we-are-dogfooding-insights)\n- [Implementing Insights in your instance](#implementing-insights-for-your-team)\n\n[Kyle Wiebers](/company/team/#kwiebers), quality engineering manager on Engineering Productivity, gives an overview of how we use Insights at GitLab in the GitLab Unfiltered video embedded below. Watch the video and read the rest of the post to learn all about this exciting new tool we're dogfooding at GitLab.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/kKnQzS9qorc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Why we built Insights\n\nThe [Engineering Productivity team](/handbook/engineering/quality/#engineering-productivity) at GitLab first built Insights to provide an overview of trends in the issue tracker, but soon realized that this technology can be applied in different ways that were beneficial to our needs, and the needs of our users.\n\n\"The initial thing was we were interested in when the bugs were being raised: Were they being raised around release time or were they being raised the middle of a phase?\" says [Mark Fletcher](/company/team/#markglenfletcher), backend engineer on Engineering Productivity. \"Because we did have bugs being created just after release, which led to regressions, which led to patch fixes. So we were just interested in exploring those kinds of trends.\"\n\nTo capture this trend data the Quality Engineering team created the [quality dashboard](https://quality-dashboard.gitlap.com/groups/gitlab-org), which was essentially the first iteration of Insights for GitLab. While the quality dashboard showed trends in bugs being raised per release cycle, it also showed how much work was being accomplished over the same period.\n\n\"And that's where the scope really changed from looking at issues that are bugs to merge requests and being able to have generic rules based on labels that we can use to align with our workflow,\" says Kyle.\n\n## Why label hygiene matters\n\nThe Engineering Productivity team soon realized that a lot of the different trends they were aiming to capture with Insights were powered by [labels](https://docs.gitlab.com/ee/user/project/labels.html#overview). Labels allow a GitLab user to categorize epics, issues, and merge requests with descriptive titles such as \"bug\" or \"feature request\" and quickly filter based upon category. The label filtering system works inside the [issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&first_page_size=100), and all throughout GitLab, and is a core part of the underlying configuration of Insights.\n\nA good example of an Insights dashboard that is configured by labels and the metadata that underlies issues and merge requests (such as creation date) is the [MR throughputs dashboard](https://gitlab.com/groups/gitlab-org/-/insights/#/throughputs).\n\n![Merge request throughputs for group](https://about.gitlab.com/images/blogimages/merge_throughputs_group.png){: .shadow.medium.center}\nA screenshot of the chart for merge request throughouts at the group level.\n{: .note.text-center}\n\nThe MR throughputs dashboard captures how many MRs are completed during a given week or month to measure our organization's overall performance. It is part of our workflow to assign labels to MRs that help distinguish the type of MR being worked on: feature, bug, community contribution, security, or backstage. This dashboard is configured as a stacked bar chart, which makes it easy to visualize MR throughput by type so we can see the type of work being created over a fixed period of time. The chart is also divided into weekly or monthly views, which helps us see both short- and long-term trends.\n\n\"So, we can look at short-term trends and longer-term trends to see: Are we delivering more work? Are we hitting a bottleneck? Are we plateauing? And that allows us to dive a little bit deeper and take corrective action,\" says Kyle.\n\n### Labels help simplify the configuration of dashboards\n\nIf you look to the lefthand sidebar of the MR throughputs dashboard, you'll notice that the dashboard is configured at the Gitlab-org group level. The group level of GitLab-org contains all of the projects within GitLab-org and therefore captures all of the MR throughput data across all projects.\n\nThe project level is a level below the group level and looks at a specific project contained within a larger group, such as the GitLab project in the GitLab-org group.\n\n![Merge request throughputs for project](https://about.gitlab.com/images/blogimages/mr_throughputs_product.png){: .shadow.medium.center}\nA screenshot of the chart for merge request throughoutputs at the project level.\n{: .note.text-center}\n\nAny Insights dashboard, including the MR throughputs dashboard, can be filtered at the group level or the project level, but the configuration remains the same regardless of how the dashboard is filtered.\n\n\"So everything that's contained within a group, and in our case, it would be the GitLab-org group, you can also have this on a project level,\" says Kyle. \"So if you want to look at Insights on a project, you can configure the same thing on a project. Just for our use case, it made sense to look at MR throughputs across multiple projects versus one specific project.\"\n\nBut in the end, it all comes back to labels. We don't have to configure the Insights dashboard differently for groups and projects because all of our labels at GitLab are set up at the group level and then propagate down to the project level.\n\nOne of the characteristics of Insights that makes it such a valuable feature is that the configuration is so flexible. While most customers will use the same labeling system across groups and projects as GitLab does, it is possible to configure the charts separately at the project and group level.\n\n\"The scope [of Insights] changed from looking at issues that are bugs to merge requests and being able to have generic rules based on labels that we can use to align with our workflow,\" says Kyle. \"Then that flexibility allows any customers to leverage the same feature based on their own specific workflow or labeling practices.\"\n\nA user can use Insights on a group or project regardless of the underlying labeling system. They just need to configure the dashboard according to their workflow.\n\n## Configuring your Insights dashboard\n\nThere are numerous Insights dashboards that are available out of the box or that can be [easily configured](https://docs.gitlab.com/ee/user/project/insights/#configure-your-insights) based on a user's labeling workflow.\n\nAll of the Insights dashboards within GitLab are [driven by a YAML file](https://gitlab.com/gitlab-org/quality/insights-config/-/blob/master/.gitlab/insights.yml). The configuration for each chart includes configuration parameters: title, type, and query.\n\nThe query section defines the type of issues and/or merge requests from the issue tracker that will be included in the chart. The [parameters for which labels are contained in the chart](https://docs.gitlab.com/ee/user/project/insights/#queryfilter_labels) fall under the query section as well.\n\n\"The Insights configuration is actually stored in [one of your project's repositories]. So, it can be changed just like you do any of your code. It can be [version-controlled](/topics/version-control/) so you can see changes over time. That gives you a lot of value to just ensure that there's very clear traceability into why was this dashboard changed, and when was it changed,\" says Kyle.\n\nHere is the configuration that underlies the [MR throughputs dashboard](https://gitlab.com/groups/gitlab-org/-/insights/#/throughputs) we looked at extensively in the section above.\n\n```\nthroughputs:\n  title: Merge Request Throughputs (product only projects)\n  charts:\n    - title: Throughputs per Week\n      type: stacked-bar\n      query:\n        issuable_type: merge_request\n        issuable_state: merged\n        collection_labels:\n          - Community contribution\n          - security\n          - bug\n          - feature\n          - backstage\n        group_by: week\n        period_limit: 12\n    - title: Throughputs per Month\n      type: stacked-bar\n      query:\n        issuable_type: merge_request\n        issuable_state: merged\n        collection_labels:\n          - Community contribution\n          - security\n          - bug\n          - feature\n          - backstage\n        group_by: month\n        period_limit: 24\n```\n{: .language-ruby}\n\nExplore the [Insights YAML file for GitLab](https://gitlab.com/gitlab-org/gitlab-insights/blob/master/.gitlab/insights.yml) to see how we set up some of our other charts.\n\n## How we are dogfooding Insights\n\nInsights is most effective at monitoring high-level trends, as well as measuring performance against a specific measurable objective with the aim of taking corrective action. At GitLab, we've been using our Insights technology in different ways to visualize our overall performance or to answer specific questions.\n\nOur Support and Quality Engineering teams at GitLab currently use Insights, but in different ways. By dogfooding the technology here at GitLab, we've found numerous use cases for Insights that could be valuable to our customers.\n\n### How our Support team uses Insights\n\nThe Support team uses Insights both as an out of the box issue tracking dashboard and as a customized dashboard made possible using automation.\n\n#### Bugs SLO chart\n\nThe [Bugs SLO dashboard](https://gitlab.com/gitlab-org/gitlab/insights/#/bugsPastSLO) was created so the Support department and engineering leaders can identify bugs overdue from SLO.\n\n![Support team Bugs SLO chart](https://about.gitlab.com/images/blogimages/bugs_slo.png){: .shadow.medium.center}\nA chart specially configured for the Support team to show how many bugs missed the SLO each month.\n{: .note.text-center}\n\nThe Bugs SLO chart is configured in the GitLab-org group but lives in the GitLab project. The chart pulls open issues pertaining to bugs and customer bugs, that are labeled `missed-SLO` and groups them by month. We also have a [labeling system for categorizing based on priority](https://docs.gitlab.com/ee/development/labels/index.html#priority-labels) – P1 bugs are top priority, P2 bugs are second priority.\n\n\"This really allows us to, again, look at the trends: Are we improving? Are we getting worse? Do we need to look a little bit deeper here and do a corrective action to help address any problems that we see within the trends that Insights provides?\" says Kyle.\n\n#### Configuration of SLO chart\n\nHere is a peek at what happens inside the YAML file to configure the bugs SLO chart.\n\n```\nbugsPastSLO:\n  title: Bugs Past SLO\n  charts:\n    - title: Open bugs past priority SLO by creation month\n      type: stacked-bar\n      query:\n        issuable_type: issue\n        issuable_state: opened\n        filter_labels:\n          - bug\n          - missed-SLO\n        collection_labels:\n          - P1\n          - P2\n        group_by: month\n        period_limit: 24\n    - title: Open customer bugs past priority SLO by creation month\n      type: stacked-bar\n      query:\n        issuable_type: issue\n        issuable_state: opened\n        filter_labels:\n          - bug\n          - missed-SLO\n          - customer\n        collection_labels:\n          - P1\n          - P2\n        group_by: month\n        period_limit: 24\n```\n{: .language-ruby}\n\n#### Triage helps ensure good label hygiene\n\nFor the Bugs SLO chart, we use the [GitLab triage project](https://gitlab.com/gitlab-org/gitlab-triage) to [automatically apply the `missed-SLO` label to open issues with priority labels that miss the SLO target](/handbook/engineering/quality/triage-operations/#missed-slo). We use automation here because the GitLab project is so massive, it would not be feasible to manually apply this label based upon the missed SLO target rules. Insights is flexible enough that either manual labeling or automation can be used on any dashboard.\n\n### Support issue tracker\n\nThe Support team used one of our out of the box dashboards to [see how many Support issues are open and closed per month](https://gitlab.com/gitlab-com/support-forum/insights/#/issues) with the [GitLab.com Support Tracker project](https://gitlab.com/gitlab-com/support-forum), which looks at support issues raised by GitLab.com users that don't go through the Support team.\n\n![Support issue tracker](https://about.gitlab.com/images/blogimages/support_issue_tracker.png){: .shadow.medium.center}\nThe Support team also uses one of our out of the box dashboards that tracks the number of issues open and closed each month.\n{: .note.text-center}\n\n\"This shows that [the dashboard] is quite useful out of the box to just see some visualizations without doing any configuration,\" says Mark. \"These were the charts that we thought would give the most value to a team or to a project without doing any config whatsoever.\"\n\n## How our Quality Engineering team uses Insights\n\nThe Quality Engineering team uses Insights to look at opportunities to remedy gaps in a specific project in our EE, as well as to visualize flaky tests on GitLab based on reported issues.\n\n### Enterprise Edition testcases chart\n\nOne of our more specific use cases is the Enterprise testcases chart. The Quality Engineering department is working to close the gap in testcases in the GitLab Enterprise. The team [configured a chart](https://gitlab.com/gitlab-org/quality/testcases/insights/#/eeTestcasesCharts) within the [testcases project](https://gitlab.com/gitlab-org/quality/testcases/tree/master) to help visualize how many open and closed test gaps there are, separated by GitLab product area, and GitLab product tier.\n\n![EE testcases chart](https://about.gitlab.com/images/blogimages/EE_testcases.png){: .shadow.medium.center}\nQuality Engineering configured this chart to visualize gaps in testcases on GitLab Enterprise.\n{: .note.text-center}\n\n\"Looking at this chart, we may say, ‘Maybe we should have a few people focus on the gaps in verify because it has the most open testcases at the current point',\" says Kyle.\n\n#### Configuration of EE testcases chart\n\nThe EE testcases chart is not something that is available out of the box, but the [configuration for the chart](https://gitlab.com/gitlab-org/quality/testcases/blob/master/.gitlab/insights.yml) is pretty simple nonetheless.\n\n```\neeTestcasesCharts:\n  title: 'Charts for EE Testcases'\n  charts:\n    - title: Open testcases (backlog) by stage\n      type: bar\n      query:\n        issuable_type: issue\n        issuable_state: opened\n        filter_labels:\n          - \"Quality:EE test gaps\"\n        collection_labels:\n          - \"devops::configure\"\n          - \"devops::create\"\n          - \"devops::protect\"\n          - \"devops::enablement\"\n          - \"devops::growth\"\n          - \"devops::manage\"\n          - \"devops::monitor\"\n          - \"devops::package\"\n          - \"devops::plan\"\n          - \"devops::release\"\n          - \"devops::secure\"\n          - \"devops::verify\"\n```\n{: .language-ruby}\n\nThe configuration shows that this is a bar chart that is looking at open issues with the filter `Quality:EE test gaps`. The collection labels are what broke the bars out into different columns. While it is possible to illustrate the data in very intricate ways, the underlying schema to configure the chart is actually quite simple, mirroring the process of searching the issue tracker by filtering based on labels.\n\n![Issue tracker](https://about.gitlab.com/images/blogimages/issue_tracker_EE.png){: .shadow.medium.center}\nThe issues represented in the EE testcases chart can be searched for by label using the issue tracker in the testcases project.\n{: .note.text-center}\n\nOpening the issue tracker for the testcases project, you can search by `Quality:EE test gaps` label, select open issues, to see the actual issues represented by the Insights chart.\n\nThe key takeaway: If your team has good label hygiene and a logical workflow, building charts based on Insights should not be particularly challenging.\n\n### End-to-end transient failures\n\nThe Quality Engineering team monitors how often we have reports of flaky tests in our pipeline by looking at the number of issues created that fit the label schema.\n\n![End-to-end transient failure chart](https://about.gitlab.com/images/blogimages/end_to_end_chart.png){: .shadow.medium.center}\nA second chart configured for Quality Engineering is the end-to-end transient failure chart, which looks at flaky tests.\n{: .note.text-center}\n\nSimilar to many of our other charts, this is a stacked bar graph that looks at both open and closed issues on a weekly basis, and the underlying configuration is as you might expect.\n\n```\ntransientFailures:\n  title: End to end transient failures\n  charts:\n    - title: Opened transient failures per week\n      type: stacked-bar\n      query:\n        issuable_type: issue\n        issuable_state: opened\n        filter_labels:\n          - \"Quality\"\n          - \"QA\"\n          - \"bug\"\n        collection_labels:\n          - \"found:gitlab.com\"\n          - \"found:canary.gitlab.com\"\n          - \"found:staging.gitlab.com\"\n          - \"found:staging-orchestrated\"\n          - \"found:dev.gitlab.com\"\n          - \"found:nightly\"\n          - \"found:in MR\"\n        group_by: week\n        period_limit: 24\n    - title: Closed transient failures per week\n      type: stacked-bar\n      query:\n        issuable_type: issue\n        issuable_state: closed\n        filter_labels:\n          - \"Quality\"\n          - \"QA\"\n          - \"bug\"\n        collection_labels:\n          - \"found:gitlab.com\"\n          - \"found:canary.gitlab.com\"\n          - \"found:staging.gitlab.com\"\n          - \"found:staging-orchestrated\"\n          - \"found:dev.gitlab.com\"\n          - \"found:nightly\"\n          - \"found:in MR\"\n        group_by: week\n        period_limit: 24\n```\n{: .language-ruby}\n\n## Implementing Insights for your team\n\nIf your team is often pulling data from GitLab through an API or CSV export, and then building charts based on issues and merge request data, then Insights will make your life a lot easier!\n\nSome questions to think about before implementing Insights include: How would you want to categorize the work being done and the issues that are being created? How do you want to monitor the open/close rates on your issues? Also, how do you plan on using labels?\n\nInsights users really need to define their workflows and have a clear idea about how they're using labels. We recommend having some sort of [automated mechanism to ensure good label hygiene](/handbook/engineering/quality/triage-operations/#triage-automation). [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) is our open source project that automates labeling of issues on our giant GitLab project and is a good candidate for any organization that has a large backlog of issues.\n\nWe recommend users [read up more on the issues workflow](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html) to learn more about how to use labels and the issue tracker, which is valuable background knowledge to improve your use of Insights.\n\nWe've been dogfooding Insights for a time to help iron out any wrinkles in the implementation or application of this technology, but we also want to hear your ideas of how we can make improvements to Insights. [Create an issue in the GitLab project issue tracker](https://gitlab.com/gitlab-org/gitlab/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=insights) with the Insights label to share your feedback with us!\n\nCover photo by [Aaron Burden](https://unsplash.com/@aaronburden) on [Unsplash](https://unsplash.com/photos/Qy-CBKUg_X8).\n{: .note.text-center}\n",[9,851,680],{"slug":1249,"featured":6,"template":683},"content:en-us:blog:insights.yml","Insights","en-us/blog/insights.yml","en-us/blog/insights",{"_path":4058,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4059,"content":4065,"config":4072,"_id":4074,"_type":13,"title":4075,"_source":15,"_file":4076,"_stem":4077,"_extension":18},"/en-us/blog/integration-management",{"title":4060,"description":4061,"ogTitle":4060,"ogDescription":4061,"noIndex":6,"ogImage":4062,"ogUrl":4063,"ogSiteName":670,"ogType":671,"canonicalUrls":4063,"schema":4064},"Integration management for git projects","Read here on how GitLab offers the tools for managing integrations for your projects!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667194/Blog/Hero%20Images/2020-11-19-integration-management-header.jpg","https://about.gitlab.com/blog/integration-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Integration management for git projects\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Deuley\"},{\"@type\":\"Person\",\"name\":\"Taurie Davis\"}],\n        \"datePublished\": \"2020-11-19\",\n      }",{"title":4060,"description":4061,"authors":4066,"heroImage":4062,"date":4069,"body":4070,"category":678,"tags":4071},[4067,4068],"Patrick Deuley","Taurie Davis","2020-11-19","GitLab is a complete platform for the entire [DevOps lifecycle](/topics/devops/), but some users and organizations already have a specific tool they must use for certain parts of their workflow. **Over 4.5 million projects have configured integrations** and hundreds of thousands more are added each month. User utilize integration management to connect a wide array of applications such as Slack, Jira, Prometheus, and more – plugging critical parts of their chosen stack into GitLab.\n\nOne of the core design concepts of GitLab as a product is that a single application serves our users best. However, for users who have made specific choices about certain tools in their workflow, the inverse is also true: a disjointed toolchain where your tools are not connected at all is _the worst possible experience_. If you are going to have separate tools in your DevOps toolchain (which is fine!), they need to at least be sitting next to each other.\n\nBefore GitLab 13.3, project integrations were managed only at the project level. This meant that if you had 400 projects, you'd have to configure that integration 400 times!\n\n**In GitLab 13.3, we added the ability to add an integration across an entire GitLab instance, for all projects. In GitLab 13.6 (coming Nov. 22, 2020), we’re expanding this ability to work at the group level as well.**\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6mz1y15JEHE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Integration management for large organizations integrating third-party applications with their GitLab projects!\n\nA group _with any number of projects in it_ can integrate them all at once, from a single place. Group owners and instance administrators rejoice! This will save you hours and hours of work managing all of those connections and keeping them up to date.\n\nThere are also security benefits to this approach: instance administrators and group owners can roll out an integration without having to share the credentials with each project owner directly. This is a great security enhancement because many organizations had to restrict configuration to a small group of people, requiring them to do a ton of busywork just to maintain this posture.\n\nGroup-level Integration Management is available **today, for free**, on both [GitLab.com](https://gitlab.com) and in self-managed GitLab installations running 13.6 and up.\n\nFor more information, check out the documentation for [Project Integration Management](https://docs.gitlab.com/ee/administration/settings/project_integration_management.html).\n\n## So what’s next for Project Integration Management?\n\nWe’re also looking to expand this feature with more bells and whistles to make the lives of our instance administrators and group owners easier. Some things that we're considering for the future are:\n\n- [**Inheritance overviews**](https://gitlab.com/gitlab-org/gitlab/-/issues/14157), which will show what projects are overriding the inherited settings\n- **Per-field inheritance** that overrides only a single field while leaving the rest of the settings managed by the parent\n- **Field masking**, which allows the group or instance owner to obfuscate specific fields that are inheritable, while still allowing the integration to work\n- **Inheritance locking**, giving group or instance owners the ability to enforce those settings on every project under them\n- **Service Template migrations**, giving users of Service Templates an easy way to migrate to this new feature and roll the change out to every project where it’s applicable\n\nIf you have any feedback, ideas for future features, input, or requirements for items on the roadmap, or anything else – please leave comments [in the parent epic for this feature](https://gitlab.com/groups/gitlab-org/-/epics/2137).\n\n### Upcoming Service Template deprecation\n\nFormerly, [Service Templates](https://docs.gitlab.com/ee/user/admin_area/settings/project_integration_management.html) filled this particular need in GitLab, with many limitations. These templates were applied only to new projects, and if you updated a value on the template, it didn’t retroactively apply to each project that already used those settings.\n\nThis solves half the problem by allowing the _initial settings of an integration_ to be defined for many projects in one place, but failed to help with actually managing those integrations later. Because the ongoing management is just as important as the setup, we saw some organizations writing custom scripts to continuously validate that those settings hadn’t changed, and automations to roll out changes to many projects at once. These examples are glue code that they should never have needed to write in the first place, let alone make them maintain over time. Our hope is that this new feature suits those use cases perfectly, and that migrating from Service Templates to integrations managed at the group level dramatically reduces their maintenance overhead.\n\nWe are currently planning on [deprecating Service Templates](https://gitlab.com/gitlab-org/gitlab/-/issues/268032) during our normal deprecation cycle (only in major releases), in GitLab 14.0.\n\n#### More GitLab integrations\n\n- [Get the most out of the Checkmarx integration with GitLab](/blog/checkmarx-integration/)\n- [Is DevOps for designers?](/blog/is-devops-for-designers/)\n- [Demo: GitLab + Jira + Jenkins](/blog/gitlab-workflow-with-jira-jenkins/)\n\nCover image by [Ryan Quintal](https://unsplash.com/photos/US9Tc9pKNBU) on [Unsplash](https://unsplash.com)\n{: .note}\n",[9,230,678],{"slug":4073,"featured":6,"template":683},"integration-management","content:en-us:blog:integration-management.yml","Integration Management","en-us/blog/integration-management.yml","en-us/blog/integration-management",{"_path":4079,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4080,"content":4086,"config":4091,"_id":4093,"_type":13,"title":4094,"_source":15,"_file":4095,"_stem":4096,"_extension":18},"/en-us/blog/interview-the-open-group",{"title":4081,"description":4082,"ogTitle":4081,"ogDescription":4082,"noIndex":6,"ogImage":4083,"ogUrl":4084,"ogSiteName":670,"ogType":671,"canonicalUrls":4084,"schema":4085},"Get to know our newest open source partner, The Open Group","The Open Group leaders explain how the organization uses GitLab to build and maintain open standards for transformative digital technologies.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679170/Blog/Hero%20Images/migration-data.jpg","https://about.gitlab.com/blog/interview-the-open-group","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get to know our newest open source partner, The Open Group\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-06-20\",\n      }",{"title":4081,"description":4082,"authors":4087,"heroImage":4083,"date":4088,"body":4089,"category":827,"tags":4090},[3504],"2023-06-20","\n\nFor more than 30 years, [The Open Group](https://www.opengroup.org/) has served as a steward and champion of [open source](https://go.gitlab.com/spHNym) technologies, helping companies achieve business objectives through [open technological standards](http://www.opengroup.org/standardsprocess/main.html). Today, many of the group's approximately 900 member organizations participate in the work of ensuring critical digital technologies remain open and accessible.\n\nThe Open Group recently joined the [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) community, where it can connect with other large-scale, open source consortia and projects using GitLab to advance the state of the open source art. So I brewed a cup of tea and sat down with two of the group's team members — Vice President and CTO [Andras Szakal](https://pages.opengroup.org/aszakal) and GitLab administrator [David Diederich](https://pages.opengroup.org/divido) — to hear how using GitLab helps them achieve their group's mission. \n\nIn this interview, you'll learn how:\n\n* [GitLab CI/CD](https://about.gitlab.com/features/continuous-integration) helps the group build scalable open source projects\n* adopting GitLab's integrated analysis tools helped the organization deploy complex solutions without the [DevOps tax](https://about.gitlab.com/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer/#eliminating-the-devops-tax)\n* GitLab serves as the foundation of the organization's approach to digital transformation\n\n## Watch the interview\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0--qGhH-MBQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n",[1187,266,9],{"slug":4092,"featured":6,"template":683},"interview-the-open-group","content:en-us:blog:interview-the-open-group.yml","Interview The Open Group","en-us/blog/interview-the-open-group.yml","en-us/blog/interview-the-open-group",{"_path":4098,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4099,"content":4105,"config":4111,"_id":4113,"_type":13,"title":4114,"_source":15,"_file":4115,"_stem":4116,"_extension":18},"/en-us/blog/introducing-accessibility-testing-in-gitlab",{"title":4100,"description":4101,"ogTitle":4100,"ogDescription":4101,"noIndex":6,"ogImage":4102,"ogUrl":4103,"ogSiteName":670,"ogType":671,"canonicalUrls":4103,"schema":4104},"Introducing Accessibility Testing in GitLab","How Accessibility Testing reinforces our value that everyone can contribute","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666941/Blog/Hero%20Images/accessibility-vision.jpg","https://about.gitlab.com/blog/introducing-accessibility-testing-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing Accessibility Testing in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"James Heimbuck\"}],\n        \"datePublished\": \"2020-03-04\",\n      }",{"title":4100,"description":4101,"authors":4106,"heroImage":4102,"date":4108,"body":4109,"category":1353,"tags":4110},[4107],"James Heimbuck","2020-03-04","\n{::options parse_block_html=\"true\" /}\n\nGitLab has introduced continuous accessibility testing with the 12.8 release. This post adds some context to the [release post](/releases/2020/02/22/gitlab-12-8-released/#automated-accessibility-scanning-of-review-apps) and introduces our vision for accessibility testing going forward.\n\n## Why isn't everyone doing accessibility testing?\n\nOne of the core tenets of the vision of GitLab is that [everyone can contribute](https://about.gitlab.com/company/vision/#vision). We also firmly believe that GitLab should be accessible to everyone and projects created with GitLab should as well. To better realize this we have introduced Accessibility Testing as a new feature in GitLab 12.8.\n\nIn talking to developers, and even my own colleagues, I have been surprised about how many people around me are color blind and have realized how easy this is to overlook. In fact, 8% of the United States male population is color blind, and this is just one kind of visual impairment that may impact a web site's readability. Take for instance the classic North American color indicators for Go / Stop or Good / Bad - Red and Green. An example of the GitLab pipeline page is shown below as users without and with protanopia would see the page. GitLab does make use of differing icons and wording as indicators of a pipeline's status, but the difference is striking.\n\n![Pipelines page](https://about.gitlab.com/images/blogimages/accessibility_direction/pipelines.png){: .shadow}\nHow the Pipelines page appears to users without Protanopia\n{: .note.text-center}\n\n![Pipelines with Protanopia](https://about.gitlab.com/images/blogimages/accessibility_direction/pipelines-with-protanopia.png){: .shadow}\nHow the Pipelines page appears to users with Protanopia\n{: .note.text-center}\n\nAs we dug into the problem with developers we found two common themes:\n1.  Accessibility testing is done late in the development lifecycle, often on a Release Candidate, when it is too late to make changes.\n1.  Accessibility testing is becoming more important across organizations.\n\n## Why is accessibility testing a hot topic?\n\nPizza. More specifically one persons ability to [customize a pizza](https://www.usatoday.com/story/money/2019/10/07/dominos-pizza-website-accessibility-supreme-court-wont-hear-case/3904582002/). While some companies may see accessibility testing as a defensive move to prevent law suits we see it a different way at GitLab. We want to build software for everyone and we want to build it quickly. Providing developers a mechanism to improve the accessibility of their software for all users is just the right thing to do.\n\n## How is GitLab solving this problem?\n\nWith the [12.8 release](/releases/2020/02/22/gitlab-12-8-released/#automated-accessibility-scanning-of-review-apps) GitLab has introduced accessibility scanning in the Core product. By including the Accessibility template to your .gitlab-ci.yml file and providing a URL the accessibility scan can be run on every merge request that includes that job. \n\n```yaml\ninclude:\n  template: Verify/Accessibility.gitlab-ci.yml\n\na11y:\n  variables:\n    a11y_urls: https://example.com\n```\n\nThe example above is from the [documentation](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html) which includes some additional details. \n\nIn the current version of the feature the result is a simple HTML report that outlines the issues with the Review App as identified by the scanner, which uses the [W2CAGAA standards](https://www.w3.org/TR/WCAG20/). We recognize that this is just a small step in making software more accessible but we are excited about the future.\n\nFuture iterations and improvements in GitLab we will be working on for a11y testing include:\n* [Identify and scan only changed pages](https://gitlab.com/gitlab-org/gitlab/issues/207383)\n* [Display newly introduced issues in the Merge Request view](https://gitlab.com/gitlab-org/gitlab/issues/39425)\n* [Display the full a11y report in GitLab](https://gitlab.com/gitlab-org/gitlab/issues/36170)\n\nThis is not a comprehensive list by any means and you can send suggestions for improvements or follow along as the category matures on the Accessibility Testing direction page.\n\nPhoto by [Matt Noble](https://unsplash.com/@mcnoble) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[108,9],{"slug":4112,"featured":6,"template":683},"introducing-accessibility-testing-in-gitlab","content:en-us:blog:introducing-accessibility-testing-in-gitlab.yml","Introducing Accessibility Testing In Gitlab","en-us/blog/introducing-accessibility-testing-in-gitlab.yml","en-us/blog/introducing-accessibility-testing-in-gitlab",{"_path":4118,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4119,"content":4124,"config":4131,"_id":4133,"_type":13,"title":4134,"_source":15,"_file":4135,"_stem":4136,"_extension":18},"/en-us/blog/introducing-achievements-system",{"title":4120,"description":4121,"ogTitle":4120,"ogDescription":4121,"noIndex":6,"ogImage":1387,"ogUrl":4122,"ogSiteName":670,"ogType":671,"canonicalUrls":4122,"schema":4123},"Introducing the GitLab Achievements feature","Boost engagement among your employees and community with achievements.","https://about.gitlab.com/blog/introducing-achievements-system","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing the GitLab Achievements feature\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Veenhof\"},{\"@type\":\"Person\",\"name\":\"Christina Lohr\"}],\n        \"datePublished\": \"2023-06-05\",\n      }",{"title":4120,"description":4121,"authors":4125,"heroImage":1387,"date":4128,"body":4129,"category":678,"tags":4130},[4126,4127],"Nick Veenhof","Christina Lohr","2023-06-05","\n\nAchievements have been a popular tool for gamification in various contexts, from social media platforms to educational institutions. It's also known to be a great recognition method for open source community contributors, of which GitLab has many. Recently, we introduced a new feature that allows organizations to award achievements to their GitLab users. This feature has the potential to increase engagement and productivity within technical organizations. Let us show you how.\n\nAchievements are a way to reward users for their activity on GitLab. As a namespace maintainer or owner, you can create custom achievements for specific contributions, which you can award to or revoke from users based on your criteria. For GitLab specifically, there were already many forms of recognition available for our community, such as leaderboards for our hackathons, swag that is sent out as a token of gratitude, etc. However, there was no single place to get an overview of these achievements. This led to a broader investigation into how we could empower not just the GitLab contributor community, but also our large user base, both on SaaS and self-hosted.\n\nSo far, we've awarded achievements to all our GitLab [Core Team](https://about.gitlab.com/community/core-team/) members and also to the winners of our most recent [hackathon](/community/hackathon/). Congratulations to all winners and our core members. You deserve these awards! We have a lot more ideas to award our wider community for their achievements, so stay tuned if you are an active contributor to GitLab.\n\n![Achievements on a GitLab user profile](https://about.gitlab.com/images/blogimages/achievements_on_user_profile.png){: .shadow}\n\n## Benefits of achievements\nBy using achievements in your organization you can start to create a culture of continuous learning and skill development. The options are limitless, from rewarding users for touching a new piece of the codebase to rewarding users that have proven to be exceptionally collaborative. Receiving an achievement can be a powerful motivator for an employee. It shows that their work is valued and recognized by their peers and supervisors. Awarding your users for obtaining a skill could lead to a more skilled workforce, which benefits both the employee and the organization.\n\nIf rolled out well, it can create a flywheel effect in your organization, leading to a competitive advantage in the market due to increased innovation and a faster cycle time. \n\nDon't believe us on our merit, start to implement [achievements](https://docs.gitlab.com/ee/user/profile/achievements.html) to reward your contributors.\n\n## How to start to use achievements\nAchievements are generally available for all tiers, both SaaS and self-hosted. See the [achievements documentation](https://docs.gitlab.com/ee/user/profile/achievements.html#achievements-experiment) to learn how to create, delete, award, and revoke achievements.\n\nIf you are an organization using GitLab, consider implementing achievements within GitLab to start rewarding behavior that drives your organization's goals.\n\nLet us know what you think in this [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/405153).\n",[266,9,678],{"slug":4132,"featured":6,"template":683},"introducing-achievements-system","content:en-us:blog:introducing-achievements-system.yml","Introducing Achievements System","en-us/blog/introducing-achievements-system.yml","en-us/blog/introducing-achievements-system",{"_path":4138,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4139,"content":4145,"config":4150,"_id":4152,"_type":13,"title":4153,"_source":15,"_file":4154,"_stem":4155,"_extension":18},"/en-us/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate",{"title":4140,"description":4141,"ogTitle":4140,"ogDescription":4141,"noIndex":6,"ogImage":4142,"ogUrl":4143,"ogSiteName":670,"ogType":671,"canonicalUrls":4143,"schema":4144},"How autoscaling GitLab CI works on AWS Fargate","Run your CI jobs as AWS Fargate tasks with GitLab Runner and the Fargate Driver","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681285/Blog/Hero%20Images/runner-autoscale-fargate-blog-cover.jpg","https://about.gitlab.com/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How autoscaling GitLab CI works on AWS Fargate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Eastman\"}],\n        \"datePublished\": \"2020-05-11\",\n      }",{"title":4140,"description":4141,"authors":4146,"heroImage":4142,"date":4147,"body":4148,"category":849,"tags":4149},[1392],"2020-05-11","\n\nAutoscaling GitLab Runner is a unique value proposition for teams that run their self-managed build agents on cloud-hosted virtual machines. As the number of [CI/CD jobs](/topics/ci-cd/) run over a specific period can fluctuate, teams must have build agent auto-scaling solutions in place that are easy to set up, configure, and cost-efficient.  \n\nGitLab Runner [autoscaling](https://docs.gitlab.com/runner/configuration/autoscale.html) responds to demand by provisioning new cloud-hosted virtual machines with Docker and GitLab Runner. When demand is lower, any additional virtual machines above the configured minimum size are de-provisioned. However, while this model of automatically provisioning and terminating virtual machine instances continues to be useful for a vast plethora of use cases, customers also want to take advantage of the capabilities of cloud container orchestration solutions for executing GitLab CI/CD jobs. For some, adopting GitLab's Kubernetes integration for AWS Elastic Kubernetes Service and Google Kubernetes Engine has allowed them to take advantage of the benefits of containerized pipelines. For others, AWS Fargate has proven to be a compelling container orchestration solution, as it simplifies the process of launching and managing containers on AWS services ECS and EKS.\n\nWe are pleased to announce that as of the [12.10](/releases/2020/04/22/gitlab-12-10-released/) release, you can now auto-scale GitLab CI jobs on AWS Fargate managed containers.\n\n![](https://about.gitlab.com/images/blogimages/autoscaling-runners-ci-ecs-fargate.png)\n\n## So how does it work? \n\nIn GitLab 12.1, we released the GitLab Runner [Custom executor](https://docs.gitlab.com/runner/executors/custom.html). With the custom executor, you can create drivers for GitLab Runner to execute a job on technology or a platform that is not supported natively. To enable executing GitLab CI jobs on AWS Fargate, we developed a [GitLab AWS Fargate driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate) for the Custom executor.  This driver uses the AWS Fargate `run-task` action to schedule a new task. A task in ECS is an instance of a task definition that runs the container or containers defined within the task definition. In this containerized solution for CI builds, the pipeline job executes on a container built from an image that must include the tools that you need to build your application.\n\nThe AWS Fargate Driver works in conjunction with GitLab Runner, a lightweight executable that executes pipeline jobs. Similar to the GitLab Runner executable, a `config.toml` file is the file used to pass configuration parameters to the driver. The AWS Fargate driver divides the CI job into the following stages.\n\n1. Config\n1. Prepare\n1. Run\n1. Cleanup\n\n## SSH connectivity\n\nFor the Fargate Driver to execute build commands in the container that is running as a task on ECS, the driver needs to be able to SSH into the container. So we have built additional capabilities into the driver to allow for a SSH connection between the GitLab Runner + AWS Fargate driver and the CI build container. \n\n![Fargate Driver SSH Connectivity](https://about.gitlab.com/images/blogimages/runner_fargate_driver_ssh.png)\n\n## Limitations\n\nAWS Fargate does not support running containers in privileged mode. For example, Docker-in-Docker (DinD), which enables the building and running of container images inside of containers, does not work on Fargate. In keeping with one of GitLab's core values, iteration, we will continue to iterate on solutions for this problem. So stay tuned for future enhancements.\n\n## Getting Started\n\nTo get started, review our detailed [configuration and setup guide.](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws_fargate/index.html)\n\nWith the release of the GitLab Runner AWS Fargate driver, we provide the most diverse set of options in the industry for executing CI pipeline jobs in an autoscaling configuration. These options now include cloud-delivered virtual machines, AWS EC2, Google GCP, Azure Compute, and container orchestration platforms: AWS EKS, AWS ECS + Fargate, and Google Kubernetes. Our long term goal is to provide the best and most comprehensive solution for executing CI jobs at scale on the major cloud platforms.\n\n\nCover image by [Alessio Lin](https://unsplash.com/@lin_alessio) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[108,9,2018],{"slug":4151,"featured":6,"template":683},"introducing-autoscaling-gitlab-runners-on-aws-fargate","content:en-us:blog:introducing-autoscaling-gitlab-runners-on-aws-fargate.yml","Introducing Autoscaling Gitlab Runners On Aws Fargate","en-us/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate.yml","en-us/blog/introducing-autoscaling-gitlab-runners-on-aws-fargate",{"_path":4157,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4158,"content":4163,"config":4168,"_id":4170,"_type":13,"title":4171,"_source":15,"_file":4172,"_stem":4173,"_extension":18},"/en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation",{"title":4159,"description":4160,"ogTitle":4159,"ogDescription":4160,"noIndex":6,"ogImage":759,"ogUrl":4161,"ogSiteName":670,"ogType":671,"canonicalUrls":4161,"schema":4162},"Introducing CI/CD Steps, a programming language for DevSecOps automation","Inside GitLab’s vision for CI/CD programmability and a look at how we simplified workflow automation.","https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing CI/CD Steps, a programming language for DevSecOps automation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darren Eastman\"}],\n        \"datePublished\": \"2024-08-06\",\n      }",{"title":4159,"description":4160,"authors":4164,"heroImage":759,"date":4165,"body":4166,"category":701,"tags":4167},[1392],"2024-08-06","For years, the DevOps industry has tried to simplify how developers create automation scripts or workflows to automatically test a code change and to perform a task with the resulting artifact or binary. Today, we are introducing [CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/), a programming language for DevSecOps automation in experiment phase, as a solution to this challenge. With CI/CD Steps, software development teams can easily create complex automation workflows within GitLab.\n\n## The path to CI/CD Steps\n\nEarly in the company's history, GitLab founders and engineers decided that there must be a tight integration between source code management, the place you store your code, and continuous integration, the automation workflows that test your code changes. And we've continued to evolve that integration, focusing on workflow automation tasks and differentiating from the approaches of CI engines across the industry, including Jenkins CI's domain-specific language, GitHub Actions, and many more. \n\nAnd, yes, I did mean to use the term workflow automation tasks rather than [CI and continuous deployment (CD)](https://about.gitlab.com/topics/ci-cd/). This is simply a result of the code that I have seen our customers develop. In a lot of cases, the platform engineering teams that support development teams using GitLab are writing complex automation scripts (workflows). So we need to embrace a more expansive construct beyond simply CI and CD. In fact, I have seen some developers rave about the flexibility of new CI/CD solutions that allow for modularity and conditionals in writing automation workflows.\n\nAt GitLab, our initial approach for CI authoring was based on YAML. We can endlessly debate the pros and cons of such a choice, but for me, as a [DevOps](https://about.gitlab.com/topics/devops/) practitioner coming from a large Fortune 50 company with a moshpit of Jenkins Groovy code and hundreds of permutations of scripts basically performing the same job, the GitLab CI authoring and execution approach was a breath of fresh air. \n\nThe first time I read a GitLab CI file – this was back in mid-2019 – my first thought was, \"No, it could not be that simple.\" A non-developer can easily grasp the intent of a basic GitLab CI pipeline without prior knowledge of all of the intricacies of the syntax of the execution model. In fact, I had just spent a year working on a team that spent several hours each day helping other development teams debug Jenkins pipelines written in Groovy and trying to figure out how to test, and in some cases build, large Java monoliths; in other cases, tons of microservices.\n\nWhile there are benefits to a GitLab CI YAML-based authoring and a bash script execution type approach, there are also limitations. Limitations that developers or platform engineers bump into as they integrate more complex workflows into their CI pipelines. These issues seem to be amplified at enterprise scale as platform teams are trying to simplify or standardize workflows across multiple development teams. In fact, one of the quotes from a recent customer survey states: “GitLab needs to embrace a post-YAML world for CI.”\n\nSo, over the past two years, our pipeline authoring team, led by Product Manager [Dov Hershkovitch](https://gitlab.com/dhershkovitch), has been working extensively on improving the pipeline authoring experience. They've also been improving the management experience of the building blocks for workflow automation – especially at scale. In fact, a part of this work, the [GitLab CI/CD Catalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/), recently became generally available.\n\nThe logical next step was to build a new language for workflow automation.\n\n## Understanding CI/CD Steps\n\nGitLab CI/CD Steps is a concept incubated by our top-notch engineers. In [our documentation](https://docs.gitlab.com/ee/ci/steps/), we describe CI/CD Steps as reusable and composable pieces of a CI job that can be referenced in a GitLab CI pipeline configuration. But what does that really mean and what is the long-term value proposition?\n\nAs I was giving this some thought, a comment from one of our customers (paraphrased here) came to mind:\n\n“CI/CD Steps enables you to compose inputs and outputs for a CI/CD job. With CI/CD Steps, developers can define inputs and outputs and, therefore, use CI/CD Steps as a function as we do in any modern programming language. A key differentiator to a normal CI/CD component is that CI/CD Steps allows the use of the outputs of other steps without GitLab having to know certain values before running the pipeline. With CI/CD Steps, you could more easily auto-cancel redundant jobs when all jobs are running as part of the parent pipeline versus having to use child pipelines.”\n\nHaving CI/CD Steps alongside the current GitLab CI/CD execution mechanism and the [CI/CD component catalog](https://docs.gitlab.com/ee/ci/components/index.html) unlocks so many possibilities for creating and maintaining the most complex CI/CD workflows. \n\nA key feature is reusability. Now, I am not suggesting that once we release CI/CD Steps as generally available, you would immediately start refactoring your currently working CI/CD jobs to CI/CD Steps. Instead, you likely will find opportunities to introduce CI/CD Steps to optimize complex pipeline workflows, and, in doing so, you will begin to reuse a CI/CD Step that you author in multiple pipelines.\n\nCI/CD Steps is a marathon, not a sprint. When we release this in beta (currently targeted for late 2024) and start getting feedback from you, we will learn new information that will guide the evolution of this new CI programming language as well as the new Step Runner, which is designed specifically to run CI/CD Steps alongside the current CI/CD jobs.\n\nI'm sure there will be questions about our strategy: Why did we make certain syntax choices? Why didn't we use Starlark as the basis for this new approach? Why did we create something new that we all have to learn? My boilerplate response is: At GitLab we develop our software in the open. More importantly, as a customer, user, and community member, if you have an idea of how to make it better, we invite you to create a merge request so we can improve this feature together.\n\nWe are the only enterprise software platform where, as users and customers, **you** have a direct say in how the platform evolves and **you** can see the changes happening transparently and in real time. That’s the power of GitLab – we iterate and we collaborate. You have invested in a platform and community that is able to evolve with the ever-changing software industry.\n\n## Create your own CI/CD step\n\nTo get a deeper understanding of CI Steps and our direction, take a look at the detailed refactoring proof-of-concept writeup in [this issue](https://gitlab.com/gitlab-org/step-runner/-/issues/85). [Principal engineer Joe Burnett](https://gitlab.com/josephburnett) walks through in great detail the thought process for refactoring a CI/CD job used as part of our GitLab Runner automated test framework. There are also recommendations noted at the end that will inform the evolution of the CI Steps syntax.\n\nThen check out the [CI/CD Steps tutorial](https://docs.gitlab.com/ee/tutorials/setup_steps/) and try creating your own CI/CD step. We recently released the `run` keyword, so testing out a CI/CD step will be simpler than previous examples that required using environment variables. This feature set is experimental so please share your experiences on the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/460057). There also is a separate feedback issue if you are testing the [Run GitHub Actions with CI/CD Steps experimental feature](https://docs.gitlab.com/ee/ci/steps/#actions).\n\nWe look forward to working with you on this journey to continuously improve the GitLab CI/CD authoring experience.\n\n## Read more\n- [CI/CD Catalog goes GA](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)\n- [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n- [What is CI/CD?](https://about.gitlab.com/topics/ci-cd/)\n- [The basics of CI](https://about.gitlab.com/blog/basics-of-gitlab-ci-updated/)\n",[478,108,1397,1396,9],{"slug":4169,"featured":90,"template":683},"introducing-ci-cd-steps-a-programming-language-for-devsecops-automation","content:en-us:blog:introducing-ci-cd-steps-a-programming-language-for-devsecops-automation.yml","Introducing Ci Cd Steps A Programming Language For Devsecops Automation","en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation.yml","en-us/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation",{"_path":4175,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4176,"content":4182,"config":4187,"_id":4189,"_type":13,"title":4190,"_source":15,"_file":4191,"_stem":4192,"_extension":18},"/en-us/blog/introducing-ci-components",{"title":4177,"description":4178,"ogTitle":4177,"ogDescription":4178,"noIndex":6,"ogImage":4179,"ogUrl":4180,"ogSiteName":670,"ogType":671,"canonicalUrls":4180,"schema":4181},"Introducing CI/CD components and how to use them in GitLab","Learn the main benefits for using CI/CD components in your CI/CD pipelines and how to achieve them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667676/Blog/Hero%20Images/buildingblocks.jpg","https://about.gitlab.com/blog/introducing-ci-components","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing CI/CD components and how to use them in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2023-07-10\",\n      }",{"title":4177,"description":4178,"authors":4183,"heroImage":4179,"date":4184,"body":4185,"category":849,"tags":4186},[1454],"2023-07-10","\nWelcome to the third blog in our series on GitLab's CI/CD components! If you haven't already, we encourage you to read \"[How to build reusable CI/CD templates](https://about.gitlab.com/blog/how-to-build-reusable-ci-templates/)\" and \"[Use inputs in includable files](https://about.gitlab.com/blog/use-inputs-in-includable-files/)\" to gain a comprehensive understanding of these exciting new capabilities. In this blog post, we'll dive in and explore the power of GitLab's CI/CD components in revolutionizing CI/CD workflows. We'll also provide a glimpse into the future of GitLab's CI/CD ecosystem, including the upcoming release of the [CI/CD catalog](https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_components/), a framework containing a collection of these components. With these moves, GitLab is taking a significant step towards streamlining pipeline configurations and enhancing reusability.\n\n### CI/CD components\nIn [GitLab 16.1](https://about.gitlab.com/releases/2023/06/22/gitlab-16-1-released/), an exciting experimental feature called CI/CD components was introduced. CI/CD components are reusable, single-purpose building blocks that abstract away pipeline configuration units.\n\nBy leveraging the power of CI/CD components, users can unlock several key benefits:\n1. **Reusability and abstraction.** CI/CD components allow pipelines to be assembled using abstractions instead of defining all the details in one place. With components encapsulating implementation details, developers can focus on composing pipelines using pre-built, reusable blocks. This approach promotes modularity, code reusability, and simplifies pipeline maintenance.\n2. **Flexibility with input.** Components support input parameters, enabling customization based on pipeline contexts, making them adaptable and reusable across various pipeline stages. Developers gain the ability to build a dynamic CI/CD catalog that is tagged and versioned, providing better control and compatibility. Developers can reference specific component versions, ensuring stability and reproducibility. By leveraging version tags, teams can maintain consistency in their pipelines while easily upgrading to newer versions when desired.\n4. **High-quality standards through testing.** Testing components as part of the development workflow to ensure quality maintains high standards is strongly recommended. By incorporating testing into the CI/CD process, developers can verify the reliability and functionality of components, identify and fix issues early on, and deliver more robust and dependable pipelines.\n5. **The CI/CD catalog.** A centralized repository of components, the CI/CD catalog is set to be released soon, and will act as a treasure trove of components curated to cover a wide range of use cases. This centralized repository offers developers a one-stop shop for discovering, integrating, and sharing components. Teams can benefit from a growing catalog of pre-built, quality-tested components, saving time and effort in configuring their pipelines.\n\nIn the previous blog posts, we discussed the main benefits for the first two points (which are also available with CI/CD templates), but now let's dig deeper into components and how they could revolutionize the way you construct your pipelines.\n\n### Testing a CI/CD component\nAs software development continues to evolve, ensuring the reliability and quality of code components becomes increasingly vital.\n\nOne of the main benefits of using components is the ability to thoroughly test components before software is officially released, enabling a more robust and streamlined development process. In our context, a released component is versioned and will follow a structured syntax, allowing for seamless integration within pipelines. \n\n```yaml\ninclude:\n  - components: /path/to/project@\u003Cversion> \n```\nOne of the unique benefits of our CI/CD components is the flexibility they offer. DevSecOps teams can opt in for an \"unofficial\" release by appending `@commit_SHA`, allowing them to experiment and iterate on their code before making it an official release.\n\n```yaml\ninclude:\n  - components: /path/to/project@\u003Ccommit_SHA> \n```\nTo make a component an official release, users must tag it, essentially creating a versioned snapshot. The tagged release will then be made available in our comprehensive CI/CD catalog (launching soon), providing users with easy access to a range of thoroughly tested and approved components. To ensure the stability and reliability of your CI/CD components, it is crucial to thoroughly test them. DevSecOps teams can leverage the power of our pipeline by utilizing the commit_SHA identifier to run comprehensive tests. If the pipeline successfully passes all tests, they can proceed to tag the component, signifying its readiness for release.\n\nBy configuring a release job based on the tagged version, DevSecOps teams can confidently incorporate the official component into their projects, knowing that it has undergone testing and validation. To learn more about how to test components, you can check out our [documentation](https://docs.gitlab.com/ee/ci/components/#test-a-component) or watch this walkthrough video:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"1870\" height=\"937\" src=\"https://www.youtube.com/embed/Vw8-ce8LNBs\" title=\"\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n### Versioning and tagging\nAs mentioned in the previous section, DevSecOps teams can leverage the `@version` or the `@commit_SHA` to refer to a component in their pipeline. Another option to refer to a component is by leveraging the `@latest`.\n\n```yaml\ninclude:\n  - components: /path/to/project@latest\n```\nThis will use the latest official (tagged) available components. When used in a pipeline in combination with reliable tests, you can guarantee that your components used in a pipeline will always be tested and verified.\n\n### On the horizon: CI/CD catalog\nOne of the biggest benefits of using components is yet to be seen and will be available with the launch of our CI/CD catalog. The catalog will allow users to search, find, and understand how to use components that are available across their organization, setting a framework for them to collaborate on pipeline constructs so that they can be evolved and improved over time. Stay tuned!\n\n### Dogfooding components \nAt GitLab, we believe in [dogfooding our own product](https://handbook.gitlab.com/handbook/values/#dogfooding). To demonstrate the power and practicality of CI/CD components, we have converted some of our GitLab templates into components and asked our internal team to use them and provide additional feedback. By doing so, we are actively using and testing components in real-world scenarios, uncovering insights, and continuously improving their functionality. In this [group](https://gitlab.com/gitlab-components), we’ve converted Code Quality, Container Scanning and SAST templates into CI/CD components and asked internal teams to use them.\n\nThrough this dogfooding process, we are not only validating the effectiveness of CI/CD components but also gaining invaluable experience and feedback to refine and enhance our offering. It's a testament to our commitment to providing practical and reliable solutions for our users. You can view the ongoing discussions between the internal teams in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390656).\n\n### Call for action\nThe CI/CD component catalog is currently in an experimental phase, so we advise against using it in a production environment at this time. There is a high probability of changes being made to it. We are currently working on reorganizing the folder structure of the components to prepare for the launch of the CI/CD catalog. You can stay updated on our progress by following our [epic](https://gitlab.com/groups/gitlab-org/-/epics/10728), or let us know what you think in this dedicated [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/407556).\n\n### What's next\nGitLab's CI/CD component catalog and its accompanying CI/CD components feature are ushering in a new era of streamlined pipeline configurations. By embracing reusability, abstraction, input flexibility, versioning, and a centralized catalog, developers can build efficient, adaptable, and maintainable CI/CD workflows. The CI/CD component catalog empowers teams to accelerate their software delivery, collaborate effectively, and leverage the full potential of GitLab's CI/CD capabilities.\n\nStay tuned for the launch of the CI/CD catalog, where you'll gain access to an extensive collection of components, unlocking new possibilities for your pipelines. GitLab remains committed to empowering developers with cutting-edge tools, driving innovation, and simplifying the complexities of modern software development.\n\n> Learn more about the CI/CD Catalog and components:\n>  \n> - [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)\n> \n> - [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n>\n> - [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n>\n> - [Documentation: CI/CD components and CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/)\n> \n\nCover image by [Alexander Grey](https://www.pexels.com/photo/assorted-color-bricks-1148496/) on [Pexels](https://www.pexels.com).\n{: .note}\n",[746,108,9],{"slug":4188,"featured":6,"template":683},"introducing-ci-components","content:en-us:blog:introducing-ci-components.yml","Introducing Ci Components","en-us/blog/introducing-ci-components.yml","en-us/blog/introducing-ci-components",{"_path":4194,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4195,"content":4201,"config":4208,"_id":4210,"_type":13,"title":4211,"_source":15,"_file":4212,"_stem":4213,"_extension":18},"/en-us/blog/introducing-compromised-password-detection-for-gitlab-com",{"title":4196,"description":4197,"ogTitle":4196,"ogDescription":4197,"noIndex":6,"ogImage":4198,"ogUrl":4199,"ogSiteName":670,"ogType":671,"canonicalUrls":4199,"schema":4200},"Introducing compromised password detection for GitLab.com","GitLab is adding compromised password detection on June 19, 2025. After that date, users logging in with known compromised passwords will be warned.  Here is what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097341/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%287%29_6QBUJnfaq500YYVKVDlxK7_1750097340425.png","https://about.gitlab.com/blog/introducing-compromised-password-detection-for-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing compromised password detection for GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ruby Nealon\"},{\"@type\":\"Person\",\"name\":\"Matt Coons\"}],\n        \"datePublished\": \"2025-05-22\",\n      }",{"title":4196,"description":4197,"authors":4202,"heroImage":4198,"date":4205,"body":4206,"category":704,"tags":4207},[4203,4204],"Ruby Nealon","Matt Coons","2025-05-22","Data breaches have become more common than ever. [According to a recent report by the Identity Theft Resource Center](https://www.idtheftcenter.org/publication/2024-data-breach-report/), over 2,800 data breaches occurred in 2024 alone, with over 1 billion victim notices sent by compromised organizations. Often, these breaches result in the exposure of credentials – usernames, emails, and passwords – in plain text, either directly or with insufficient protection against conversion to plain text. These compromised or stolen credentials are actively and widely leveraged by attackers, too. [Verizon’s 2024 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/2024-dbir-data-breach-investigations-report.pdf) identified use of stolen credentials as the initial action in 24% of breaches, ranking it as their top initial action. \n\nGitLab.com stores your password securely, salted and hashed with bcrypt. Your password goes through a one-way hashing transformation before storage, securing your password and ensuring it is not possible to extract the original password from storage. The representation is also unique: Even if two users shared the same password, the results of the one-way transformations would be completely different. However, these safeguards intentionally make it impractical to identify all users with a compromised or otherwise weak password.\n\n__Starting on June 19, 2025, GitLab will be introduce compromised password detection during sign-in for all GitLab.com users.__ This works by securely comparing the password you log in with against a database of known compromised credentials during authentication. If the password is correct but matches known compromised credentials, you will be alerted with a banner on GitLab.com and you will be sent an email notification until you change your password. \n\n***Note:** Compromised password detection is only for logins using GitLab’s native username and password and does not apply to credentials used through SSO.*\n\nExample compromised password warning banner: \n\n![Example Compromised Password Warning Banner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097349/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097348674.png)\n\nWe’re excited to introduce this additional countermeasure to help ensure your account is secure. We also encourage users to take these additional preventive actions to maintain the security of your account(s): \n\n1. [**Use a strong password unique to your GitLab.com account.**](https://docs.gitlab.com/user/profile/user_passwords/#change-a-known-password)\nGitLab [disallows weak passwords](https://docs.gitlab.com/user/profile/user_passwords/#block-weak-passwords) that are considered compromised or that contain part of your name, email address, or predictable words. We strongly recommend using a password manager like [1Password](https://1password.com/), [Google Password Manager](https://passwords.google.com/), or [Apple Passwords](https://support.apple.com/en-us/120758), as well.  \n3. [**Set up two-factor authentication for your GitLab.com account.**](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#enable-two-factor-authentication)\nGitLab supports time-based, one-time password applications, like [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en&co=GENIE.Platform%3DAndroid) and WebAuthn, with a [PIN/fingerprint](https://support.google.com/chromebook/answer/10364515?hl=en) or a [hardware security key](https://www.yubico.com/jp/product/security-key-series/security-key-nfc-by-yubico-black/).   \n5. **Prevent yourself from getting locked out of your account.**\n[Change your primary email address](https://docs.gitlab.com/user/profile/#change-your-primary-email) if you no longer have access, and [ensure you have recovery codes](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#recovery-codes) in case your two-factor authentication device is lost or stolen. Also, consider [setting up an alternative method for two-factor authentication](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#set-up-a-webauthn-device).  \n8. **Stay aware of new risks.**\nRegister with a service like [haveibeenpwned.com](http://haveibeenpwned.com) to receive an email notification if your email address appears in a newly disclosed breach. This service is free to use and requires only your email address at registration.\n\n> To learn more about trust and security measures on GitLab.com, visit the [GitLab security page](https://about.gitlab.com/security/), highlighting the GitLab Trust Center, compliance certifications, and security measures that keep users and customers safe on our platform.\n",[704,701,9,678,478],{"slug":4209,"featured":90,"template":683},"introducing-compromised-password-detection-for-gitlab-com","content:en-us:blog:introducing-compromised-password-detection-for-gitlab-com.yml","Introducing Compromised Password Detection For Gitlab Com","en-us/blog/introducing-compromised-password-detection-for-gitlab-com.yml","en-us/blog/introducing-compromised-password-detection-for-gitlab-com",{"_path":4215,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4216,"content":4222,"config":4227,"_id":4229,"_type":13,"title":4230,"_source":15,"_file":4231,"_stem":4232,"_extension":18},"/en-us/blog/introducing-custom-compliance-frameworks-in-gitlab",{"title":4217,"description":4218,"ogTitle":4217,"ogDescription":4218,"noIndex":6,"ogImage":4219,"ogUrl":4220,"ogSiteName":670,"ogType":671,"canonicalUrls":4220,"schema":4221},"Introducing Custom Compliance Frameworks in GitLab","Reduce manual tracking, accelerate audit readiness, and enforce controls faster natively within GitLab DevSecOps workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099268/Blog/Hero%20Images/Blog/Hero%20Images/GitLab_Blog_Header_v4_YBzFAgt2EAkqQfqxNFEgj_1750099267940.svg","https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing Custom Compliance Frameworks in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Khor\"},{\"@type\":\"Person\",\"name\":\"Salman Ladha\"}],\n        \"datePublished\": \"2025-04-17\",\n      }",{"title":4217,"description":4218,"authors":4223,"heroImage":4219,"date":2880,"body":4225,"category":704,"tags":4226},[4224,698],"Ian Khor","Maintaining multiple compliance frameworks in fast-moving DevSecOps pipelines is more difficult than ever. As standards evolve independently and become more complex, organizations are buried in overlapping requirements and manual processes – draining developer time and slowing audits. \n\nTo solve this, GitLab is introducing Custom Compliance Frameworks and 50 out-of-the-box (OOTB) controls for a wide variety of compliance standards, including ISO 27001, the [CIS Benchmark](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/), and SOC 2.\n\nCustom Compliance Frameworks enable organizations to map multiple, overlapping controls from different standards and regulations into a single, unified framework. This flexibility brings much-needed efficiency, allowing businesses to tailor compliance programs in a way that makes sense for them. As these policies are embedded directly into GitLab’s CI/CD pipelines, compliance is enforced automatically – without disrupting development.\n\nAdditionally, with the OOTB controls, teams can accelerate compliance adoption, eliminating the need for external tools or complex custom configurations. By embedding compliance directly into the software development lifecycle, GitLab provides real-time visibility, automated enforcement, and simplified audit readiness so teams can ship secure, *compliant* software, faster. \n\nCustom Compliance Frameworks and OOTB controls are available now in GitLab Ultimate.\n\n## Mounting compliance pressure\n\nOrganizations must navigate various compliance frameworks to ensure adherence to numerous regulations and provide assurance to their customers. While these frameworks often share common controls, they rarely align. The result is a reality compliance teams know all too well: manual tracking through spreadsheets that breeds chaos, particularly during audit reviews. \n\nDevelopers are pulled into the compliance fray because modern software development is central to satisfying many of these controls. Instead of building and shipping secure software, they find themselves supporting evidence collection and compliance reviews. A Forrester Total Economic Impact™ Study of GitLab Ultimate found that prior to GitLab developers spent up to [80 hours annually on audit and compliance tasks](https://tei.forrester.com/go/GitLab/GitLabUltimate/?lang=en-us#Appendixes); time diverted from writing code and delivering business value.\n\nThis fragmented approach isn’t just inefficient, it’s costly. Compliance-related costs have [surged by 60% over the past five years](https://www.cato.org/sites/cato.org/files/2024-01/research-brief367.pdf), according to the CATO Institute. Without a system that connects compliance enforcement to where software is built, compliance will remain a burdensome afterthought that drives a wedge between developers and security teams. \n\n## Why should you care about Custom Compliance Frameworks\n\nOur customers have asked for greater flexibility when it comes to the tracking and enforcement of compliance within DevSecOps workflows. With this release, we’re happy to empower customers in the following ways: \n\n**Compliance that fits the business, not the other way around**\n\nRegulatory requirements overlap across multiple frameworks causing complexity in tracking and enforcement. Custom Compliance Frameworks allow organizations to create a unified framework that cleanly maps the requirements and controls of multiple standards, reducing manual effort and reliance on costly consultants.\n\n**Faster compliance from setup through to audits**\n\nStart monitoring compliance instantly with OOTB controls aligned with key compliance standards, such as SOC 2, ISO 27001, and CIS Benchmarks. Automated compliance monitoring and evidence collection cuts audit prep from weeks to days, ensuring developers can remain focused on delivering secure software. \n\n**Built-in compliance at the speed of development**\n\nUnlike traditional GRC tools that operate in isolation, GitLab enforces compliance directly in CI/CD pipelines where work happens. This deep integration means compliance validation occurs automatically as code moves through the pipeline, eliminating the traditional friction between development speed and security requirements.\n\nHere is an example of how a custom compliance framework can be created in GitLab:\n\n![custom compliance frameworks - edit requirement screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099291312.png)\n\n\u003Cbr>\u003C/br>\n\n![custom compliance frameworks - screen showing requirements](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099291/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099291312.png)\n\n## What to know about the Custom Compliance Frameworks rollout\n\nThere are two critical aspects of this release: \n\n- As of GitLab 18.0, Custom Compliance Frameworks will be enabled by default. \n- Starting in GitLab 18.0, we’ve enabled Custom Compliance Frameworks by default. We’ve also removed \"Standards\" from the Compliance Center to simplify the experience. Don’t worry — your existing compliance controls still apply. We’ve converted the GitLab Standard and SOC 2 standards into compliance framework labels and transformed their compliance checks into controls (our new term going forward).\n- Only GitLab Ultimate customers can define requirements, map controls, and enforce compliance frameworks. Premium users can still use compliance labels, but they won’t have access to the full feature set.\n\nTo learn more about Custom Compliance Frameworks, please watch this introduction video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/yfJ0oHCIn-8?si=z_Rt_ikry4RhjEAC\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Shift compliance left with GitLab  \n\nSimilar to security, shifting compliance left means addressing compliance requirements earlier in the software development lifecycle. Since software is central to an organization achieving compliance, embedding controls where software is created is crucial. With GitLab, security and compliance teams can define frameworks, map controls, and automate enforcement directly in CI/CD pipelines. Developers stay focused on shipping features, while compliance teams gain real-time visibility and automated evidence collection to be audit-ready. This unified approach bridges the gap between development and compliance, helping organizations achieve continuous compliance as part of their DevSecOps practice. \n\nAs a result, organizations using GitLab can reduce developer time spent on audit and compliance tasks by 90% and accelerate external audits from several weeks to under one week, according to [Forrester](https://tei.forrester.com/go/GitLab/GitLabUltimate/?lang=en-us#AnalysisOfBenefits). \n\nIf you’re an existing GitLab Ultimate customer and would like to learn more about how Custom Compliance Frameworks can help improve your compliance and security program, [visit our Compliance Center documentation](https://docs.gitlab.com/user/compliance/compliance_center/) where we cover implementation requirements, use cases, and more.\n\n***Note:** ”The Total Economic Impact™ Of GitLab Ultimate” is a commissioned study conducted by Forrester Consulting on behalf of GitLab, October 2024. Results are based on a composite organization representative of interviewed customers.*\n\n## Learn more\n\n- [How to ensure separation of duties and enforce compliance with GitLab](https://about.gitlab.com/blog/ensuring-compliance/)\n- [Meet regulatory standards with GitLab security and compliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [Guide to fulfilling SOC 2 security requirements with GitLab](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/)",[704,701,9,478],{"slug":4228,"featured":6,"template":683},"introducing-custom-compliance-frameworks-in-gitlab","content:en-us:blog:introducing-custom-compliance-frameworks-in-gitlab.yml","Introducing Custom Compliance Frameworks In Gitlab","en-us/blog/introducing-custom-compliance-frameworks-in-gitlab.yml","en-us/blog/introducing-custom-compliance-frameworks-in-gitlab",{"_path":4234,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4235,"content":4241,"config":4247,"_id":4249,"_type":13,"title":4250,"_source":15,"_file":4251,"_stem":4252,"_extension":18},"/en-us/blog/introducing-gitlab-advanced-vulnerability-tracking",{"title":4236,"description":4237,"ogTitle":4236,"ogDescription":4237,"noIndex":6,"ogImage":4238,"ogUrl":4239,"ogSiteName":670,"ogType":671,"canonicalUrls":4239,"schema":4240},"Introducing GitLab Advanced Vulnerability Tracking","Learn how this security feature improves the efficiency of vulnerability management by reducing futile auditing time (includes data from a new study).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664844/Blog/Hero%20Images/AdobeStock_941867776.jpg","https://about.gitlab.com/blog/introducing-gitlab-advanced-vulnerability-tracking","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab Advanced Vulnerability Tracking\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n        \"datePublished\": \"2025-01-21\",\n      }",{"title":4236,"description":4237,"authors":4242,"heroImage":4238,"date":4243,"body":4244,"category":704,"tags":4245},[824],"2025-01-21","DevSecOps streamlines software development by allowing teams to ship features quickly and providing short feedback cycles for customers. These short feedback cycles can be used to monitor the impact of a feature from the time it is shipped and to inform developers and product managers about the success or failure of a given deployment.\n\nGitLab, as an agnostic DevSecOps platform, can act as an integration point for different [CI/CD](https://about.gitlab.com/topics/ci-cd/) tools that often contribute to user-facing functionality. For example, the [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), which displays all detected vulnerabilities, is visible as a single functionality, but the data in the report may come from a number of different tools in various pipelines.\n\nIn a heterogeneous Static Application Security Testing ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) setup we find two potential sources of vulnerability deduplication:\n1. Code volatility refers to the reintroduction of vulnerabilities in a constantly changing code base.\n2. Double reporting refers to duplication introduced by multiple tools that are reporting the same vulnerability. \n\nGitLab addresses these two sources of duplication by means of the [Advanced Vulnerability Tracking](https://docs.gitlab.com/ee/user/application_security/sast/#advanced-vulnerability-tracking) feature, which identifies and deduplicates vulnerabilities in a constantly changing code base.\n\n[Advanced Vulnerability Tracking](https://docs.gitlab.com/ee/user/application_security/sast/#advanced-vulnerability-tracking) leverages contextual information provided by generated syntax-trees to scope vulnerabilities and generates location fingerprints for vulnerabilities that are less fragile across code changes in comparison to other tracking methods.\n\nIn a recent study, we demonstrated that our vulnerability tracking approach was 30% more effective than traditional, line-based vulnerability tracking where `\u003Cfile, line number>` are used to fingerprint vulnerabilities. This means that advanced vulnerability tracking reduces the manual effort of auditing vulnerabilities by 30%. In addition, our study suggested that the positive effect of our vulnerability tracking method increases over time.\n\nThe preprint of our study \"[A scalable, effective and simple Vulnerability Tracking approach for heterogeneous SAST setups based on Scope+Offset](https://about.gitlab.com/resources/downloads/icse25-preprint.pdf)\" will be presented at the [47th International Conference on Software Engineering (Software Engineering in Practice Track) 2025](https://conf.researchr.org/home/icse-2025).\n\n*[Lucas Charles](https://gitlab.com/theoretick), [Jason Leasure](https://gitlab.com/jleasure), and [Hua Yan](https://gitlab.com/hyan3) contributed to this article and study.*",[704,4246,9,478],"security research",{"slug":4248,"featured":6,"template":683},"introducing-gitlab-advanced-vulnerability-tracking","content:en-us:blog:introducing-gitlab-advanced-vulnerability-tracking.yml","Introducing Gitlab Advanced Vulnerability Tracking","en-us/blog/introducing-gitlab-advanced-vulnerability-tracking.yml","en-us/blog/introducing-gitlab-advanced-vulnerability-tracking",{"_path":4254,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4255,"content":4261,"config":4267,"_id":4269,"_type":13,"title":4270,"_source":15,"_file":4271,"_stem":4272,"_extension":18},"/en-us/blog/introducing-gitlab-serverless",{"title":4256,"description":4257,"ogTitle":4256,"ogDescription":4257,"noIndex":6,"ogImage":4258,"ogUrl":4259,"ogSiteName":670,"ogType":671,"canonicalUrls":4259,"schema":4260},"Announcing GitLab Serverless","The true value of serverless is best realized via a single-application DevOps experience – that's why we're launching GitLab Serverless.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666851/Blog/Hero%20Images/gitlab-serverless-blog.png","https://about.gitlab.com/blog/introducing-gitlab-serverless","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Announcing GitLab Serverless\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Priyanka Sharma\"}],\n        \"datePublished\": \"2018-12-11\",\n      }",{"title":4256,"description":4257,"authors":4262,"heroImage":4258,"date":4264,"body":4265,"category":298,"tags":4266},[4263],"Priyanka Sharma","2018-12-11","\n\n[Serverless](/topics/serverless/) is the latest innovation in cloud computing that promises to alter the cost-benefit equation for enterprises. As our CEO, [Sid Sijbrandij](/company/team/#sytses) says, \"All roads lead to compute.\" There is a race among providers to acquire as many workloads from enterprises as possible, at the cheapest cost. The latter is where serverless comes in: serverless computing is an execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual resources consumed by an application, rather than on pre-purchased units of capacity.\n\nThis field began with the release of [AWS Lambda](https://en.wikipedia.org/wiki/AWS_Lambda) in November 2014. In the four short years since then, it has become a well-known workflow that enterprises are eager to adopt. Today, we are announcing [GitLab Serverless](/topics/serverless/) to enable our users to take advantage of the benefits of serverless.\n\n## GitLab Serverless is launching Dec. 22\n\nGitLab is the only single application for the entire [DevOps lifecycle](/topics/devops/). As part of that vision, we will release GitLab Serverless in GitLab 11.6, coming later this month, to allow enterprises to plan, build, and manage serverless workloads with the rest of their code from within the same GitLab UI. It leverages [Knative](https://cloud.google.com/knative/), which enables [autoscaling](https://en.wikipedia.org/wiki/Autoscaling) down to zero and back up to run serverless workloads on Kubernetes. This allows businesses to employ a multi-cloud strategy and leverage the value of serverless without being locked into a specific cloud provider.\n\nIn order to bring the best-in-class to our users, we partnered with [TriggerMesh](https://triggermesh.com/) founder [Sebastien Goasguen](https://twitter.com/sebgoa) and his team. Sebastien has been part of the serverless landscape since the beginning. He built a precursor to Knative, Kubeless. He is actively involved with the Knative community and understands the workflow from soup to nuts. Sebastien says, \"We are excited to help GitLab enable all their users to deploy functions directly on the Knative function-as-a-service clusters. We believe that these additions to GitLab will give those users the best possible experience for complete serverless computing from beginning to end.\"\n\n## \"Serverless first\"\n\nAs any attendees at [AWS re:Invent](/blog/aws-reinvent-recap/) would have noticed, the behemoth is putting all its energies behind serverless. We heard [stories from the likes of Trustpilot](https://www.computerworlduk.com/cloud-computing/how-trustpilot-takes-serverless-first-approach-engineering-with-aws-3688267/) about changing their engineering culture to \"serverless first.\" This is because serverless cloud providers save money by not having to keep idle machines provisioned and running, and are passing on the benefits to their customers. While this is amazing news, it is hard to truly embrace a workflow if it lives outside of developers' entrenched habits. GitLab has millions of users and is used by over 100,000 organizations, and with GitLab Serverless they can now enjoy the cost savings and elegant code design serverless brings, from the comfort of their established workflows.\n\nAs with all GitLab endeavors, making serverless multi-cloud and accessible to everyone is a big, hairy, audacious goal. Today, Knative can be installed to a Kubernetes cluster with a single click via the GitLab Kubernetes integration. It shipped in [GitLab 11.5](/releases/2018/11/22/gitlab-11-5-released/#easily-deploy-and-integrate-knative-with-gitlab).\n\n### How to activate GitLab Serverless\n\nStarting with the release of GitLab 11.6 on Dec. 22, the \"Serverless\" tab will be available for users as an alpha offering. Please do check it out and share your feedback with us.\n\n1. Go to your GitLab instance and pick your project of choice.\n2. Click on the `Operations` menu item in the sidebar.\n3. Pick `Serverless` to view the list of all the functions you have defined. You will also be able to see a brief description as well as the Knative cluster the function is deploying to.\n\n![Serverless list view](https://gitlab.com/gitlab-org/gitlab-ce/uploads/8b821d4aaa1bb75375dc54567a4313ad/CE-project__serverless-grouped.png \"Serverless list view\"){: .shadow.large.center}\n\nTo dig further, click into the function for more info.\n\n![function detail view](https://gitlab.com/gitlab-org/gitlab-ce/uploads/9e1e3893aa5369a2a165d1dd95c98dd8/CE-project__serverless--function-details.png \"function detail view\"){: .shadow.large.center}\n\nAll this goodness will be available Dec. 22. In the meantime, we would love to see you at [KubeCon Seattle](/events), where our product and engineering experts are attending to talk all things serverless with attendees. Hope to see you at booth S44!\n",[678,851,9,230,1936],{"slug":4268,"featured":6,"template":683},"introducing-gitlab-serverless","content:en-us:blog:introducing-gitlab-serverless.yml","Introducing Gitlab Serverless","en-us/blog/introducing-gitlab-serverless.yml","en-us/blog/introducing-gitlab-serverless",{"_path":4274,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4275,"content":4281,"config":4286,"_id":4288,"_type":13,"title":4289,"_source":15,"_file":4290,"_stem":4291,"_extension":18},"/en-us/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"title":4276,"description":4277,"ogTitle":4276,"ogDescription":4277,"noIndex":6,"ogImage":4278,"ogUrl":4279,"ogSiteName":670,"ogType":671,"canonicalUrls":4279,"schema":4280},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab’s new Planner role for Agile planning teams\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-11-25\",\n      }",{"title":4276,"description":4277,"authors":4282,"heroImage":4278,"date":4283,"body":4284,"category":1228,"tags":4285},[1225],"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 60-day 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/)",[1164,478,9,701],{"slug":4287,"featured":90,"template":683},"introducing-gitlabs-new-planner-role-for-agile-planning-teams","content:en-us:blog:introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","Introducing Gitlabs New Planner Role For Agile Planning Teams","en-us/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","en-us/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"_path":4293,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4294,"content":4300,"config":4305,"_id":4307,"_type":13,"title":4308,"_source":15,"_file":4309,"_stem":4310,"_extension":18},"/en-us/blog/introducing-gitlabs-open-source-security-center",{"title":4295,"description":4296,"ogTitle":4295,"ogDescription":4296,"noIndex":6,"ogImage":4297,"ogUrl":4298,"ogSiteName":670,"ogType":671,"canonicalUrls":4298,"schema":4299},"Introducing GitLab’s Open Source Security Center","Our open source repository of projects designed to enhance security operations and risk management will help developers adapt faster, respond smarter, and defend better — together.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661895/Blog/Hero%20Images/blog-image-template-1800x945__7_.png","https://about.gitlab.com/blog/introducing-gitlabs-open-source-security-center","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Introducing GitLab’s Open Source Security Center\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"},{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2025-03-04\",\n      }",{"title":4295,"description":4296,"authors":4301,"heroImage":4297,"date":4302,"body":4303,"category":704,"tags":4304},[698,3524],"2025-03-04","Today, we’re excited to announce the launch of [GitLab’s Open Source Security Center](https://about.gitlab.com/security/open-source-resources/) — a central repository of security-focused projects developed by GitLab’s internal security team. These tools are designed to help developers, security practitioners, and organizations build safer, more secure software, and more resilient security programs.\n\nSecuring systems is an ongoing challenge for businesses as threat actors continually adapt to new technologies and find creative ways to exploit organizations. Not only are they evolving their tactics, techniques and procedures, but they’re also [collaborating through criminal networks](https://insights.blackhatmea.com/do-cybercriminals-collaborate-and-build-community/), sharing strategies, stolen data, and malicious tools to launch coordinated attacks at scale. \n\nAs these threats grow in complexity, community-driven collaboration is one of our most powerful defenses. It’s a notion we’ve long understood in security — that *defending against adversaries is a shared responsibility*. By working together as a community, we can accelerate our collective intelligence and stay ahead of adversaries.\n\nIn open-sourcing our security solutions, we aim to empower teams to adapt faster, respond smarter, and defend better — together.\n\n[![Open Source Security Center page image](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674572/Blog/Content%20Images/Screenshot_2025-03-04_at_08.10.05.png)](https://about.gitlab.com/security/open-source-resources/)\n\n## Why open source security? \n\nAt GitLab, open source isn’t just part of our technology — it’s part of our [founding story](https://about.gitlab.com/company/).\n\nSince day one, we’ve championed the open source philosophy, believing that transparency, collaboration, and community-driven development are keys to building better software. Over the years, GitLab has fostered an open source community with more than [4,000 contributors](https://about.gitlab.com/community/contribute/) and has provided a comprehensive DevSecOps platform through its open source [Community Edition](https://about.gitlab.com/install/ce-or-ee/).\n\nWe’ve also been inspired by industry leaders like [Crowdstrike](https://opensource.crowdstrike.com/) and [Palo Alto Networks](https://www.paloaltonetworks.ca/prisma/cloud/open-source-projects), who have shown that open-sourcing security tools not only improves innovation but also strengthens the entire security ecosystem. Following in their footsteps, GitLab is committed to supporting the community by sharing tools, templates, and frameworks developed by our security teams.\n\n## Explore our featured open source security projects\n\nWe’re launching the Open Source Security Center with a range of projects designed to enhance security operations and risk management. Here are some of the featured projects:\n\n* **[StORM templates](https://gitlab.com/gitlab-security-oss/risk-mgmt/storm-templates/):** Streamline your security risk program with templates that standardize risk tracking and reporting.\n\n* **[GUARD Framework](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/):** Automate response and detection with a detections-as-code approach that simplifies detection creation, maintenance, and alert routing.  \n\n* **[GitLab CIS Benchmark Scanner](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/):** Improve your project’s security posture by auditing against the Center for Internet Security GitLab Benchmark.\n\nWhether you’re a security engineer, researcher, or developer, your expertise and contributions are invaluable. Join us in strengthening the security ecosystem and collaborating with a community dedicated to making software safer for everyone.\n\n> [Explore GitLab’s Open Source Security Center](https://about.gitlab.com/security/open-source-resources/) and contribute to the next chapter of open source security. \n\n## Learn more\n\n- [New CIS GitLab Benchmark scanner boosts security and compliance](https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance/)\n- [GitLab introduces new CIS Benchmark for improved security](https://about.gitlab.com/blog/gitlab-introduces-new-cis-benchmark-for-improved-security/)\n- [Unveiling the GUARD framework to automate security detections at GitLab](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/)\n- [Automating cybersecurity threat detections with GitLab CI/CD](https://about.gitlab.com/blog/automating-cybersecurity-threat-detections-with-gitlab-ci-cd/)",[704,678,1187,703,9],{"slug":4306,"featured":90,"template":683},"introducing-gitlabs-open-source-security-center","content:en-us:blog:introducing-gitlabs-open-source-security-center.yml","Introducing Gitlabs Open Source Security Center","en-us/blog/introducing-gitlabs-open-source-security-center.yml","en-us/blog/introducing-gitlabs-open-source-security-center",{"_path":4312,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4313,"content":4318,"config":4322,"_id":4324,"_type":13,"title":4325,"_source":15,"_file":4326,"_stem":4327,"_extension":18},"/en-us/blog/introducing-product-analytics-in-gitlab",{"title":4314,"description":4315,"ogTitle":4314,"ogDescription":4315,"noIndex":6,"ogImage":1565,"ogUrl":4316,"ogSiteName":670,"ogType":671,"canonicalUrls":4316,"schema":4317},"Product Analytics: A sneak peek at our upcoming feature","Our journey to add Product Analytics into the DevSecOps platform.","https://about.gitlab.com/blog/introducing-product-analytics-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Product Analytics: A sneak peek at our upcoming feature\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Kerr\"}],\n        \"datePublished\": \"2023-03-27\",\n      }",{"title":4314,"description":4315,"authors":4319,"heroImage":1565,"date":1393,"body":4320,"category":1513,"tags":4321},[2450],"\n\nProduct analytics are important to understand how your users engage with your application so that you can make data-driven decisions. Identifying features that your users make heavy use of and which they don’t can provide signals to teams on where and how to spend their time most effectively. Without product data, we must use one-off anecdotes or opinions, which can be subject to incorrect assumptions, internal biases, or are missing key details. At the same time, instrumenting applications and processing this data can be challenging, which leads many teams to not do it.\n\nAt GitLab, we view this workflow of instrumenting the app, collecting data, and processing it to gain insights as a key piece of the DevSecOps lifecycle. For this reason, we are working on adding Product Analytics capabilities to our platform so you’ll be able to take advantage of them in your own apps. You will be able to instrument features you have built, see how users engage with them, and make decisions using that data – all within GitLab.\n\nIn this blog, you'll learn more details on what our vision is, what we are working on, our future plans, and how you can contribute and engage with us.\n\n## What is Product Analytics?\n\nWe have a broad vision for what we want to achieve, which we outline in our [product direction page](https://about.gitlab.com/direction/analytics/product-analytics/). The short version is that we want to enable developers to easily add instrumentation to their applications, provide infrastructure to receive and process it, run experiments, and enable consumers of the data, such as product managers or developers, to use GitLab to gain insights that will help them make even better products.\n\nOur initial focus is on web applications, primarily those built with JavaScript and Ruby on Rails. Longer term, we want to add functionality like experiments and support for other web frameworks and additional tech stacks.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jG42hesT030\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWe plan to use several open-source technologies to make this happen: [Snowplow](http://www.snowplow.io), [ClickHouse](https://clickhouse.com/), [Cube.dev](https://cube.dev/), and [ECharts](https://echarts.apache.org/en/index.html) for instrumentation, data storage, and data visualization, respectively. Each of these projects is great at what they do and we are excited to build with them.\n\n## How to configure Product Analytics\n\nOnce publicly available, Product Analytics will need access to a Kubernetes cluster running these applications. GitLab will be able to create and manage this cluster for you or you will be able to provide your own cluster. That cluster will then process, store, and transform your data and display it in relevant GitLab screens. You will then instrument your application’s features with one of our [client-side SDKs](https://gitlab.com/gitlab-org/analytics-section/product-analytics/gl-application-sdk-js). \n\nWith your app instrumented and your Product Analytics cluster set up, you will be able to access reports and dashboards within GitLab to explore the data that is reported. You'll be able to identify usage trends and better understand your users so that you can make improvements in future versions of your product.\n\nWe anticipate that one of the unique differentiators GitLab will have with Product Analytics is that all of the dashboard and visualization configurations will be driven by files in your GitLab project. You will be able to collaborate with your team using [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), look at previous versions to understand changes, and set up controls over who can make changes – just like you can with code.\n\n![Product Analytics dashboard](https://about.gitlab.com/images/blogimages/productanalyticsingitlab/productanalytics2.png){: .shadow}\n\n## We are customer zero \n\nOne of GitLab’s values is [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) and using our own product. This helps us better understand our users’ pain points and to find where we should make improvements more quickly. We are already dogfooding what we have built in Product Analytics so far.\n\nWe added Product Analytics to our internal handbook several months ago and have learned a lot about Product Analytics and how team members use the internal handbook.\n\nInstrumenting the internal handbook helped us work through the user experience for Product Analytics. We built out a workflow in GitLab to configure the cluster, view the Product Analytics dashboards, and view the content on them. This showed us what it would be like to instrument a real application. The steps we had difficulty doing showed what users would also likely have difficulty doing and, therefore, were an indication to focus on fixing those.\n\nOnce we had instrumented the handbook, we learned a few things we expected, such as people use the internal handbook primarily on weekdays and we see a massive dropoff in usage on weekends. One thing we didn’t expect was understanding which pages were the most viewed from the handbook. For example, we have various meetings to review [performance indicators](https://about.gitlab.com/handbook/product/#product-performance-indicators) and we saw large spikes in usage for relevant pages when those meetings occurred.\n\n![Screenshot showing spikes](https://about.gitlab.com/images/blogimages/productanalyticsingitlab/productanalytics1.png){: .shadow}\n\n## Our continued commitment to user privacy\n\nWe know that analytics offerings raise questions about user privacy and how data is being managed. Your data is your data. We want to build Product Analytics from the beginning so that you can respect the privacy of users. We are taking a few steps to accomplish this.\n\n* Product Analytics was designed to honor commonly recognized opt-out signals. That means users browsing the app will not have their activity recorded or analyzed by Product Analytics when an opt-out signal is received. Opt-out signals are becoming more common as a way of respecting privacy and we are excited to use them.\n* We are designing Product Analytics from the beginning to give you full control over the data you collect, rather than requiring it to be sent to a third-party service. Recall how you will have to provide a Kubernetes cluster with Snowplow, ClickHouse, and Cube.dev – you can provide your own cluster and GitLab can connect to it or we can host the cluster for you. In all cases, the data is yours – GitLab will not use this data beyond Product Analytics features and will not sell nor examine it.\n\n## What’s next?\n\nWe’re excited for the future of Product Analytics and to provide a way for you to learn even more about your users. Our near-term plans are to take what we have built so far and learn what improvements are needed to make it production ready for you to use. We are also working to give you a variety of options on how to best display Product Analytics data within GitLab so that it is easy for you to get started and to explore your data.\n\n## We’d love to hear from you\n\nAs we move forward with Product Analytics, we would love to hear your thoughts, comments, and questions. We have created [this Product Analytics feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/391970) if you want to start a discussion there.\n\nWe plan to release Product Analytics iteratively and will start with a small group of existing customers. If you are interested in previewing Product Analytics before it is generally available, please fill out [our contact form](https://forms.gle/3Q3srimfqpM4WCKM8).\n\n\u003Ci>Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\u003C/i>\n",[678,701,9],{"slug":4323,"featured":6,"template":683},"introducing-product-analytics-in-gitlab","content:en-us:blog:introducing-product-analytics-in-gitlab.yml","Introducing Product Analytics In Gitlab","en-us/blog/introducing-product-analytics-in-gitlab.yml","en-us/blog/introducing-product-analytics-in-gitlab",{"_path":4329,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4330,"content":4336,"config":4342,"_id":4344,"_type":13,"title":4345,"_source":15,"_file":4346,"_stem":4347,"_extension":18},"/en-us/blog/introducing-workspaces-beta",{"title":4331,"description":4332,"ogTitle":4331,"ogDescription":4332,"noIndex":6,"ogImage":4333,"ogUrl":4334,"ogSiteName":670,"ogType":671,"canonicalUrls":4334,"schema":4335},"A first look at workspaces: On-demand, cloud-based development environments","Remote development workspaces are now available in Beta for GitLab Premium and Ultimate users.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682731/Blog/Hero%20Images/code-editor-workspace.jpg","https://about.gitlab.com/blog/introducing-workspaces-beta","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A first look at workspaces: On-demand, cloud-based development environments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Schurter\"}],\n        \"datePublished\": \"2023-05-23\",\n      }",{"title":4331,"description":4332,"authors":4337,"heroImage":4333,"date":4338,"body":4339,"category":678,"tags":4340},[2491],"2023-05-23","\n\nCloud-based development tools are quickly gaining popularity for their ability to provide a consistent, secure developer experience and streamline developer onboarding, which can reduce the time it takes for a developer to contribute to a codebase from days to hours, or even minutes. To support this shift in developer workflows, GitLab has introduced a significant upgrade in [remote development](/direction/create/ide/remote_development/) in GitLab 16.0. Secure, on-demand, cloud-based development workspaces are now available in Beta for GitLab Premium and Ultimate users on GitLab.com and on self-managed instances.\n\nThe December 2022 [release of the Web IDE Beta](/blog/get-ready-for-new-gitlab-web-ide/) delivered a familiar, feature-rich editing experience in your browser and the ability to connect to a remote server and interact with a cloud-based runtime environment. Workspaces take experience to the next level by bringing the configuration, orchestration, and management of your remote development environments into GitLab for the first time.\n\n### What is a workspace? \nA workspace is your personal, ephemeral development environment in the cloud, created using centrally managed and curated dependencies defined in code. Developing with a workspace enables you to spend less time configuring your local development environment and more time focusing on writing code. Instead of managing package updates and troubleshooting version conflicts, consistent and reproducible cloud-based environments are available on demand. \n\nEach workspace is a unique instance of your environment so you can switch between tasks seamlessly and have confidence that your environment will remain stable between sessions. Whether used as a tool to accelerate developer onboarding, provide stable environments for education purposes, or improve security by limiting the need to clone code locally, workspaces will change how you develop software on GitLab.\n\n### How do you create a workspace? \nTo create a workspace in GitLab, you’ll need: \n\n- **A cloud platform or self-hosted Kubernetes cluster:** This release is focused on delivering a “bring your own infrastructure” solution. We know that many of you want complete control over your infrastructure and code, so we have prioritized hosting workspaces on your own infrastructure or in the cloud platform of your choice. \n\n- **An agent:** Everything starts with the GitLab Agent for Kubernetes. Once you have the agent running in a Kubernetes cluster, [configuring remote development](https://docs.gitlab.com/ee/user/workspace/#prerequisites) is a matter of installing a couple of dependencies and adding a few lines of code to the agent configuration. \n\n- **A devfile:** After you have an agent configured, you need to define your environment in a `.devfile.yaml` file, stored at the root of a project. In this file, you can specify container images, map ports, define volume mounts, [and more](https://docs.gitlab.com/ee/user/workspace/#relevant-schema-properties). \n\n- **An editor:** In the first iteration, we are supporting the Web IDE and injecting it into the workspace. In future iterations, we will add support for other editors like [Jupyter Notebook](https://gitlab.com/gitlab-org/gitlab/-/issues/408381).\n\n- Optionally, you can [override the default timeout for your workspace](https://docs.gitlab.com/ee/user/workspace/index.html#create-a-workspace) to make sure you’re using cloud resources efficiently. Since workspaces are meant to be ephemeral, the default lifespan is 24 hours, but it can be set as high as a week. \n\nAfter you’ve created your workspace, you can launch the Web IDE with a single click and get right to work. \n\nWant to see it in action? This short video walks you through the configuration of an agent and the creation of a workspace: \n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/lDVaOtO_JVM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n### What comes next?\nWe’re excited to start getting your feedback so we’re introducing this as a Beta for public projects. Your credentials aren't currently being injected into the workspace during its creation, which means you can’t automatically clone private repositories. You can, however, create a workspace and authenticate yourself manually after it’s running. We’ll be working on [injecting credentials](https://gitlab.com/groups/gitlab-org/-/epics/10480) as well as addressing some other points of friction to make this even easier for developers to adopt. We’ll also be working on: \n\n- [Connecting to a workspace via SSH from your desktop IDE](https://gitlab.com/groups/gitlab-org/-/epics/10478)\n- [Support for alternative editors](https://gitlab.com/groups/gitlab-org/-/epics/10635) like Jupyter Notebook or vim\n- [Configure instance or group-level usage limits to manage cloud resources](https://gitlab.com/groups/gitlab-org/-/epics/10571)\n- [Support for architectures other than amd64](https://gitlab.com/groups/gitlab-org/-/epics/10594)\n\nAs you can see, we have an ambitious roadmap ahead of us, and we want to hear from you. Please let us know how you are using workspaces, what features are most important to you, and share any issues you run into along the way in the [public feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/410031). We can’t wait to see how you integrate workspaces into your DevSecOps workflow to improve the developer experience!\n\n**Disclaimer**: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\n\nCover image by [AltumCode](https://unsplash.com/@altumcode) on [Unsplash](https://unsplash.com/photos/dC6Pb2JdAqs)\n{: .note}\n\n",[4341,9,678],"cloud native",{"slug":4343,"featured":6,"template":683},"introducing-workspaces-beta","content:en-us:blog:introducing-workspaces-beta.yml","Introducing Workspaces Beta","en-us/blog/introducing-workspaces-beta.yml","en-us/blog/introducing-workspaces-beta",{"_path":4349,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4350,"content":4356,"config":4361,"_id":4363,"_type":13,"title":4364,"_source":15,"_file":4365,"_stem":4366,"_extension":18},"/en-us/blog/ios-publishing-with-gitlab-and-fastlane",{"title":4351,"description":4352,"ogTitle":4351,"ogDescription":4352,"noIndex":6,"ogImage":4353,"ogUrl":4354,"ogSiteName":670,"ogType":671,"canonicalUrls":4354,"schema":4355},"How to publish iOS apps to the App Store with GitLab and fastlane","See how GitLab, together with fastlane, can build, sign, and publish apps for iOS to the App Store.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680470/Blog/Hero%20Images/ios-publishing-cover.jpg","https://about.gitlab.com/blog/ios-publishing-with-gitlab-and-fastlane","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to publish iOS apps to the App Store with GitLab and fastlane\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-03-06\",\n      }",{"title":4351,"description":4352,"authors":4357,"heroImage":4353,"date":4358,"body":4359,"category":849,"tags":4360},[846],"2019-03-06","\n\n_Note: You may also find the blog post [Tutorial: iOS CI/CD with GitLab](/blog/ios-cicd-with-gitlab/) from June 2023 helpful._\n\nRecently we published a [blog post\ndetailing how to get up and running quickly with your Android app](/blog/android-publishing-with-gitlab-and-fastlane/), GitLab, and\n[_fastlane_](https://fastlane.tools). In this edition, let's look at how to get\na build of an iOS app up and running, including publishing all the way to\nTestFlight. To see how cool this can be, check out this [video\nof me making a change on an iPad Pro using the GitLab Web IDE](https://www.youtube.com/watch?v=325FyJt7ZG8), getting that\nbuilt, and then receiving an update to the test version of my application on the\nvery same iPad Pro I was using to develop.\n\nFor the purposes of this article, we'll be using a [simple Swift iOS app](https://gitlab.com/jyavorska/flappyokr)\nthat I recorded the video with.\n\n## First, a note on Apple Store configuration\n\nWhat we're going to need in order to set all of this up is a mobile application set up\nin the App Store, distribution certificates, and a provisioning profile that ties\nit all together.\n\nMost of the complexity here actually has to do with setting up your signing\nauthority for the App Store. Hopefully in most cases this is already good to go\nfor you; if you're a new app developer, I'll try to get you started on the right\ntrack, but the intricacies of Apple certificate management is out of the scope of\nthis article, and tends to change somewhat frequently. But, this information\nshould get you going.\n\n### My apps\n\nYour application will need to be set up in App Store Connect so you have an ID\nfor your application, which will be used in your `.xcodebuild` configuration.\nYour app profile and ID are what tie together the code builds with pricing and\navailability, as well as TestFlight configuration for distributing testing\napplications to your users. Note that you don't need to set up public testing –\nyou can use personal testing with TestFlight just fine as long as your testing\ngroup is small, and the setup is simpler and requires no additional approvals\nfrom Apple.\n\n### Provisioning profile\n\nIn addition to the app setup, you need iOS distribution and development keys\ncreated in the Certificates, Identifiers, and Profiles section of the Apple\nDeveloper console. Once these certificates are created, you can create a\nprovisioning profile to unify everything.\n\nAlso note that the user you will authenticate with needs to be able to create\ncertificates, so please ensure that they have that ability or you will see an\nerror during the [_cert_ and _sigh_](https://docs.fastlane.tools/codesigning/getting-started/#using-cert-and-sigh)\nsteps.\n\n### Other options\n\nThere are several more ways to set up your certificates and profiles than the\nsimple method I've described above, so if you're doing something different you may\nneed to adapt. The most important thing is that you need your `.xcodebuild`\nconfiguration to point to the appropriate files, and your keychain needs to be\navailable on the build machine for the user that the runner is running as. We're\nusing _fastlane_ for signing, so if you run into trouble here or want to learn\nmore about your options, take a look at their extensive [code signing documentation](https://docs.fastlane.tools/codesigning/getting-started/).\n\nFor this sample project, I'm using the [_cert_ and _sigh_](https://docs.fastlane.tools/codesigning/getting-started/#using-cert-and-sigh)\napproach, but the [match\napproach](https://docs.fastlane.tools/codesigning/getting-started/#using-match) may be better for actual enterprise use.\n\n## How to set up GitLab and _fastlane_\n\n### How to set up your CI/CD runner\n\nWith the above information gathered or set up, we can start with configuring the\nGitLab runner on a macOS device. Unfortunately, building on macOS is the only\nrealistic way to build iOS apps. This is potentially changing in the future;\nkeep an eye on projects like [xcbuild](https://github.com/facebook/xcbuild) and\n[isign](https://github.com/saucelabs/isign), as well as our own internal issue\n[gitlab-ce#57576](https://gitlab.com/gitlab-org/gitlab-ce/issues/57576) for\ndevelopments in this area.\n\nIn the meantime, setting up the runner is fairly straightforward. You can follow\nour most current [instructions for setting up GitLab Runner on macOS](https://docs.gitlab.com/runner/install/osx.html)\nto get that up and running.\n\nNote: Be sure to set your GitLab runner to use the `shell` executor. For building iOS on\nmacOS, it's a requirement to operate directly as the user on the machine rather\nthan using containers. Note that when you're using the shell executor, the\nbuild and tests run as the identity of the runner logged in user, directly on\nthe build host. This is less secure than using container executors, so please\ntake a look at our [security implications documentation](https://docs.gitlab.com/runner/security/#usage-of-shell-executor)\nfor additional detail on what to keep in mind in this scenario.\n\n```\nsudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64\nsudo chmod +x /usr/local/bin/gitlab-runner\ncd ~\ngitlab-runner install\ngitlab-runner start\n```\n\nWhat you need to be careful about here is ensuring your Apple keychain is set up\non this host and has access to the keys that Xcode needs in order\nto build. The easiest way to test this is to log in as the user that will be\nrunning the build and try to build manually. You may receive system prompts for\nkeychain access which you need to \"always allow\" for CI/CD to work. You will probably\nalso want to log in and watch your first pipeline or two to make sure that\nno prompts come up for additional keychain access. Unfortunately Apple does not\nmake this super easy to use in unattended mode, but once you have it working it\ntends to stay that way.\n\n### _fastlane_ init\n\nIn order to start using _fastane_ with your project, you'll need to run\n`fastlane init`. Simply follow the [instructions\nto install and run _fastlane_](https://docs.fastlane.tools/getting-started/ios/setup/), being sure to use the instructions in the\n[Use a Gemfile](https://docs.fastlane.tools/getting-started/ios/setup/#use-a-gemfile)\nsection, since we do want this to run quickly and predictably via unattended CI.\n\nFrom your project directory, you can run the following commands:\n\n```\nxcode-select --install\nsudo gem install fastlane -NV\n# Alternatively using Homebrew\n# brew cask install fastlane\nfastlane init\n```\n\n_fastlane_ will ask you for some basic configuration and then create a project folder\ncalled `fastlane` in your project which will contain three files:\n\n#### 1. `fastlane/Appfile`\n\nThis file is straightforward, so you just want to check to make sure that the Apple\nID and app ID that you set up earlier are correct.\n\n```\napp_identifier(\"com.vontrance.flappybird\") # The bundle identifier of your app\napple_id(\"your-email@your-domain.com\") # Your Apple email address\n```\n\n#### 2. `fastlane/Fastfile`\n\nThe `Fastfile` defines the build steps. Since we're using a lot of the built-in\ncapability of _fastlane_ this is really straightforward. We create a single\nlane which gets certificates, builds, and uploads the new build to TestFlight.\nOf course, you may want to split these out into different jobs depending on your\nuse case. Each of these steps, `get_certificates`, `get_provisioning_profile`,\n`gym`, and `upload_to_testflight` are pre-bundled actions already included with\n_fastlane_.\n\n`get_certificates` and `get_provisioning_profile` are actions associated with\nthe [_cert_ and _sigh_](https://docs.fastlane.tools/codesigning/getting-started/#using-cert-and-sigh)\napproach to code signing; if you're using _fastlane_ [match](https://docs.fastlane.tools/codesigning/getting-started/#using-match)\nor some other approach you may need to update these.\n\n```yaml\ndefault_platform(:ios)\n\nplatform :ios do\n  desc \"Build the application\"\n  lane :flappybuild do\n    get_certificates\n    get_provisioning_profile\n    gym\n    upload_to_testflight\n  end\nend\n```\n\n#### 3. `fastlane/Gymfile`\n\nThis `gym` file is optional, but I created it manually in order to override the default\noutput directory and place the output in the current folder. This makes things a\nbit easier for CI. You can read more about `gym` and its options in the\n[gym documentation](https://docs.fastlane.tools/actions/gym/).\n\n```yaml\noutput_directory(\"./\")\n```\n\n### Our `.gitlab-ci.yml` configuration file\n\nNow, we have a CI/CD runner associated with our project so we're ready to try a\npipeline. Let's see what's in our `.gitlab-ci.yml` file:\n\n```yaml\nstages:\n  - build\n\nvariables:\n  LC_ALL: \"en_US.UTF-8\"\n  LANG: \"en_US.UTF-8\"\n  GIT_STRATEGY: clone\n\nbuild:\n  stage: build\n  script:\n    - bundle install\n    - bundle exec fastlane flappybuild\n  artifacts:\n    paths:\n    - ./FlappyBird.ipa\n```\n\nYes, that's really it! [We set UTF-8 locale for _fastlane_ per their\nrequirements](https://docs.fastlane.tools/getting-started/ios/setup/#set-up-environment-variables),\nuse a `clone` strategy with the `shell` executor to ensure we have a clean\nworkspace each build, and then simply call our `flappybuild` _fastlane_ target,\nwhich we discussed above. This will build, sign, and deploy the latest build to\nTestFlight.\n\nWe also gather the artifact and save it with the build – note that the `.ipa`\nformat output is a signed ARM executable, so not something you can run in the\nsimulator. If you wanted a simulator output to be saved with the build, you\nwould simply add a build target that produces it and then add it to the artifact\npath.\n\n### Other environment variables\n\nThere are some special environment variables behind the scenes here that are\nmaking this work.\n\n#### `FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD` and `FASTLANE_SESSION`\n\nIn order to authenticate against the App Store for the TestFlight upload,\n_fastlane_ must be able to authenticate. In order to do this, you need to\ncreate an app-specific password to be used by CI. You can read more about this\nprocess in [this documentation](https://docs.fastlane.tools/best-practices/continuous-integration/#use-of-application-specific-passwords-and-spaceauth).\n\nIf you're using two-factor authentication, you'll also need to generate the\n`FASTLANE_SESSION` variable – instructions are in the same place.\n\n#### `FASTLANE_USER` and `FASTLANE_PASSWORD`\n\nIn order for [_cert_ and _sigh_](https://docs.fastlane.tools/codesigning/getting-started/#using-cert-and-sigh)\nto be able to fetch the provisioning profile and certificates on demand, the\n`FASTLANE_USER` and `FASTLANE_PASSWORD` variables must be set. You can read more\nabout this [here](https://docs.fastlane.tools/best-practices/continuous-integration/#environment-variables-to-set).\nYou may not need these if you are using some other approach to signing.\n\n## In closing...\n\nRemember, you can see a working project with all of this set up by heading over\nto my [simple demo app](https://gitlab.com/jyavorska/flappyokr).\n\nHopefully this has been helpful and has inspired you to get iOS builds and\npublishing working within your GitLab project. There is some good additional\n[CI/CD best-practice](https://docs.fastlane.tools/best-practices/continuous-integration/)\ndocumentation for _fastlane_ if you get stuck anywhere,\nand you could also consider using the `CI_BUILD_ID` (which increments each build)\nto [automatically increment a version](https://docs.fastlane.tools/best-practices/continuous-integration/gitlab/#auto-incremented-build-number).\n\nAnother great capability of _fastlane_ to try is the ability to\n[automatically generate screenshots](https://docs.fastlane.tools/getting-started/ios/screenshots/)\nfor the App Store – it's just as easy to set up as the rest of this has been.\n\nWe'd love to hear in the comments how this is working for you, as well as your\nideas for how we can make GitLab a better place to do iOS development in general.\n\nPhoto by eleven_x on [Unsplash](https://unsplash.com/photos/lwaw_DL09S4)\n{: .note}\n",[108,230,9],{"slug":4362,"featured":6,"template":683},"ios-publishing-with-gitlab-and-fastlane","content:en-us:blog:ios-publishing-with-gitlab-and-fastlane.yml","Ios Publishing With Gitlab And Fastlane","en-us/blog/ios-publishing-with-gitlab-and-fastlane.yml","en-us/blog/ios-publishing-with-gitlab-and-fastlane",{"_path":4368,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4369,"content":4375,"config":4380,"_id":4382,"_type":13,"title":4383,"_source":15,"_file":4384,"_stem":4385,"_extension":18},"/en-us/blog/is-serverless-the-end-of-ops",{"title":4370,"description":4371,"ogTitle":4370,"ogDescription":4371,"noIndex":6,"ogImage":4372,"ogUrl":4373,"ogSiteName":670,"ogType":671,"canonicalUrls":4373,"schema":4374},"Is serverless the end of ops?","What is Serverless architecture, what are the pros and cons of using it and where will it go in the future?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671845/Blog/Hero%20Images/serverless-ops-blog.jpg","https://about.gitlab.com/blog/is-serverless-the-end-of-ops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Is serverless the end of ops?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-09-12\",\n      }",{"title":4370,"description":4371,"authors":4376,"heroImage":4372,"date":4377,"body":4378,"category":1249,"tags":4379},[2390],"2019-09-12","\nWe’re not playing tricks when we say [serverless](/topics/serverless/) isn’t actually serverless. It’s not that servers aren’t doing work, it’s just that _your_ servers aren’t necessarily having to do the work. In these exciting times of automation, not having to worry about servers seems pretty appealing.\n\n[Serverless architecture has an annual growth rate of over 700%](https://hackernoon.com/severe-truth-about-serverless-security-and-ways-to-mitigate-major-risks-cd3i3x6f) and shows no signs of slowing down. Its popularity is all due to the operational efficiency it promises. Instead of worrying about infrastructure, you can essentially outsource those responsibilities to your cloud provider. Once you specify the resources your code requires, the cloud provider provisions the servers and deploys. Even better, you only pay for what is used.\n\nThe dream of serverless computing is pretty simple: Developers deploy into infrastructures they don’t have to manage, set up, or maintain. Once they upload a simple cloud function it _just works_. Since organizations are only paying for what they use, this system is infinitely scalable, and because this is all managed by a cloud provider, they take over security as well.\n\nWith a serverless architecture carrying all of the ops load, what does that mean for sysadmins?\n\n## Serverless: The end of ops?\n\nServerless hype hasn’t been without skepticism. On the ops side of things, there has been some concern that serverless is trying to force ops out of the picture. A successful [DevOps team structure](/topics/devops/build-a-devops-team/) is all about dev and ops working together but, as we well know, there are some challenges to overcome. For one: dev and ops teams are incentivized by vastly different things. Development wants faster feature delivery, whereas operations wants stability and availability. These two goals contradict each other. With serverless bypassing ops altogether, it unintentionally reinforces the “ops as a barrier” trope.\n\nGetting to the point: No, serverless is not the end of ops as we know it. Ops looks after monitoring, security, networking, support, and the overall stability of a system. Serverless is just one way of managing systems, but it isn’t the only way. [The sysadmin is still happening – you’re just outsourcing it with serverless](https://martinfowler.com/articles/serverless.html), and that’s not necessarily a bad (or good) thing.\n\nEven with so many new technologies and methodologies out there – Kubernetes, serverless, containerization – the basics of computing remain the same. It’s only when we understand the fundamentals and commit to building reliable code that we can make the most of these new platforms.\n\n[In a recent interview with Google Staff Developer Advocate Kelsey Hightower](/blog/kubernetes-chat-with-kelsey-hightower/), one of the biggest challenges he mentions is the “all-or-nothing” approach. “Either I’m all serverless, or I’m all Kubernetes, or I’m all traditional infrastructure. That has never made sense in the history of computing.” Ultimately, you don’t have to choose: Pick the platforms that work best for the job. Monoliths are easy to build and run, and microservices and Kubernetes can help organizations scale faster. Serverless is just another tool that teams can use to keep innovating.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/9OHNejqXOoo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nVideo directed and produced by [Aricka Flowers](/company/team/#arickaflowers)\n{: .note}\n\n## Serverless pros and cons\n\nAs with any architecture, there are going to be some benefits and some disadvantages. It’s important to weigh the pros and cons carefully against your organization’s needs.\n\n### Less operational overhead\n\nThis is frequently listed as one of the biggest advantages of serverless. Security patches, server upgrades, and other maintenance are already taken care of, which can free up resources for more important things.\n\n### Scalability\n\nYou just upload a code/function and your cloud provider handles the rest. [Serverless allows as many functions to be run (in parallel, if necessary) as needed to continually service all incoming requests](https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9). Or you can have serverless run an entire application (with frontend, backend, etc.) and still reap the benefits. Because you’re not boxed into a certain pricing structure or number of minutes, serverless can be infinitely scalable (in theory).\n\n### Less operating costs\n\nYou’re only using what you need and all costs are purely based on usage. Finances are dynamic, which is more representative of how companies actually operate.\n\nOne example of this concept is comparing a rideshare service to the costs of owning a vehicle. With a car, there are costs you pay regardless of usage (insurance, registration, car payment), there are costs you pay depending on the usage (gas, maintenance), and then there are additional costs tied to unforeseen circumstances (accidents, that pothole again). With a rideshare, you’re just paying to go from point A to point B – all car costs we listed previously are being taken care of by someone else.\n\n### Less control\n\nOften cited as the biggest con, what you gain in reduced operational costs, complexity, and engineering lead time comes with [increased vendor dependencies](https://martinfowler.com/articles/serverless.html) and less oversight. There has to be a lot of trust in the cloud vendor since you’ll be unable to manage the server yourself. Not having control of your system means that if errors happen, you’re reliant on someone else to fix them. In business, no one cares more about your problems than you do.\n\n### Potential security risks\n\nWhile cloud vendors will manage security for you, and are generally well equipped for that task, it’s the architecture of serverless itself that could introduce vulnerabilities into the system. The problem is especially true for serverless applications built on top of microservices, with independent pieces of software interacting through numerous APIs. Gartner warns that [APIs will become the major source of data breaches by 2022](https://www.gartner.com/doc/3834704/build-effective-api-security-strategy).\n\n### Unpredictable costs\n\nHow can we list costs as both a pro and a con? That’s mainly due to the elasticity serverless offers. Since everything is event-triggered, rather than paid up front, elasticity becomes a double-edged sword: You’re not paying for cloud usage you don’t need, but it being so easy to use means you may end up using more.\n\nFor another real-world example of this concept in action, let’s examine ketchup, mainly the introduction of the plastic squeeze bottle.\n\nHeinz ketchup had been served in the iconic glass bottles we all know and love since 1890, but in 1983 the Heinz corporation unveiled the squeezable plastic bottle to consumers. This was heralded as a huge innovation – consumers could squeeze more precisely, the bottles were unbreakable which reduced losses in shipment, and the ergonomic design made it perfect for hands of all sizes. After the introduction of the new squeezable bottle, [ketchup sales went up by 3.7% from the prior year](https://www.npr.org/sections/thesalt/2014/04/29/306911004/whats-the-secret-to-pouring-ketchup-know-your-physics). Why? Now that ketchup could be dispensed more easily, people used a lot more of it. Instead of tapping on a glass bottle hoping for a drop, the ketchup cup runneth over.\n\nWith serverless being so easy to use, it’s best to assume that developers will use it more than you expect.\n\n## Where are we on our serverless journey?\n\nSo much of the literature about serverless comes from the cloud providers themselves, so of course it focuses on the most idealized vision of what serverless can be. As a result, those in the ops community felt like they were being forced out, and organizations were too busy paying attention to the benefits to see the potential downsides.\n\nServerless opens up a lot of opportunities in DevOps, and offers a unique solution for many use cases. Does this mean that sysadmins everywhere will soon be out of a job? Probably not. Serverless is just another tool in the toolbox, and at GitLab we’re exploring how to help users leverage Knative and Kubernetes to define and manage serverless functions in GitLab. We’re also looking into how we can be even more multi-faceted. Some users want to work with a Kubernetes cluster, some want to push a serverless function into AWS Lambda. We can already help with monoliths and microservices, and we’re actively working on supporting serverless as well.\n\nInterested in joining the conversation for this category? Please join us in our [public epic](https://gitlab.com/groups/gitlab-org/-/epics/155) where we discuss this topic and we can answer any questions you might have. Everyone can contribute.\n\nPhoto by [Tomasz Frankowski](https://unsplash.com/@sunlifter?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1936,9,976],{"slug":4381,"featured":6,"template":683},"is-serverless-the-end-of-ops","content:en-us:blog:is-serverless-the-end-of-ops.yml","Is Serverless The End Of Ops","en-us/blog/is-serverless-the-end-of-ops.yml","en-us/blog/is-serverless-the-end-of-ops",{"_path":4387,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4388,"content":4394,"config":4400,"_id":4402,"_type":13,"title":4403,"_source":15,"_file":4404,"_stem":4405,"_extension":18},"/en-us/blog/issue-boards-anniversary",{"title":4389,"description":4390,"ogTitle":4389,"ogDescription":4390,"noIndex":6,"ogImage":4391,"ogUrl":4392,"ogSiteName":670,"ogType":671,"canonicalUrls":4392,"schema":4393},"The evolution of the GitLab Issue Board","Celebrating one year of flexible, integrated project and release management workflows inside GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680378/Blog/Hero%20Images/issue-boards-anniversary.jpg","https://about.gitlab.com/blog/issue-boards-anniversary","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The evolution of the GitLab Issue Board\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Lindberg\"}],\n        \"datePublished\": \"2017-08-23\",\n      }",{"title":4389,"description":4390,"authors":4395,"heroImage":4391,"date":4397,"body":4398,"category":298,"tags":4399},[4396],"Erica Lindberg","2017-08-23","\n\n[Collaboration is driven by conversation](https://www.forbes.com/sites/laurencebradford/2016/12/30/the-future-of-web-development-with-gitlab-ceo-sid-sijbrandij/#7b8895b04148). It should be a natural and integrated\npractice throughout the development lifecycle, not a manual, contrived process\nthat requires administration and maintenance. By integrating every step of the\nsoftware development lifecycle and providing all the necessary collaboration\ntools, GitLab by default provides all the capabilities modern development teams need to support cross-functional collaboration at scale. GitLab was created so teams could focus more on their work, not on configuring their tools.\n\n\u003C!-- more -->\n\nLast year, we announced the first iteration of the [GitLab Issue Board](/stages-devops-lifecycle/issueboard/), a major\nmilestone in our mission to create an open source and integrated\nproduct for modern software development. Built on top of our integrated issue\ntracking system, it became possible to visualize your work and customize your\nworkflow inside of GitLab.\n\nToday, GitLab comes with everything you need to plan and track projects and\nreleases, including issues (tracker and board), milestones, burndown charts,\nchat integration, and more. Communication is centralized, plans\nand progress are visible, and work is linked, making collaboration frictionless.\n\nTo celebrate our progress over the past year, no small thanks to the community and feedback from our customers, we wanted to take a look at where\nthe Issue Board has gone since we launched its first iteration in GitLab 8.11.\n\n## The evolution of the GitLab Issue Board\n\nAt GitLab, we practice [Conversational Development](http://conversationaldevelopment.com/). Our software development is centered around conversations on what can be improved, how to implement it,\nwhether or not it worked, and if it achieved the expected value. Instead of\nwaiting months to release a “perfect” feature, we work on smaller, functional\nchanges that can get into the hands of our users much more quickly. There’s a few reasons why we develop software this way: in addition to being\nable to deliver value faster, we can also react to the market and iterate faster with more frequent feedback loops, and if something goes wrong, it’s easier to spot and fix the problem.\n\nThis is how we built the GitLab Issue Board. We started by shipping the basic\nfunctionality needed to allow users to visualize and track their issues. Over the last 12 months, we’ve released small changes every month. Today, the GitLab Issue Board has everything you need to plan and track your projects and releases.\n\nHere’s how we built it over multiple monthly releases:\n\n### August—October 2016 | GitLab 8.11-13\nThe [GitLab Issue Board](https://docs.gitlab.com/ee/user/project/issue_board.html)\nis released in 8.11. Built on top of our integrated issue\ntracking system, it uses labels from issues to create lists on a board. You can drag and drop lists to organize your workflow, move issues between lists, and labels are updated automatically as you move them across the board.\n\nUsers now have the ability to [create workflows inside of GitLab](https://docs.gitlab.com/ee/user/project/issue_board.html#creating-workflows).\n\n\u003Cimg src=\"/images/8_11/issue_boards.gif\" alt=\"Issue Boards in GitLab 8.11\" class=\"shadow\">\n\n[Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards) are released in 8.13. Users can now create multiple\nworkflows, allowing different teams to create their own customized boards with\nthe same issues. Once a board is finished, you can leave it as is to review later, or recycle it.\n\n\u003Cimg src=\"/images/8_13/m_ib.gif\" alt=\"Multiple Issue Boards in GitLab 8.13\" class=\"shadow\">\n\n### January—February 2017 | GitLab 8.16-17\nNew search and filter interface is added to the [Issue Tracker](https://docs.gitlab.com/ee/user/project/issues/index.html) in 8.16, making it easier for users to search and filter their issues by different attributes such as author, assignee, milestone, and label.\n\nThe new search and filter interface is added to the Issue Board in GitLab 8.17,\nimproving usability. A modal window is added to display all issues that don’t belong to a list for easier search and filtering.\nIssues can be added to a list from the modal, and issues can be removed from a\nlist on the board.\n\n\u003Cimg src=\"/images/8_17/board_modal.png\" alt=\"Add issues modal in board in GitLab 8.17\" class=\"shadow\">\n\n### March 2017 | GitLab 9.0\n[Milestones](https://docs.gitlab.com/ee/user/project/milestones/index.html) are added to the Issue Board in GitLab 9.0 enabling users to organize issues into cycles or sprints with a start date and deadline. Issues can be filtered on the board by milestone, or new boards can be created for individual milestones.\n\n\u003Cimg src=\"/images/9_0/boards_milestone.gif\" alt=\"Boards Milestone\" class=\"shadow\">\n\nThe ability to [reorder issues in a Board list](https://docs.gitlab.com/ee/user/project/issue_board.html#re-ordering-an-issue-in-a-list) is also introduced in 9.0. Now, users prioritize issues within a list simply by dragging and dropping the issue card.\n\n\u003Cimg src=\"/images/9_0/boards_reorder.gif\" alt=\"Boards Reorder\" class=\"shadow\">\n\n## Get started with GitLab Issue Boards\n\nStart building your project and release management workflows using the Issue Board.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/CiolDtBIOA0\" frameborder=\"0\" allowfullscreen>\u003C/iframe>\n\nIn this video, Discussion Product Manager Victor Wu demonstrates how to use GitLab Issue Boards for Agile and Scrum-style planning and tracking.\n\n### Documentation Quick Links\n\n- [Issue Board Overview](https://docs.gitlab.com/ee/user/project/issue_board.html#overview)\n- [Issue Boards for Scrum](https://docs.gitlab.com/ee/user/project/issue_board.html#scrum-team)\n- [Issue Board terminology](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-board-terminology)\n- [Creating workflows](https://docs.gitlab.com/ee/user/project/issue_board.html#creating-workflows)\n\n## Help us celebrate our #Issueversary\n\nEveryone has an Issue Board story. Maybe you spent months on a long conversation to get your legal team to embrace the Kanban and promptly blew their minds. Maybe your team is full of diehards driven by strongly held opinions over exactly how many stages yours should have. Maybe you're a remote worker and your issue board is one of the main ways you keep up with teammates spread across the globe.\n\nWhatever your story is, we want to hear from you! Help us celebrate a year of the GitLab Issue Board by [sending us your Issue Board story](https://docs.google.com/forms/d/e/1FAIpQLSf_0DTiQX1X048X6ioAVLRLSBwJzVSG1LH7LupoFdsascPAAw/viewform)\nfor your chance to win free GitLab swag. We'll tweet out our favorites and announce the winners on September 5.\n",[9,894],{"slug":4401,"featured":6,"template":683},"issue-boards-anniversary","content:en-us:blog:issue-boards-anniversary.yml","Issue Boards Anniversary","en-us/blog/issue-boards-anniversary.yml","en-us/blog/issue-boards-anniversary",{"_path":4407,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4408,"content":4414,"config":4420,"_id":4422,"_type":13,"title":4423,"_source":15,"_file":4424,"_stem":4425,"_extension":18},"/en-us/blog/issue-labels-can-now-be-scoped",{"title":4409,"description":4410,"ogTitle":4409,"ogDescription":4410,"noIndex":6,"ogImage":4411,"ogUrl":4412,"ogSiteName":670,"ogType":671,"canonicalUrls":4412,"schema":4413},"Issue labels can now be scoped!","A small change with a huge impact: Scoped Labels can help teams customize their workflow and speed up delivery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679729/Blog/Hero%20Images/scopedlabels.jpg","https://about.gitlab.com/blog/issue-labels-can-now-be-scoped","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Issue labels can now be scoped!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-06-20\",\n      }",{"title":4409,"description":4410,"authors":4415,"heroImage":4411,"date":4417,"body":4418,"category":1249,"tags":4419},[4416],"Suri Patel","2019-06-20","\n\nGreat news, everyone!\n[Hailed as one of the best inventions since sliced bread](https://gitlab.com/gitlab-com/marketing/corporate-marketing/issues/682),\n[Scoped Labels](/releases/2019/04/22/gitlab-11-10-released/#scoped-labels) can make your\ncustom workflows even cooler. We’re excited to share how using this small feature can\naccelerate delivery.\n\nPlease note that this is a paid feature available to Premium and Ultimate for [self-managed](/pricing/#self-managed) GitLab\nor Silver and Gold tiers for [GitLab.com](/pricing/).\n{: .alert .alert-info.text-center}\n\n## What are GitLab Scoped Labels?\n\nIt all started with\n[an issue detailing a feature with a simple idea](https://gitlab.com/gitlab-org/gitlab-ee/issues/9175):\nHelp teams that use issue boards for workflow. With Scoped Labels, teams can apply\nmutually exclusive labels (that share the same scope) to an issue, merge request,\nor epic, solving custom fields and custom workflow states use cases. Scoped Labels\nmake it possible for teams to define a basic custom field that avoids confusion and\ncleans up issue lists (i.e. fewer duplicate labels).\n\n![Scoped labels](https://about.gitlab.com/images/blogimages/scoped-labels.png){: .shadow.center.medium}\n\nBy using Scoped Labels, teams can create custom labels and apply them to a\ngiven issue, automatically removing any other existing, related labels. For example,\nif you have the labels `workflow::development`, `workflow::review`, and `workflow::deployed`,\nrepresenting the workflow states of your team, you can advance the issue\n(e.g., `workflow::development` to `workflow::review`) by applying the next label\nwithout having to remove the original one.\n\nYou may already be familiar with this behavior, since it’s similar to moving\nissues across label lists in an issue board. Now, team members who don’t directly work\nin an issue board or who want to advance workflow states consistently in\nissues themselves can do so using Scoped Labels.\n\n## How Scoped Labels accelerate delivery\n\nYou might be thinking that Scoped Labels is too small of a feature to make a splash,\nbut hear me out, it can help reduce cycle time. Here's how:\n\n1. If you want a custom field on your issues, like a drop-down with a few items\nyou can select (e.g., colors or stages), Scoped Labels prevent conflicts where\nnormally only one color or one stage is possible. By removing conflicts, multiple\nteams can scope an issue, merge request, or epic.\n1. You can define the workflow steps for an issue (e.g., proposal, design,\ndevelopment, QA, acceptance, deploy), creating the basis for how you can eventually\nmeasure the flow of work though the system (based on how long issues have specific labels).\n\nThese two use cases illustrate how Scoped Labels can help teams work concurrently\non features and measure their efforts.\n\n## Scoped Labels: A feature film\n\nWant to see Scoped Labels in action? Get your popcorn ready and enjoy the show! 🍿\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4BCBby6du3c\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCheck out the [documentation on Scoped Labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) for more.\n\nCover image by [ Jo Szczepanska](https://unsplash.com/@joszczepanska?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/9OKGEVJiTKk)\n{: .note}\n",[9,894,1164],{"slug":4421,"featured":6,"template":683},"issue-labels-can-now-be-scoped","content:en-us:blog:issue-labels-can-now-be-scoped.yml","Issue Labels Can Now Be Scoped","en-us/blog/issue-labels-can-now-be-scoped.yml","en-us/blog/issue-labels-can-now-be-scoped",{"_path":4427,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4428,"content":4433,"config":4439,"_id":4441,"_type":13,"title":4442,"_source":15,"_file":4443,"_stem":4444,"_extension":18},"/en-us/blog/iterating-on-sso",{"title":4429,"description":4430,"ogTitle":4429,"ogDescription":4430,"noIndex":6,"ogImage":1055,"ogUrl":4431,"ogSiteName":670,"ogType":671,"canonicalUrls":4431,"schema":4432},"How we are iterating on Group Single Sign On for GitLab.com","Here's some insight into our approach to improving a key enterprise capability for GitLab.com, SSO.","https://about.gitlab.com/blog/iterating-on-sso","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we are iterating on Group Single Sign On for GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Brinkman\"}],\n        \"datePublished\": \"2019-01-17\",\n      }",{"title":4429,"description":4430,"authors":4434,"heroImage":1055,"date":4436,"body":4437,"category":298,"tags":4438},[4435],"Eric Brinkman","2019-01-17","\n\nAt GitLab, we do things a little differently. We believe in shipping what we call the MVC, or minimum viable change, rather than waiting for something to be perfect. We’d rather our customers get their hands on a portion of the feature to ensure we are on the right track and that our next iteration is spot on, than wait several months to ship a full feature that may not be exactly what customers desire. In fact, [iteration is one of our six core values](https://handbook.gitlab.com/handbook/values/#iteration) at GitLab, and it’s something that drives our day-to-day decision making. In this blog post, we’ll take a look at how a recent enterprise authentication feature challenged our organization with respect to prioritization, core values, and [transparency](https://handbook.gitlab.com/handbook/values/#transparency) with customers. We’ll also discuss our vision for GitLab.com, and the associated challenges we’ve come across while ensuring it’s a solution that works seamlessly for enterprise adoption of GitLab.\n\nSingle Sign On, or SSO, has been at the forefront of most enterprises’ digital transformation requirements for quite some time. Enterprise organizations require access to software to be controlled by their Identity Provider of choice as there are hundreds, if not thousands, of users. Manually provisioning users and revoking access across multiple systems when employees leave is not scalable and is error prone in organizations of any size.\n\nWe’ve long had [support for SAML, LDAP, and OAuth configuration](https://docs.gitlab.com/ee/administration/auth/) for self-managed GitLab, which assumes our customers have admin access at the instance level. While this works great for individual instances, a different approach is needed for GitLab.com, which is a giant, multi-tenant version of a single instance, primarily segregated at the group level for enterprises.\n\nIn [GitLab 11.0](/releases/2018/06/22/gitlab-11-0-released/#saml-single-sign-on-for-groups-beta), shipped in June 2018, we launched the [MVC to take the first step in SAML-based SSO on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/40). When we launched this functionality, we knew it wasn’t going to solve 100 percent of enterprise authentication needs, but rather than keeping this functionality private until we had other SSO features (such as automated provisioning of users and revocation of permissions), we decided to launch it to get as much feedback as possible, and to ensure our product velocity stays at the high levels we’ve come to expect.\n\nHere are some of the factors at play and how we're moving forward:\n\n### 1. We haven't always focused on enterprise features for GitLab.com\n\nGitLab.com has typically been the GitLab solution for hobbyists and small development teams. Enterprises have typically gravitated towards self-managed, self-hosted GitLab. Because of this bifurcation, enterprise features such as SSO were not prioritized as high in mid-2018.\n\n### The fix: We are now prioritizing enterprise features\n\nThis includes features like SSO at the top of our list. In 2019, enterprise customers looking to use GitLab are coming with a SaaS-first approach, led by a desire to get out of traditional hosting arrangements, shying away from long procure times, and looking for quick time to market on SaaS implementation. Most importantly, we’ve heard this directly from enough customers recently that we couldn't sit idly by and not activate on this.\n\n### 2. Security issues have burdened our Manage team\n\nThe [Manage](/stages-devops-lifecycle/) team, responsible for authentication at GitLab, has been hit with the most security issues of any team (170 open issues) and has been required to prioritize these over new feature releases. Manage has released [eight security fixes](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=Any&label_name[]=Manage&label_name[]=security) that we've made public since September. We're proud of this work, as it’s required to protect our customers.\n\n### The fix: Measures to improve our velocity in finding and fixing security issues\n\nWe will continue to prioritize P1 security issues above all new features and functionality, consistent with our [prioritization framework](/handbook/product/product-processes/#how-we-prioritize-work) and ensuring a secure application. If GitLab isn’t a secure application where customers can trust that their data is safe and secure, all of the features in the world won’t make a difference as we won’t be around for long. In order to improve our security posture and increase the velocity at which we identify and fix security vulnerabilities, we've launched our [HackerOne Bug Bounty Program](https://hackerone.com/gitlab) with rewards of up to $12,000! [This program was launched](/blog/gitlab-hackerone-bug-bounty-program-is-public-today/) on Dec. 12, 2018 and has already paid out over $265,000 in bug bounties, over 215 reports!\n\n### 3. The Manage team has been stretched\n\nThe Manage team has an incredibly broad scope, ranging from permissions and authentication, to cycle analytics and DevOps scoring for organizations. In the few spare cycles our engineering team has had in between security issues, we had to spend time on high-severity, non-security bugfixes and promised features – like [adding smart card support](https://gitlab.com/gitlab-org/gitlab-ee/issues/726) and keeping instances more secure by [prohibiting admin impersonation](https://gitlab.com/gitlab-org/gitlab-ce/issues/40385). Simply put, we didn’t have enough resources to activate on all fronts.\n\n### The fix: We're growing to meet demand\n\nGitLab will grow from ~400 employees at the start of 2019 to ~800 by the end of the year. We will be splitting Manage into several teams, starting with the [Fulfillment team](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/18087), allowing for more resources to push along each of these areas in parallel.\n\nGitLab.com is one of our highest-growth areas based on most Key Performance Indicators, including monthly active users, revenue, and feature usage. It’s the quickest way to get started using GitLab, and we need to do a better job knocking down barriers for large organization adoption. We’re already activating heavily on [SAML-based SSO for enterprises](https://gitlab.com/groups/gitlab-org/-/epics/731) in early 2019 and look forward to regaining our customers’ trust in being a company that quickly adapts to your feedback.\n\nIf this type of organization and [product philosophy](/handbook/product/) seems exciting to you, drop me a note at ebrinkman@gitlab.com. We will be doubling the size of the product team and are looking for talented product managers to help us scale GitLab and drive the direction and growth of our application.\n",[9,680,704],{"slug":4440,"featured":6,"template":683},"iterating-on-sso","content:en-us:blog:iterating-on-sso.yml","Iterating On Sso","en-us/blog/iterating-on-sso.yml","en-us/blog/iterating-on-sso",{"_path":4446,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4447,"content":4453,"config":4460,"_id":4462,"_type":13,"title":4448,"_source":15,"_file":4463,"_stem":4464,"_extension":18},"/en-us/blog/jira-importer-research",{"title":4448,"description":4449,"ogTitle":4448,"ogDescription":4449,"noIndex":6,"ogImage":4450,"ogUrl":4451,"ogSiteName":670,"ogType":671,"canonicalUrls":4451,"schema":4452},"Jira Importer Research","Senior Product Designer Holly Reynolds is seeking participants for research surrounding importing Jira issues.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679490/Blog/Hero%20Images/jira-importer-blog-post.png","https://about.gitlab.com/blog/jira-importer-research","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jira Importer Research\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-04-08\",\n      }",{"title":4448,"description":4449,"authors":4454,"heroImage":4450,"date":4456,"body":4457,"category":1353,"tags":4458},[4455],"Holly Reynolds","2020-04-08","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nWorking with multiple DevOps applications including Jira and GitLab? Looking to consolidate to or test drive GitLab with your own existing Jira issues? We are researching ways to provide options for importing issues from Jira into GitLab and need your help!\n\n**Problem Overview**\nWe believe our [Project Management](https://about.gitlab.com/solutions/agile-delivery/) users need a way to easily transfer existing issues from Jira into GitLab beyond what's possible with CSV exports. We want to dive deeper into understanding what will provide the most value for these users in this import process from the start and what their expectations are for this experience.\n\n**Our recruiting Challenge**\nThis is a bit of a unique group we're seeking feedback from in that a specific persona may not always apply. For example, both a [Systems Admin](https://about.gitlab.com/handbook/product/personas/#sidney-systems-administrator) or a [DevOps Engineer](https://about.gitlab.com/handbook/product/personas/#devon-devops-engineer) could be responsible for helping their team transition from Jira to GitLab. We'd like to hear from anyone with issues currently in Jira that would like to import them into GitLab via an API.\n",[9,3138,1672,4459,1355],"developer survey",{"slug":4461,"featured":6,"template":683},"jira-importer-research","content:en-us:blog:jira-importer-research.yml","en-us/blog/jira-importer-research.yml","en-us/blog/jira-importer-research",{"_path":4466,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4467,"content":4473,"config":4479,"_id":4481,"_type":13,"title":4482,"_source":15,"_file":4483,"_stem":4484,"_extension":18},"/en-us/blog/kubernetes-overview-operate-cluster-data-on-the-frontend",{"title":4468,"description":4469,"ogTitle":4468,"ogDescription":4469,"noIndex":6,"ogImage":4470,"ogUrl":4471,"ogSiteName":670,"ogType":671,"canonicalUrls":4471,"schema":4472},"Kubernetes overview: Operate cluster data on the frontend","GitLab offers a built-in solution for monitoring your Kubernetes cluster health. Learn more about the technical design and functionality with this detailed guide.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099045/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2816%29_3L7ZP4GxJrShu6qImuS4Wo_1750099045397.png","https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kubernetes overview: Operate cluster data on the frontend\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Anna Vovchenko\"}],\n        \"datePublished\": \"2024-06-20\",\n      }",{"title":4468,"description":4469,"authors":4474,"heroImage":4470,"date":4476,"body":4477,"category":849,"tags":4478},[4475],"Anna Vovchenko","2024-06-20","Accessing real-time cluster information is crucial for verifying successful software deployments and initiating troubleshooting processes. In this article, you'll learn about GitLab's enhanced Kubernetes integration, including how to leverage the Watch API for real-time insights into deployment statuses and streamlined troubleshooting capabilities. \n\n## What are GitLab's Kubernetes resources?\n\nGitLab offers a dedicated [dashboard for Kubernetes](https://gitlab.com/groups/gitlab-org/-/epics/2493 \"Visualize the cluster state in GitLab\") to understand the status of connected clusters with an intuitive visual interface. It is integrated into the Environment Details page and shows resources relevant to the environment. Currently, three types of Kubernetes resources are available:\n\n- pods filtered by the Kubernetes namespace\n- services\n- Flux resource ([HelmRelease](https://fluxcd.io/flux/components/helm/helmreleases/) or [Kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/))\n\nFor these resources, we provide general information, such as name, status, namespace, age, etc. It is represented similarly to what the [kubectl](https://kubernetes.io/docs/reference/kubectl/) command would show when run from the Kubernetes cluster. More details can be found when clicking each resource: The side drawer shows the list of labels, annotations, and detailed status and spec information presented as read-only YAML code blocks.\n\nThe information provided helps to visualize the cluster state, spot any issues, and debug problematic deployments right away.\n\n## Frontend to cluster communication: The GitLab solution\n\nWe have developed a range of tools and solutions to enable a seamless connection and management of Kubernetes clusters within GitLab. One of the core components of this system is the [GitLab agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/install/). This powerful tool provides a secure bidirectional connection between a GitLab instance and a Kubernetes cluster. It is composed of two main components: **agentk** and **KAS** (Kubernetes agent server).\n\n![Kubernetes flow chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099055229.png)\n\nagentk is a lightweight cluster-side component. It is responsible for establishing a connection to a KAS instance and waiting for requests to process. It is proxying requests from KAS to Kubernetes API. It may also actively send information about cluster events to KAS.\n\nWhile agentk is actively communicating with the cluster, KAS represents a GitLab server-side component. It is responsible for:\n\n- accepting requests from agentk\n- authenticating agentk requests by querying GitLab backend\n- fetching the agent's configuration from a corresponding Git repository using Gitaly\n- polling manifest repositories for GitOps support\n\nWe implemented the agent access rights feature to provide access from the GitLab frontend to the cluster in a secure and reliable way. To enable the feature, the user should update the agent’s configuration file by adding the [user_access](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html) section with the following parameters: `projects`, `groups`, and `access_as` to specify which projects can access cluster information via the agent and how it should authenticate.\n\nOnce this is done, the frontend can connect to the cluster by sending a request to the Rails controller, which should set a `gitlab_kas cookie`. This cookie is then added to the request sent to KAS together with the agent ID and Cross-Site Request Forgery (CSRF) token. Upon receiving the request, KAS checks the user’s authorization and forwards it to agentk, which makes an actual request to the Kubernetes API. Then the response goes all the way back from the agentk to KAS and finally to the GitLab client.\n\n![Kubernetes overview - how it works](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099055229.png)\n\nTo integrate this logic on the GitLab frontend and use it within the Vue app, we developed a JavaScript library: [@gitlab/cluster-client](https://gitlab.com/gitlab-org/cluster-integration/javascript-client). It is generated from the Kubernetes OpenAPI specification using the typescript-fetch generator. It provides all the Kubernetes APIs in a way that can be used in a web browser.\n\n## Introducing the Watch API\n\nThe most challenging task is to provide **real-time updates** for the Kubernetes dashboard. Kubernetes introduces the concept of watches as an extension of GET requests, exposing the body contents as a [readable stream](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams). Once connected to the stream, the Kubernetes API pushes cluster state updates similarly to how the `kubectl get \u003Cresource> --watch` command works. The watch mechanism allows a client to fetch the current state of the resource (or resources list) and then subscribe to subsequent changes, without missing any events. Each event contains a type of modification (one of three types: added, modified, or deleted) and the affected object.\n\nWithin the `WatchApi` class of the `@gitlab/cluster-client` library, we've developed a systematic approach for interacting with the Kubernetes API. This involves fetching a continuous stream of data, processing it line by line, and managing events based on their types. Let's explore the key components and functionalities of this approach:\n\n1. Extending the Kubernetes API: Within the WatchApi class, we extend the base Kubernetes API functionality to fetch a continuous stream of data with a specified path and query parameters. This extension enables efficient handling of large datasets, as the stream is processed line by line.\n  2. Decoding and event categorization: Upon receiving the stream, each line, typically representing a JSON object, is decoded. This process extracts relevant information and categorizes events based on their types.\n3. Internal data management: The `WatchApi` class maintains an internal data array to represent the current state of the streamed data, updating it accordingly as new data arrives or changes occur. \n4. The `WatchApi` class implements methods for registering event listeners, such as `onData`, `onError`, `onTimeout`, and `onTerminate`. These methods allow developers to customize their application's response to events like data updates, errors, and timeouts. \n\nThe code also handles scenarios such as invalid content types, timeouts, and errors from the server, emitting corresponding events for clients to handle appropriately. **With this straightforward, event-driven approach, the `WatchApi` class allows developers to create responsive real-time applications efficiently.**\n\n![Kubernetes overview - flow chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099055231.png)\n\n## How is the Kubernetes overview integrated with the GitLab frontend?\n\nCurrently, we have two Kubernetes integrations within the product: the Kubernetes overview section for the Environments and the full Kubernetes dashboard as a separate view. The latter is a major effort of representing all the available Kubernetes resources with filtering and sorting capabilities and a detailed view with the full information on the metadata, spec, and status of the resource. This initiative is now on hold while we are searching for the most useful ways of representing the Kubernetes resources related to an environment.\n\n[The Kubernetes overview](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html) on the Environments page is a detailed view of the Kubernetes resources related to a specific environment. To access the cluster state view, the user should select an agent installed in the cluster with the appropriate access rights, provide a namespace (optionally), and select a related Flux resource.\n\nThe view renders a list of Kubernetes pods and services filtered by the namespace representing their statuses as well as the Flux sync status. Clicking each resource opens a detailed view with more information for easy issue spotting and high-level debugging. \n\n![Kubernetes overview - list of Kubernetes pods and services](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099055233.png)\n\nWe need to set up a correct configuration object that will be used for all the API requests. In the configuration, we need to specify the URL provided by the KAS, that proxies the Kubernetes APIs; the GitLab agent ID to connect with; and the CSRF token. We need to include cookies so that the `kas_cookie` gets picked up and sent within the request.\n\n```javascript\ncreateK8sAccessConfig({ kasTunnelUrl, gitlabAgentId }) {\n  return {\n    basePath: kasTunnelUrl,\n    headers: {\n      'GitLab-Agent-Id': gitlabAgentId,\n      ...csrf.headers,\n    },\n    credentials: 'include',\n  };\n}\n```\n\nAll the API requests are implemented as GraphQl client queries for efficiency, flexibility, and ease of development. The query structure enables clients to fetch data from various sources in one request. With clear schema definitions, GraphQL minimizes errors and enhances developer efficiency.\n\nWhen first rendering the Kubernetes overview, the frontend requests static lists of pods, services, and Flux resource (either HelmRelease or Kustomization). The fetch request is needed to render the empty view correctly. If the frontend tried to subscribe to the Watch API stream and one of the resource lists was empty, we would wait for the updates forever and never show the actual result – 0 resources. In the case of pods and services, after the initial request, we subscribe to the stream even if an empty list was received to reflect any cluster state changes. For the Flux resource, the changes that the user would expect the resource to appear after the initial request are low. We use the empty response here as an opportunity to provide more information about the feature and its setup. \n\n![Kubernetes overview - flux sync status unavailable](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099055235.png)\n\nAfter rendering the initial result, the frontend makes additional requests to the Kubernetes API with the `?watch=true` query parameter in the URL. We create separate watchers for each event type – data, error, or timeout. When receiving the data, we follow three steps:\n\n- transform the data\n- update the Apollo cache\n- run a mutation to update the connection status\n\n```javascript\nwatcher.on(EVENT_DATA, (data) => {\n  result = data.map(mapWorkloadItem);\n  client.writeQuery({\n    query,\n    variables: { configuration, namespace },\n    data: { [queryField]: result },\n  });\n\n  updateConnectionStatus(client, {\n    configuration,\n    namespace,\n    resourceType: queryField,\n    status: connectionStatus.connected,\n  });\n});\n```\n\nAs we show the detailed information for each resource, we rely on having the status, spec, and metadata fields with the annotations and labels included. The Kubernetes API wouldn’t always send this information, which could break the UI and throw errors from the GraphQl client. We transform the received data first to avoid these issues. We also add the `__typename` so that we can better define the data types and simplify the queries by reusing the shared fragments.\n\nAfter data stabilization, we update the Apollo cache so that the frontend re-renders the views accordingly to reflect cluster state changes. Interestingly, we can visualize exactly what happens in the cluster – for example, when deleting the pods, Kubernetes first creates the new ones in the pending state, and only then removes the old pods. Thus, for a moment we can see double the amount of pods. We can also verify how the pods proceed from one state to another in real-time. This is done with the combination of added, deleted, and modified events received from the Kubernetes APIs and processed in the `WatchApi` class of the `@gitlab/cluster-client` library.\n\n![Kubernetes overview - states of connection status](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099055/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099055236.gif)\n\nBy default, with a single Watch request, we get a stream of events for five minutes, and then it hits the timeout. We need to properly reflect this on the frontend so that the user is aware of any outdated information. To achieve this, we introduced a `k8sConnection` query together with `reconnectToCluster` mutation. We have a UI element – a badge with a tooltip to indicate the connection status. It has three states: connecting, connected, and disconnected. The state gets updated within every step of the UX flow. First, we set it to `connecting` once the Watch client gets created. Then we update it to `connected` with the first received piece of data. Last, we trigger the mutation for `disconnected` state when an error or timeout event occurs. This way, we can let the user refresh the view and reconnect to the stream without the need of refreshing the browser tab. Relying on the user action to reconnect to the stream helps us save resources and only request the necessary data while ensuring the accurate cluster state is available for the user at any time.\n\n## What’s next?\n\nLeveraging the Kubernetes built-in functionality for watching the Readable stream helped us to build the functionality quickly and provide the Kubernetes UI solution to our customers, getting early feedback and adjusting the product direction. This approach, however, presented technical challenges, such as the inability to utilize the GraphQl subscriptions and the need for reconnecting to the stream.\n\nWe are planning our next iterations to enhance the Kubernetes overview within GitLab UI. One of the planned iterations for the feature, [Frontend-friendly Kubernetes Watch API](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/541), is an updated mechanism of batch-watching the cluster data and moving from the fetch Readable stream to WebSockets. We are going to create a new API in KAS to expose the Kubernetes watch capability via WebSocket. This should reduce the complexity of the JavaScript code, resolve the timeout issue, and improve the compatibility of the Kubernetes APIs within GitLab frontend integrations.\n\n> Curious to learn more or want to try out this functionality? Visit our [Kubernetes Dashboard documentation](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html) for more details and configuration tips.\n",[1936,9,746],{"slug":4480,"featured":90,"template":683},"kubernetes-overview-operate-cluster-data-on-the-frontend","content:en-us:blog:kubernetes-overview-operate-cluster-data-on-the-frontend.yml","Kubernetes Overview Operate Cluster Data On The Frontend","en-us/blog/kubernetes-overview-operate-cluster-data-on-the-frontend.yml","en-us/blog/kubernetes-overview-operate-cluster-data-on-the-frontend",{"_path":4486,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4487,"content":4493,"config":4498,"_id":4500,"_type":13,"title":4501,"_source":15,"_file":4502,"_stem":4503,"_extension":18},"/en-us/blog/look-back-on-11-11-cicd",{"title":4488,"description":4489,"ogTitle":4488,"ogDescription":4489,"noIndex":6,"ogImage":4490,"ogUrl":4491,"ogSiteName":670,"ogType":671,"canonicalUrls":4491,"schema":4492},"Looking back on the 11.x releases for GitLab CI/CD","With GitLab 12.0 coming soon, it's a great time to reflect on all the features we've launched since 11.0.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666857/Blog/Hero%20Images/photo-cicdlookback.jpg","https://about.gitlab.com/blog/look-back-on-11-11-cicd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Looking back on the 11.x releases for GitLab CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-06-19\",\n      }",{"title":4488,"description":4489,"authors":4494,"heroImage":4490,"date":4495,"body":4496,"category":849,"tags":4497},[846],"2019-06-19","\nGitLab releases each month, so if you aren't paying close attention it can be easy to\nlose track of all the great features that are coming out. With an eye towards [CI/CD](/solutions/continuous-integration/)\nin particular, I'd like to take you through some of the highlights in each of our 11.x releases,\neach of which contributed to our strategy around cloud native CI/CD that has\nsecurity and smarts built right in, supports code reusability and live troubleshooting,\nand in general enables your team to make progress towards your goal of better, more\nreliable software delivery.\n\n![Release Badges](https://about.gitlab.com/images/blogimages/11x_release_logos.png){: .shadow.medium.center}\n\nFor those who don't know me, I'm the director of product for CI/CD and I've spent\nmy career (going all the way back to doing build automation of Windows 98 at my\nfirst corporate job) out of doing build and release automation and process. I love\nthis stuff, and my career move from building CI/CD implementations to building\nCI/CD tools for folks just like me has been one of the most rewarding things I've\ndone in my life. I hope that experience and passion comes through in the features\nwe've delivered – either way, I'd love to chat with you if you're a user of GitLab\nCI/CD. DM me on [Twitter](https://twitter.com/j4yav) or contact me via my [GitLab profile](https://gitlab.com/jyavorska) if you'd like to chat.\n\nAnyway, without further ado let's dive into the first 11.x release!\n\n## [GitLab 11.0](/releases/2018/06/22/gitlab-11-0-released/)\n\n### Auto DevOps Generally Available\n\nWe kicked off the 11.0 series in June 2018 by launching [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/).\nBeyond making it easy to host and collaborate on public and private repositories,\nGitLab also simplifies the rest of the process by offering the whole delivery toolchain,\nbuilt in and automated: Simply commit your code and Auto DevOps can do the rest.\nAuto DevOps is a pre-built, fully featured CI/CD pipeline that takes the best of\nGitLab CI/CD features, adds a lot of smarts around auto-detecting what's in your\nproject, and automates the entire delivery process to your Kubernetes cluster.\n\nCheck out our [quick-start guide](https://docs.gitlab.com/ee/topics/autodevops/cloud_deployments/auto_devops_with_gke.html)\nif you haven't had a chance to play with it yet – you might be surprised what it's\ncapable of out of the box.\n\n![Auto DevOps](https://about.gitlab.com/images/11_0/auto-devops.png){: .shadow.medium.center}\n\n### Job logs in the Web IDE\n\nTying operational deployments/execution together with development is also a priority\nfor GitLab. In 11.0 we made the CI status of the current commit available in the status\nbar of the Web IDE, and made it possible to view the [status and the logs for each job on the right](https://docs.gitlab.com/ee/user/project/web_ide/#view-ci-job-logs).\nThis made it easy to fix a merge request with CI failures by opening the failed job\nright alongside your code.\n\n![Web IDE trace](https://about.gitlab.com/images/11_0/web_ide_ci_trace.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [CI/CD pipeline jobs integrated with the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#view-ci-job-logs)\n- [Variable-defined deployment policies for Canary deployments](https://docs.gitlab.com/ee/topics/autodevops/#deploy-policy-for-canary-environments)\n- [Specify deployment strategy from Auto DevOps settings](https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy)\n\n---\n\n## [GitLab 11.1](/releases/2018/07/22/gitlab-11-1-released/)\n\n### Security reports in pipeline view\n\nSecurity was another important area of focus for us throughout the 11.x series. We\nalready had security reports in the MR before this release, but here we also\nadded status for branches so this information can be acted upon even earlier.\nGitLab 11.1 (July 2018) completed the [set of security reports shown in the pipeline view](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports),\nadding both Container Scanning and DAST. From there you could now simply review\nthe Reports tab to access all security information and take action.\n\n![Security Reports](https://about.gitlab.com/images/11_1/security_reports.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Redesign of the merge request and pipeline info sections](https://docs.gitlab.com/ee/user/project/merge_requests/)\n- [Improved Kubernetes cluster page design](https://docs.gitlab.com/ee/user/project/clusters/)\n\n---\n\n## [GitLab 11.2](/releases/2018/08/22/gitlab-11-2-released/)\n\n### Custom templates at the instance level\n\nIn 11.2 (August 2018) we also introduced [custom templates at the instance level](https://docs.gitlab.com/ee/administration/custom_project_templates.html),\nmaking it easy for organizations to set up a basic template for how they want\ntheir CI/CD pipelines to run. Development teams can grab a copy of the template\nand go, confident their following their organizational processes. Our enterprise\ncustomers are very important to us, and this feature came directly from the great\nfeedback we get from our customers.\n\n![Project Templates](https://about.gitlab.com/images/11_2/project-templates-instance.png){: .shadow.medium.center}\n\n### Kaniko for Docker Builds\n\nHistorically, building Docker images within a containerized environment had\nrequired compromises, using techniques like docker-in-docker on privileged\ncontainers. These solutions were often insecure and slow. In this release we\nmade the Runner compatible with [Kaniko](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html),\na new tool developed by Google which is able to securely build an image within\nan unprivileged container. Cloud-first build technology is so important for the\njourney we want to take with our users, and supporting these kinds of foundational\ntechnologies that make your life easier are so nice to deliver.\n\n![Kaniko](https://about.gitlab.com/images/11_2/kaniko.png){: .shadow.medium.center}\n\n### JUnit test results in merge requests\n\nFinally, testing will always be an important part of any CI/CD pipeline. With the 11.2 release,\nwe made it possible to [see JUnit test results directly](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html)\nright from the CI view in the merge request widget, as part of our ongoing efforts\nto invest in full-spectrum integrated testing within GitLab.\n\n![JUnit Results](https://about.gitlab.com/images/feature_page/screenshots/junit-test-summaries-MR-widget.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [GitLab Runner in cloud native Helm Chart](https://docs.gitlab.com/charts/)\n- [Built-in project templates switched to use Dockerfiles](https://docs.gitlab.com/ee/user/project/working_with_projects.html#create-a-project)\n- [Manually stop an environment](https://docs.gitlab.com/ee/ci/environments/index.html#stopping-an-environment)\n\n---\n\n## [GitLab 11.3](/releases/2018/09/22/gitlab-11-3-released/)\n\n### Built-in Maven package repository\n\nFor any development organization, having an easy and secure way to manage\ndependencies is critical. Package management tools, such as Maven for Java\ndevelopers, provide a standardized way to share and version control these\nlibraries across projects. In GitLab 11.3 (September 2018), we opened up [Maven repositories built directly into GitLab](https://docs.gitlab.com/ee/user/packages/maven_repository/index.html).\nJava developers were now easily able to publish their packaged libraries to\ntheir project’s Maven repository: Just share a simple XML snippet with\nother teams looking to utilize that library, and Maven and GitLab will take care\nof the rest.\n\n![Maven Repo](https://about.gitlab.com/images/11_3/maven.png){: .shadow.medium.center}\n\n### Interactive Web Terminals\n\nCI/CD jobs are executed in the runner as part of pipelines, but this execution wasn't interactive.\nWhen they failed, it wasn't always easy to dig into details to spot the source of the problem.\n[Interactive web terminals](https://docs.gitlab.com/ee/ci/interactive_web_terminal/)\nbrought the capability to connect to a running or completed job and manually enter\ncommands to understand what’s happening in the system, and helped us move the story\nforward on empowering teams to deliver code, troubleshoot, and solve issues directly.\n\n![Web Terminal](https://about.gitlab.com/images/11_3/verify-webterm.png){: .shadow.medium.center}\n\n### Better includes with `extends` keyword\n\nReusing CI/CD code is a great way to help ensure consistency in software delivery,\nand also minimizes the amount of per-job scripting that’s needed to write and\nmaintain. As of 11.11, we began offering a powerful alternative approach\nfor code reuse in templates using [YAML `extends` keywords](https://docs.gitlab.com/ee/ci/yaml/#extends),\nexpanding upon our vision for reusability and compliance in the enterprise.\n\n![Extends](https://about.gitlab.com/images/11_3/verify-includes.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)\n- [Auto DevOps enabled by default](https://docs.gitlab.com/ee/topics/autodevops/)\n- [Custom file templates for self-managed instances](https://docs.gitlab.com/ee/administration/settings/instance_template_repository.html)\n\n---\n\n## [GitLab 11.4](/releases/2018/10/22/gitlab-11-4-released/)\n\n### Feature Flags\n\nFeature Flags are a no-brainer to make software deliver easier, so you knew we'd eventually\nwant to include them in the GitLab single application. With the 11.4 release (October 2018) we delivered on\nthis promise by adding [Feature Flags](https://docs.gitlab.com/ee/operations/feature_flags.html),\nhelping teams to achieve continuous delivery by offering better options for incrementally\nrolling out changes and separating feature delivery from customer launch.\n\n![Feature Flags](https://about.gitlab.com/images/11_4/feature_flags.png){: .shadow.medium.center}\n\n### `only/except` rules for changes to files\n\nA very popular requested feature, in 11.4 we added the ability within the\n`.gitlab-ci.yml` to [use `only`/`except` rules for jobs](https://docs.gitlab.com/ee/ci/yaml/#only--except)\nbased on when modifications occur to a specific file or path (or glob). This allowed\nfor even more smarts in the pipeline, especially for monorepo/microservice-type\nuse cases, where the pipeline behavior can be optimized based on the changed files\nin the repository.\n\n![Only Except Changes](https://about.gitlab.com/images/11_4/verify-onlyexceptchanges.png){: .shadow.medium.center}\n\n### Timed incremental rollouts\n\nTeams already had the ability within Auto DevOps to set up incremental rollouts,\nbut with this release we added an option to also set up [timed incremental rollouts](https://docs.gitlab.com/ee/topics/autodevops/#timed-incremental-rollout-to-production)\nwhere the rollout will automatically continue forward on a timed cadence, making\nsure there is no error before continuing. This helped us push our vision for safe,\ncontinous deployment forward by providing teams with a new tool to have control over\ntheir code rollouts.\n\n![Timed Incremental Rollouts](https://about.gitlab.com/images/11_4/timed_incremental_rollouts.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Moving `includes` from Starter to Core](https://docs.gitlab.com/ee/ci/yaml/#include)\n- [Auto DevOps support for RBAC](https://docs.gitlab.com/ee/topics/autodevops/)\n- [Filter admin runners view by type/state](https://docs.gitlab.com/ee/ci/runners/)\n- [Support for interactive web terminals with Docker executor](https://docs.gitlab.com/ee/ci/interactive_web_terminal/)\n- [Delayed jobs for pipelines](https://docs.gitlab.com/ee/ci/yaml/#whendelayed)\n\n---\n\n## [GitLab 11.5](/releases/2018/11/22/gitlab-11-5-released/)\n\n### Access control for Pages\n\nWith the 11.5 release (November 2018) we delivered a fantastic community-contributed feature which enabled\naccess control for Pages. From now on, instead of only supporting use cases where the\ncontent associated with the product is public, you could use Pages to build and\npublish protected content that should [only be accessible by project members](https://docs.gitlab.com/ee/user/project/pages/introduction.html#gitlab-pages-access-control).\nOperational documentation, internal secrets, or even just private planning or\nother information can now be confidently published via your pipelines in an\neasy-to-access way, with confidence that only the right people are able to see it.\n\n![Access Control Pages](https://about.gitlab.com/images/11_5/access-control-pages.png){: .shadow.medium.center}\n\n### Deploy Knative to your Kubernetes cluster\n\nBuilding [serverless applications](/topics/serverless/) enables teams to focus their time on making a\ngreat product and eliminates the need of provisioning, managing, and operating\nservers. Starting in GitLab 11.5, we enabled [deploying Knative to your existing Kubernetes cluster](https://docs.gitlab.com/ee/update/removals.html)\nwith a single click using the GitLab Kubernetes integration. Knative is a\nKubernetes-based platform to build, deploy, and manage modern serverless workloads.\nTasks that were once difficult, such as source-to-container builds, routing and\nmanaging traffic, and scaling-to-zero, now work effortlessly out of the box.\n\n![KNative](https://about.gitlab.com/images/11_5/knative.png){: .shadow.medium.center}\n\n### Parallel attribute for faster pipelines\n\nThe speed to delivery in a CI/CD environment can oftentimes be limited by the time it takes to complete the various tests in order to ensure the code is able to be shipped. With the `parallel` keyword in GitLab CI/CD, teams can quickly and easily parallelize these tests – accelerating the testing process and overall time to delivery.\n\n![Parallel](https://about.gitlab.com/images/11_5/parallel-keyword.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Review Apps can now link directly to changed pages](https://docs.gitlab.com/ee/ci/environments/index.html#going-from-source-files-to-public-pages)\n- [New CI/CD syntax for security, quality, and performance report types](https://docs.gitlab.com/ee/ci/yaml/#artifactsreports)\n- [Additional information about deployments in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#pipeline-status-in-merge-requests)\n\n---\n\n## [GitLab 11.6](/releases/2018/12/22/gitlab-11-6-released/)\n\n### GitLab Serverless\n\nBuilding on the Knative integration introduced in the previous month, 11.6's new, more\ncomprehensive [Serverless](https://docs.gitlab.com/ee/update/removals.html)\ncapability enabled users to easily define functions in their repository and have\nthem served and managed by Knative. Cloud native is such an important part of our\nroadmap, and it was really exciting to launch this feature while I was at KubeCon\nno less.\n\nBy simply defining your function data in the repo’s `serverless.yml` file and\nusing a `.gitlab-ci.yml` template, each function will be deployed to your cluster,\nwith Knative taking care of scaling your function based on request volume. This\nenables application developers to iterate quickly without having to worry about\nprovisioning or managing infrastructure.\n\n![Serverless](https://about.gitlab.com/images/11_6/serverless.png){: .shadow.medium.center}\n\n### Run pipeline jobs for merge requests\n\nRunning a given job only when dealing with a merge request was made much easier in 11.6. Using the\n`merge_requests` value with `only/except` keywords will allow you to configure jobs\nto run [only or except when in the context of a merge request](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html).\nThis allows finer control over pipeline behavior, and also provides access to new\nenvironment variables indicating the target branch and merge request ID to be used\nfor additional automated behaviors.\n\n![Merge Request Pipelines](https://about.gitlab.com/images/11_6/verify-mergerequestpipelines.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Kubernetes clusters for groups](https://docs.gitlab.com/ee/user/group/clusters/)\n- [Pipelines are now deletable via API](https://docs.gitlab.com/ee/api/pipelines.html#delete-a-pipeline)\n- [Trigger variables are now hidden in UI by default](https://docs.gitlab.com/ee/ci/triggers/)\n\n---\n\n## [GitLab 11.7](/releases/2019/01/22/gitlab-11-7-released/)\n\n### Releases page\n\nThe 11.7 release (January 2019) added the ability to [create releases in GitLab](https://docs.gitlab.com/ee/user/project/releases/index.html)\nand view them on a summary page. Releases are a snapshot in time of the source,\nlinks, and other metadata or artifacts associated with a released version of your\ncode, and helps users of your project to easily discover the latest releases\nof your software.\n\nThis is a feature that was, as a career release manager, near and dear to my heart.\nI have so many plans around [Release Orchestration](/direction/release/release_orchestration/)\nthat build on this feature as a foundation. Being able to tie a milestone to\na release, a feature coming very soon, will open the door to tying together all\nkinds of interesting things happening in GitLab to a release. This isn't my forward-looking\nblog post so I won't go too far here, but I'll just say I can't wait to\ngo on that journey to build something really unique and powerful together with our users.\n\n![Releases Page](https://about.gitlab.com/images/11_7/release-releases_page.png){: .shadow.medium.center}\n\n### Expand upstream/downstream pipelines across projects\n\nWith 11.7 it became possible to [expand upstream or downstream cross-project pipelines](https://docs.gitlab.com/ee/ci/pipelines/index.html#visualize-pipelines)\nright from the pipeline view, giving you visibility into your end-to-end pipelines,\nno matter in which project they start or finish. It's one pattern we've been seeing\nmore and more of in GitLab, and we're adding more features to support. The reality of\ncontinuous delivery is complex orchestration across projects and even groups, so\nthis is a feature that was nice to get out the door to help make this easier.\n\n![Cross-Project Pipelines](https://about.gitlab.com/images/11_7/release-pipeline_expansion.png){: .shadow.medium.center}\n\n### NPM package repository\n\nIn January we also started offering [NPM registries](https://docs.gitlab.com/ee/user/packages/npm_registry/index.html)\nbuilt directly into GitLab. From this point teams can share a simple package-naming\nconvention to utilize that library in any Node.js project, and NPM and GitLab will\ndo the rest – all from a single, easy-to-use interface. Yet another step on our path\nto enable all kinds of repositories, built right into GitLab when you need them.\n\n![NPM Packages](https://about.gitlab.com/images/11_7/npm_package_view.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Ability to configure Kubernetes app secrets as variables in Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#application-secret-variables)\n- [API support for Kubernetes integration](https://docs.gitlab.com/ee/api/project_clusters.html)\n- [Short commit SHA available as environment variable](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)\n- [Authorization support for fetching includes](https://docs.gitlab.com/ee/ci/yaml/#include)\n- [Skip CI builds during git push with `skip_ci` keyword](https://docs.gitlab.com/ee/ci/pipelines/#skip-a-pipeline)\n\n---\n\n## [GitLab 11.8](/releases/2019/02/22/gitlab-11-8-released/)\n\n### `trigger:` keyword for pipelines\n\nEven as of GitLab 9.3 you were able to create multi-project pipelines by triggering\na downstream pipeline via a GitLab API call in your job. In GitLab 11.8 (February 2019), we added\nfirst-class support for triggering these downstream pipelines with the [`trigger:`](https://docs.gitlab.com/ee/ci/yaml/#trigger)\nkeyword, instead of requiring teams to make an API call to trigger the downstream\npipeline. A bit more for those cross-project use cases that makes everything just\na little bit nicer to use.\n\n![Trigger](https://about.gitlab.com/images/11_8/multi_project_pipeline_graph.png){: .shadow.medium.center}\n\n### Pages support for subgroups\n\nPages was updated in 11.8 to [work with subgroups in GitLab](https://docs.gitlab.com/ee/administration/pages/),\ngiving you the ability to create Pages sites at that level as well. Sites set up in this\nway will have a URL in the format of `toplevel-group.gitlab.io/subgroup/project`,\nmaking them very easy to find.\n\n![Pages for SubGroups](https://about.gitlab.com/images/11_8/release-pages-subgroups.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Several new templates for getting started quickly with GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/#getting-started)\n- [Auto DevOps support for environment-specific custom domain](https://docs.gitlab.com/ee/topics/autodevops/#environment-variables)\n- [Feature Flags was improved by making them environment-aware](https://docs.gitlab.com/ee/operations/feature_flags.html#define-environment-specs)\n- [CI_PAGES and CI_PAGES_URL added as helpful variables accessible to Pages pipelines](https://docs.gitlab.com/ee/user/project/pages/)\n- [.html extensions are now automatically resolved for Pages sites](https://docs.gitlab.com/ee/user/project/pages/)\n- [Tolerations were added to the Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html#the-keywords)\n- [A new cleanup procedure for the Container Registry](https://docs.gitlab.com/ee/api/container_registry.html#delete-a-repository-tag)\n- [Force redeploy when Auto DevOps secrets are updated](https://docs.gitlab.com/ee/topics/autodevops/#environment-variables)\n\n---\n\n## [GitLab 11.9](/releases/2019/03/22/gitlab-11-9-released/)\n\n### Feature Flag auditability\n\nWith the 11.9 release (March 2019), operations like adding, removing, or changing Feature Flags\nare now [recorded in the GitLab audit log](https://docs.gitlab.com/ee/administration/audit_events.html),\ngiving you visibility into what is changing and when. If you’re having an incident\nand need to see what changed recently, or just need to look back as an auditor on\nhow your feature flags have been modified, this is now very easy to do. We have\nbig plans for Feature Flags, and also compliance built right into your pipelines.\nIt was great to knock out a two-for-one with this one.\n\n![Feature Flag audit events](https://about.gitlab.com/images/11_9/release-ffaudit.png){: .shadow.medium.center}\n\n### Security templates for pipelines\n\nGitLab security features evolve very fast, and they always need to be up to\ndate to be effective and protect your code. We know that changing the job\ndefinition is difficult if you have to manage multiple projects. As of this release we\ninclude bundled security templates [directly into your configuration](https://docs.gitlab.com/ee/user/application_security/sast/#configuring-sast),\nand have them updated with your system every time you upgrade to a new version of\nGitLab, without any change to any pipeline configuration required. Security plus\nreusability, a great combination.\n\n![Security Templates](https://about.gitlab.com/images/11_9/templates.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Project templates for .NET, Go, iOS, and Pages](https://docs.gitlab.com/ee/user/project/working_with_projects.html#built-in-templates)\n- [Run specific jobs on merge requests only when files change](https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-onlychanges-with-merge-request-pipelines)\n- [Auto DevOps build jobs for tags](https://docs.gitlab.com/ee/topics/autodevops/#auto-build)\n\n---\n\n## [GitLab 11.10](/releases/2019/04/22/gitlab-11-10-released/)\n\n### Pipeline dashboard\n\nIn 11.10 (April 2019) we added [pipeline status information to the Operations Dashboard](https://docs.gitlab.com/ee/user/operations_dashboard/).\nThis helps teams view the pipeline health of all the projects that they care about,\nall together in a single interface. Yet another step towards making pipelines across\nyour instance easy to understand and follow, this one was built in real-time coordination\nwith a customer, which is always a nice way to get something done. You get to build\nsomething that solves a real problem and collaborate directly with the folks who\nneed it.\n\n![Pipeline Dashboard](https://about.gitlab.com/images/11_10/cross-project-pipelines-dashboard.gif){: .shadow.medium.center}\n\n### Pipelines on merge results\n\nWhen working in a feature branch, it’s normal to have it diverge over\ntime from the target branch if you aren’t rebasing frequently. This can result\nin a situation where both the source and target branch’s pipelines are green and\nthere are no merge conflicts, but the combined output will result in a failed\npipeline due to an incompatibility between the changes.\n\nWith 11.10 it became possible for a pipeline to automatically create a new ref that\ncontains the combined merge result of the source and target branch, then\n[run the pipeline against that ref](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html)\n(what we call an `attached` state). In this way, GitLab can help teams keep their\nmaster branch green even when they have many teams merging into the release branch.\n\nTools and techniques built right into GitLab for keeping master green was a big\nfocus in the last few releases of 11.x, and will remain so for 12.x as well. Look\nfor [merge trains](https://gitlab.com/gitlab-org/gitlab-ee/issues/9186) to be built\non top of this foundation, and some really cool enhancements around sequencing and\nparallelization of them.\n\n![Merge Ref Pipeline](https://about.gitlab.com/images/11_10/merge_request_pipeline.png){: .shadow.medium.center}\n\n### Composable Auto DevOps\n\nAuto DevOps enables teams to adopt modern DevOps practices with little to no effort.\nStarting in GitLab 11.10 each job of Auto DevOps was made available as an\nindependent template. Using the includes feature of GitLab CI, users can [choose to bring in\nonly certain stages of Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#using-components-of-auto-devops) while continuing to use their own custom\n`gitlab-ci.yml` for the rest. This helps teams to use just the desired jobs, while\ntaking advantage of any updates made upstream.\n\n![Composable Auto DevOps](https://about.gitlab.com/images/11_10/composable-auto-devops.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [More thorough Container Registry cleanup](https://docs.gitlab.com/omnibus/maintenance/#removing-unused-layers-not-referenced-by-manifests)\n- [Ability to purchase CI add-on runner minutes](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#extra-shared-runners-pipeline-minutes-quota)\n- [Change the cloning path for pipelines](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#custom-build-directories)\n- [Simple masking of protected variables in logs](https://docs.gitlab.com/ee/ci/variables/#masked-variables)\n- [Enable/disable Auto DevOps at the group level](https://docs.gitlab.com/ee/topics/autodevops/#enablingdisabling-auto-devops-at-the-group-level)\n- [Group-level runners for group-level clusters](https://docs.gitlab.com/ee/user/group/clusters/#installing-applications)\n- [Control over `git clean` flags in pipeline jobs](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#git-clean-flags)\n\n---\n\n## [GitLab 11.11](/releases/2019/05/22/gitlab-11-11-released/)\n\n### Windows Container Executor\n\nIn GitLab 11.11 (May 2019) we were very pleased to add a new executor to the GitLab Runner\nfor using [Docker containers on Windows](https://docs.gitlab.com/runner/executors/docker.html#using-windows-containers).\nPreviously, using the shell executor to orchestrate Docker commands was the primary\napproach for Windows, but with this update you are now able to use Docker\ncontainers on Windows directly, in much the same way as if they were on Linux\nhosts. This opened up the door for more advanced kinds of pipeline orchestration\nand management for our users of Microsoft platforms.\n\nAlso included with this update was improved support for PowerShell throughout GitLab\nCI/CD, as well as new helper images for various versions of Windows containers.\n\n![Windows Executor](https://about.gitlab.com/images/11_11/windows-container.png){: .shadow.medium.center}\n\n### Caching proxy for Container Registry\n\nLots of teams are using containers as part of their build pipelines, and our new\n[caching proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/index.html) for\nfrequently used upstream images/packages introduced a great way to speed them up.\nBy keeping a copy of needed layers locally using the new caching proxy, you can\neasily improve execution performance for the commonly used images in your environment.\n\n![Dependency Proxy](https://about.gitlab.com/images/11_11/dependency-proxy-mvc.png){: .shadow.medium.center}\n\n### Chat notifications for deployments\n\nIn 11.11 deployment events were available to be [automatically shared in your team’s channel](https://docs.gitlab.com/ee/user/project/integrations/)\nthrough our Slack and Mattermost chat integrations, helping bring visibility to\nthese important activities that your teams need to be aware of.\n\n![Notifications](https://about.gitlab.com/images/11_11/release-slack-notification.png){: .shadow.medium.center}\n\n### Guest Access for Releases\n\nIt also became possible in this release for [guest users of your projects to view releases](https://docs.gitlab.com/ee/user/permissions.html#releases-permissions)\nthat you have published on the Releases page. They will be able to download your\npublished artifacts, but are prevented from downloading the source code or seeing\nrepository information such as tags and commits.\n\n![Guest Releases](https://about.gitlab.com/images/11_7/release-releases_page.png){: .shadow.medium.center}\n\n### Other highlights\n\n- [Add-on runner minutes extended to free plans](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#extra-shared-runners-pipeline-minutes-quota)\n- [Access deployment details through environments API](https://docs.gitlab.com/ee/api/environments.html#get-a-specific-environment)\n- [Create a file directly from environment variable](https://docs.gitlab.com/ee/ci/variables/#variable-types)\n- [Run all manual jobs for a stage in one click](https://docs.gitlab.com/ee/ci/pipelines/index.html#add-manual-interaction-to-your-pipeline)\n\n---\n\n## In conclusion\n\nPhew... that was a lot of great features, and the team here at GitLab is really proud of\nwhat we delivered with this series of GitLab releases. I hope you found something\nthat you can take advantage of in your own CI/CD process. If you're interested in\nseeing where we're heading next, head over to our [CI/CD strategy page](/direction/ops/)\nand check out what's coming. Also, be sure to check out our 12.0 release post coming out on the 22nd of this month.\n\nOne of the things you may have noticed is that we frequently add new iterations\non our features, even month to month. We have a lot more iterations planned, both\nfor new and existing features, but what would you like to see in the next\nversion of your favorite feature? We'd love to hear – let us know in the\ncomments below.\n\nPhoto by [Zoltan Tasi](https://unsplash.com/photos/O_mBXldZ0hc?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/arrow?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[851,108,9],{"slug":4499,"featured":6,"template":683},"look-back-on-11-11-cicd","content:en-us:blog:look-back-on-11-11-cicd.yml","Look Back On 11 11 Cicd","en-us/blog/look-back-on-11-11-cicd.yml","en-us/blog/look-back-on-11-11-cicd",{"_path":4505,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4506,"content":4512,"config":4518,"_id":4520,"_type":13,"title":4521,"_source":15,"_file":4522,"_stem":4523,"_extension":18},"/en-us/blog/major-league-gitlab-hacking",{"title":4507,"description":4508,"ogTitle":4507,"ogDescription":4508,"noIndex":6,"ogImage":4509,"ogUrl":4510,"ogSiteName":670,"ogType":671,"canonicalUrls":4510,"schema":4511},"Major League Hacking: Students contribute to feature updates","Our latest program participants explain their projects, their results, and the lessons they learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663736/Blog/Hero%20Images/a-deep-dive-into-the-security-analyst-persona.jpg","https://about.gitlab.com/blog/major-league-gitlab-hacking","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Major League Hacking: Student fellows contribute to platform feature updates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-05-30\",\n      }",{"title":4513,"description":4508,"authors":4514,"heroImage":4509,"date":4515,"body":4516,"category":827,"tags":4517},"Major League Hacking: Student fellows contribute to platform feature updates",[3504],"2023-05-30","\n\nContributing to [open source](https://go.gitlab.com/spHNym) projects [like GitLab](https://gitlab.com/gitlab-org) can be a powerful way to learn software development. Just ask [Mughees Pervaiz](https://gitlab.com/Mughees_), who is studying computer science at the University of South Asia, and [Young Jun Joo](https://gitlab.com/youngjun827), who is studying mathematics and economics at the University of Waterloo in Canada. They recently contributed to GitLab as part of a fellowship with [Major League Hacking](https://mlh.io/about), a Certified B corporation working to empower tomorrow's technology leaders. The fellows' [12-week program recently concluded](https://fellowship.mlh.io/), but before it was over, we gave them one final assignment: Explain your favorite contribution to GitLab during your fellowship.\n\nHere's what they had to say.\n\n## Mughees Pervaiz\nDuring my internship, I was a part of the GitLab Foundation team under the mentorship of our maintainer, [James Rushford](https://gitlab.com/jrushford). My primary responsibility was to improve both the developer and user experience on GitLab. \n\nMy favorite contribution was helping to update expand/collapse buttons in roadmaps [from link buttons to tertiary buttons](https://gitlab.com/gitlab-org/gitlab/-/issues/396775). Before the changes, the feature was using old components, and I updated it to new GitLab UI components. We had to [migrate the expand/collapse buttons](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117242) that appear in the roadmap tree drawer. So we were working with the tree view (or, you could say, the 'child components' of the roadmap) and, because of this, it was very difficult for me to find the right file from GitLab's very large codebase.\n\nMaking this contribution taught me a lot about working with the GitLab codebase — specifically about making changes to the front-end user interface. I had to work with different GitLab components, such as the epic item details (vue component), epic item details (js component), and the front-end JavaScript libraries such as [Jest](https://jestjs.io/), in order to test or implement this feature.\n\nThis contribution also helped me develop my collaboration and communication skills. I had to work closely with other members of the GitLab community, including designers, product managers, and other contributors, in order to refine the feature and ensure that it aligned with GitLab's design principles and user experience goals.\n\nI also learned not to jump into coding without understanding an issue completely. Here, James helped me quite a bit: When I asked for his guidance, he responded with the following questions:\n\n- What is your understanding of the problem?\n- What did you try so far?\n- What did you find so far?\n- What are your next ideas?\n- Where did you look for information?\n\nAt first, I was confused. *Why is he asking me these questions instead of helping me?* But following James' technique really helped me with the issue, and I solved the problem by myself. At that moment, one of the most important lessons was clear to me: Don't underestimate myself. James wanted me to go beyond my limits, get out of the box, and try to solve the issue by myself so I could have a better understanding of what was happening in the codebase. So to anyone wishing to contribute to GitLab, I would say: Believe in yourself and give your best, and make sure you read the issue closely to develop a good understanding of the problem you're trying to solve.\n\n## Young Jun Joo\nDuring my Major League Hacking fellowship with GitLab, I worked on [improving the GitLab search function](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111741). Some GitLab users were experiencing a slow search experience — and as a user myself, I understood the importance of having a quick and efficient search function. I wanted to help make that a reality for other users.\n\nSo I [implemented a memoization algorithm](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112606) that caches search results. Now, if a user searches for the same word multiple times, the search results will be retrieved from the cache instead of being recalculated each time. This results in a faster and more efficient search experience for GitLab users.\n\nMy contribution to GitLab was significant because it improved the search function's performance and efficiency, making it more reliable and user-friendly. Working on this project taught me a lot about optimization and efficiency in software development. I also gained a deeper understanding of how memoization algorithms work and how they can be used to improve performance.\n\nMy work on this project not only was extremely rewarding but also had a positive impact on GitLab and its users, who can now quickly and easily search for the information they need without experiencing lag or delays. I'm proud to have made a meaningful contribution to such a valuable tool for software development, and grateful for the opportunity to have worked with such a talented team of developers.\n\n## Your turn\nWant to improve your open source development skill by contributing to GitLab? You can start right now by reviewing the project's [list of outstanding issues](https://gitlab.com/groups/gitlab-org/-/issues/?sort=created_date&state=opened&label_name%5B%5D=quick%20win&first_page_size=100) (hint: start with issues labeled `quick win`). And be sure to connect with our [community on Discord](https://discord.gg/gitlab). We'd love to meet you.\n",[1187,266,9],{"slug":4519,"featured":6,"template":683},"major-league-gitlab-hacking","content:en-us:blog:major-league-gitlab-hacking.yml","Major League Gitlab Hacking","en-us/blog/major-league-gitlab-hacking.yml","en-us/blog/major-league-gitlab-hacking",{"_path":4525,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4526,"content":4532,"config":4537,"_id":4539,"_type":13,"title":4540,"_source":15,"_file":4541,"_stem":4542,"_extension":18},"/en-us/blog/making-builds-faster-autoscaling-runners",{"title":4527,"description":4528,"ogTitle":4527,"ogDescription":4528,"noIndex":6,"ogImage":4529,"ogUrl":4530,"ogSiteName":670,"ogType":671,"canonicalUrls":4530,"schema":4531},"How to make builds faster","How GitLab uses autoscaling to reduce build times and make developers happy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673173/Blog/Hero%20Images/autoscaling-balance.jpg","https://about.gitlab.com/blog/making-builds-faster-autoscaling-runners","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to make builds faster\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2019-08-21\",\n      }",{"title":4527,"description":4528,"authors":4533,"heroImage":4529,"date":4534,"body":4535,"category":1249,"tags":4536},[2390],"2019-08-21","\nPicture this: It’s 5:30 pm on a Friday and a project manager has an urgent request. A\nbug is affecting a group of customers and it needs to be fixed ASAP. You find the discrepancy\nand, _phew_, it looks like it’s going to be a relatively easy fix. You make the update and\nstart the CI pipeline… and then you wait… and wait. Two hours later, you’re still waiting. What was\nsupposed to be a quick fix has turned into another long night sitting in a queue.\n\n[The team at Ticketmaster](/blog/continuous-integration-ticketmaster/) certainly felt the\npain with their Jenkins pipelines, and many [DevOps](/topics/devops/) teams are all too familiar with sluggish CI.\n\nSlow builds hinder development speed. Plus – they’re annoying. It’s just one more thing developers\nhave to deal with in order to do their jobs. Organizations might dedicate more servers to process\nthese builds in an effort to solve the problem, but often that creates more problems. More servers\nmean higher cloud and computing costs. When it comes to long builds, many developers have\nresigned themselves to just “grin and bear it.”\n\n## Making builds _faster_\n\n[Continuous integration](/solutions/continuous-integration/) allows you to run a number of tasks as you\nprepare to deploy your software, like building a software package or running tests. These tasks\nneed to be run by something. At GitLab we call these task enablers runners, though other [CI tools](/solutions/continuous-integration/) call them\nagents. Runners are an application that processes builds: If all of these runners are in use, work\nis queued until one becomes available. Let's say your peak usage is 100 jobs, but your average\nusage is around 25 jobs. You have to decide how many servers to provision. If you go with the\naverage, you will have to wait during peak usage times. So why not just add more runners? Some\nservices actually charge for each of these virtual machines, and if you’re not using them all\nthe time, those costs can add up. If you're on a cloud infrastructure, you're paying for that\nserver time – even when it's not doing anything.\n\nFor ops teams, it’s been a never-ending balancing act of having the right amount of runners\nfor the right amount of work. But tasks don’t happen in a vacuum – every team has slow times\nand busier times that are unpredictable.\n\nNobody likes waiting. With this universal truth in mind, we introduced autoscaling to GitLab Runners.\n\n## What are autoscaling runners?\n\nAutoscaling gives teams the ability to utilize resources in a more elastic and dynamic way. What\nthis means is that our runners can be configured so that machines are created _on demand_.\nThose machines, after the job is finished, can wait to run the next jobs or be removed automatically.\nYou can even specify the `IdleTime` of a server before it shuts off. Once runners are set up to\nautoscale, your infrastructure contains only enough capacity to handle the load.\n\nAutoscaling runners ensure builds can be processed more efficiently and you aren’t paying for\nmore machines than you need. Developers can focus on their code instead of worrying about\ntheir infrastructure environment, and ops teams no longer have to moonlight as soothsayers.\n\nThe only thing you need to take advantage of autoscaling is one GitLab instance and\none [GitLab Runner](https://docs.gitlab.com/runner#features) that can be installed for free.\nOur runner is written in Go and can run on any platform where you can build Go binaries\nincluding Linux, macOS, Windows, FreeBSD, and Docker.\n\nSee how the team at [Substrakt Health](https://substrakthealth.com/) set up an autoscaling\ncluster of GitLab CI/CD runners using Docker-Machine and AWS – and saved 90% on EC2 costs in the process.\n\n[Read their story.](/blog/autoscale-ci-runners/)\n{: .alert .alert-gitlab-purple .text-center}\n\nSpeed and efficiency are important cornerstones of effective DevOps, so waiting for builds has\nalways felt like a step backward. As everyone strives to deploy more software, it seems only right\nthat your architecture be up for the task. Autoscaling runners let DevOps teams focus on what\nthey do best: Deploying better, faster software (yes, even on a Friday).\n\nPhoto by [Austin Neill](https://unsplash.com/@arstyy?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[108,9,851],{"slug":4538,"featured":6,"template":683},"making-builds-faster-autoscaling-runners","content:en-us:blog:making-builds-faster-autoscaling-runners.yml","Making Builds Faster Autoscaling Runners","en-us/blog/making-builds-faster-autoscaling-runners.yml","en-us/blog/making-builds-faster-autoscaling-runners",{"_path":4544,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4545,"content":4551,"config":4556,"_id":4558,"_type":13,"title":4559,"_source":15,"_file":4560,"_stem":4561,"_extension":18},"/en-us/blog/manage-it-alerts-with-gitlab",{"title":4546,"description":4547,"ogTitle":4546,"ogDescription":4547,"noIndex":6,"ogImage":4548,"ogUrl":4549,"ogSiteName":670,"ogType":671,"canonicalUrls":4549,"schema":4550},"How we manage IT Alerts in GitLab","Triaging alerts just got easier with GitLab because you can investigate and remediate outages in a single tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681461/Blog/Hero%20Images/manage-it-alerts-in-gitlab.png","https://about.gitlab.com/blog/manage-it-alerts-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we manage IT Alerts in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Waldner\"}],\n        \"datePublished\": \"2020-08-03\",\n      }",{"title":4546,"description":4547,"authors":4552,"heroImage":4548,"date":4553,"body":4554,"category":678,"tags":4555},[2294],"2020-08-03","\n\nIt’s 2 a.m. Monday morning.\n\nYour phone screen lights up and buzzes. Lo and behold, the alert is serious and there is likely a severe incident ongoing with your service.\n\nYou check Slack to see if anyone else is involved. Next, you log into your monitoring tool to review the alert and do a quick triage hoping that the cause and solution are straightforward. The next 30 minutes are spent frantically bouncing around between five to six different tools, digging for clues in metrics, events, traces, logs, and release tools, hoping you can correlate a recent deployment to the incident. After another team member finally joins the firefight, you spend precious time getting them up to speed. After that, your boss calls. At this time, an hour has passed, you are no closer to the root cause.\n\nDoes this situation sound familiar?\n\nThere are so many jobs to be done during an incident: Communicating using multiple channels, facilitating collaboration, documenting findings and the timeline, and assessing metrics, logs, traces, and errors to diagnose problems. This process can be manual, time-consuming, and stressful for incident responders.\n\nWouldn’t it be great if most of this is automated and centralized in one place?\n\nEnter, GitLab alert and incident management\n\nOur vision is to free up more time for incident responders to actually respond to incidents by automating resource management, communications, correlating observability data and metadata, and executing runbooks. Since GitLab is a single app for your entire [DevOps](/topics/devops/) lifecycle, the bonus of using GitLab to triage IT alerts and manage incidents is that you are doing so in the same tool you are already using - everything is colocated to help you remediate problems faster.\n\n## What can I do today?\n\nWe are in the midst of building an Operations Command Center where you can investigate, respond to, and remediate IT incidents all in one interface.\n\nAvailable today, GitLab includes the following highlighted functionality:\n\n- Aggregate IT alerts in a single interface (GitLab) via our [generic webhook receiver](https://docs.gitlab.com/ee/operations/incident_management/integrations.html)\n- Triage multiple alerts in a [list view](https://docs.gitlab.com/ee/operations/incident_management/alerts.html)\n- Indicate ownership of critical alerts by [changing the status](https://docs.gitlab.com/ee/operations/incident_management/alerts.html)\n- Delegate responsibility by [assigning alerts](https://docs.gitlab.com/ee/operations/incident_management/alerts.html#assign-an-alert)\n- Promote alerts to incidents by [creating GitLab issues](https://docs.gitlab.com/ee/operations/incident_management/alerts.html#create-an-incident-from-an-alert)\n- [Investigate the metrics](https://docs.gitlab.com/ee/operations/incident_management/alerts.html#metrics-tab) directly in the alert\n\n## What is coming soon?\n\nAlert and incident management tools are the main focus of the [Health group](/handbook/engineering/development/ops/monitor/respond/) within the [Monitor stage](/direction/monitor/). In the next few milestones, we anticipate releasing:\n\n- Embedded [logs](https://gitlab.com/gitlab-org/gitlab/-/issues/231395) for GitLab Alerts\n- Linked [runbooks in alerts](https://gitlab.com/groups/gitlab-org/-/epics/1436)\n- A custom [integration builder](https://gitlab.com/gitlab-org/gitlab/-/issues/217766) to integrate any alerting source with GitLab\n- An [incident dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/219542) to manage active outages\n\n## We want to hear from you!\nAs per usual, we, at GitLab, listen closely to our community and we like to give you direct access to the ideas we are considering for our product. If you want to contribute to building [Incident Management](https://gitlab.com/groups/gitlab-org/-/epics/349) tools, please check out the linked epic to see what we have in the near-term. We love your feedback and we would love to receive your merge requests even more.\n\n## Read more about our monitoring tools:\n\n- [Why we scoped down to build up error tracking](/blog/iteration-on-error-tracking/)\n- [How application performance metrics helps developers](/blog/working-with-performance-metrics/)\n- [Understand incident management with GitLab](/blog/incident-management-with-gitlab/)\n",[851,9],{"slug":4557,"featured":6,"template":683},"manage-it-alerts-with-gitlab","content:en-us:blog:manage-it-alerts-with-gitlab.yml","Manage It Alerts With Gitlab","en-us/blog/manage-it-alerts-with-gitlab.yml","en-us/blog/manage-it-alerts-with-gitlab",{"_path":4563,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4564,"content":4570,"config":4575,"_id":4577,"_type":13,"title":4578,"_source":15,"_file":4579,"_stem":4580,"_extension":18},"/en-us/blog/mastering-gitlab-admin-tasks-with-gitlab-duo-chat",{"title":4565,"description":4566,"ogTitle":4565,"ogDescription":4566,"noIndex":6,"ogImage":4567,"ogUrl":4568,"ogSiteName":670,"ogType":671,"canonicalUrls":4568,"schema":4569},"Mastering GitLab admin tasks with GitLab Duo Chat","Learn how to use Chat to streamline administrative tasks on self-managed instances, improving efficiency and problem-solving capabilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666405/Blog/Hero%20Images/GitLab_Duo_Blog_Hero_1800x945_r2_B__1_.png","https://about.gitlab.com/blog/mastering-gitlab-admin-tasks-with-gitlab-duo-chat","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Mastering GitLab admin tasks with GitLab Duo Chat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-08-09\",\n      }",{"title":4565,"description":4566,"authors":4571,"heroImage":4567,"date":4572,"body":4573,"category":806,"tags":4574},[1994],"2024-08-09","As a GitLab administrator managing a self-hosted instance, you often face complex challenges that require innovative solutions. Enter [GitLab Duo Chat](https://about.gitlab.com/gitlab-duo/) – your AI-powered assistant that can significantly streamline your administrative tasks. In this article, we'll explore how you can leverage GitLab Duo Chat to solve intricate problems efficiently, using a real-world example of updating group memberships across multiple groups.\n\n## The power of GitLab Duo Chat for admins\n\nGitLab Duo Chat is more than just conversational AI; it's a powerful tool that can assist with complex administrative tasks. By providing context-aware suggestions and code snippets, Chat can help you navigate through GitLab's extensive feature set and underlying architecture.\n\n### Case study: Updating group memberships\n\nLet's dive into a scenario where an admin needs to add an administrator user to multiple [groups](https://docs.gitlab.com/ee/user/group/) – in this case, 50,000 groups. This task, while conceptually simple, can be daunting due to its scale.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/dBd957MK_DE?si=JYTzdRjVQHyB6rpl\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Step-by-step problem-solving with GitLab Duo Chat\n\n* **Initial approach:** Our first instinct might be to use GitLab's API, but with 50,000 groups, this could put significant strain on the system.\n* **Pivoting to the Rails console:** Instead, we can use the Rails console for a more efficient solution. Here's where Chat comes in handy.\n* **Crafting the solution:** Let's walk through the process of creating a Ruby script to accomplish our task:\n\n``` python\n\ndef add_admin_to_groups(parent_group, admin_user)\n     unless parent_group.members.exists?(user_id: admin_user.id)\n       parent_group.add_owner(admin_user)\n       puts \"Added #{admin_user.name} to #{parent_group.name}\"\n     end\n\n    parent_group.descendants.each do |subgroup|\n      add_admin_to_groups(subgroup, admin_user)\n    end\n  end\n\n# Usage\n\nadmin_user = User.find_by(username: 'mr_admin')\nparent_group = Group.find_by(path: 'top_group')\nadd_admin_to_groups(parent_group, admin_user)\n```\n\n* **Iterative refinement:** Through conversation with Chat, we refined this script, addressing issues like method availability and parameter requirements.\n\n### Key takeaways\n\n#### Non-deterministic responses\n\nGitLab Duo Chat may provide different answers to the same question, encouraging exploration of multiple solutions. As an example:\n\nAn admin asks, ***How can I improve CI/CD pipeline performance?***\n\nChat's first response could be:\n***Consider using GitLab CI/CD caching to speed up subsequent pipeline runs. Here's an example .gitlab-ci.yml snippet:***\n\n```\ncache:\n  key: ${CI_COMMIT_REF_SLUG}\n  paths:\n    - node_modules/    \n ```\n\n***This caches the `node_modules` directory, reducing build times for Node.js projects.***\n\nWhen asked again, Chat's second response could be: ***To improve CI/CD performance, try parallelizing your jobs. Here's an example:***\n\n```\ntest:\n  parallel: 3\n```\n\n***This runs your test job across three parallel runners, potentially reducing overall pipeline duration.***\n\n### Error interpretation and debugging\n\nChat can help interpret error messages and suggest fixes. As an example, an admin encounters an error: \"fatal: reference is not a tree: 8a7d460\". They could ask Chat: ***I'm seeing this Git error. What does it mean and how can I fix it?***\n\nChat could respond with:\n\n***This error typically occurs when Git can't find a specific commit. It could be due to a corrupted repository or incomplete fetch. Try these steps:***\n* ***Run `git fsck` to check for corruption.***\n* ***If that doesn't work, try git fetch --all --prune to update all remotes.***\n* ***If the issue persists, you might need to re-clone the repository.***\n\n***Always back up your repository before attempting these fixes.***\n\n### Code optimization and refactoring\n\nChat can assist in optimizing and refactoring code for better performance.\n\nAn example: An admin wants to optimize a Gitaly configuration for a large instance. They could ask Chat: ***How can I optimize Gitaly for an instance with 10,000+ repositories?***\n\nChat could respond with: ***For a large instance, consider this optimized Gitaly configuration:***\n\n```\n[concurrency]\nrpc_concurrency = 100\n\n[rate_limiting]\nrpc_rate_limit = 100\n\n[cgroups]\nmountpoint = '/sys/fs/cgroup'\nhierarchy_root = 'gitaly'\nmemory_bytes = 30000000000  # Adjust based on available memory\ncpu_shares = 1024\n```\n***This configuration increases concurrency, implements rate limiting to prevent overload, and uses cgroups (control groups) to manage resource allocation. Adjust values based on your specific hardware and needs.***\n\n## Best practices for using GitLab Duo Chat in admin tasks\n\n### Formulate queries clearly and provide context\n\nWhen using Chat, the quality of the response largely depends on the quality of your query. Clear, detailed questions that provide relevant context will yield more accurate and helpful answers.\n\nPoor query: ***Why is GitLab slow?***\n\nThis query lacks specifics and context, making it difficult for Chat to provide a targeted response. \n\nA better query would be: ***Our GitLab instance with 5,000 users and 3,000 projects is experiencing slow response times, especially during peak hours (9-11 AM EST). CPU usage on the application servers spikes to 90%. How can we diagnose and address this?***\n\nThis improved query provides crucial details:\n\n* scale of the instance (5,000 users, 3,000 projects)\n* nature of the problem (slow response times)\n* timing of the issue (peak hours, 9-11 AM EST)\n* observed symptoms (90% CPU spike)\n\nWith this information, Chat can provide more targeted advice.\n\nAn even better query would be: ***We're running GitLab 15.8.3 on a 3-node cluster (8 vCPUs, 32GB RAM each) with a separate PostgreSQL 13 database and Redis 6.2 instance. Our instance hosts 5,000 users and 3,000 projects. We're experiencing slow response times (average 5s, up from our usual 1s) during peak hours (9-11 AM EST), primarily affecting merge request creation and pipeline initiation. CPU usage on the application servers spikes to 90%, while database CPU remains under 60%. Gitaly CPU usage is around 70%. We've already increased Puma workers to 8 per node. What additional diagnostics should we run and what potential solutions should we consider?***\n\nThis query provides an extensive context, including:\n* GitLab version and infrastructure details\nspecific performance metrics (response time increase)\n* affected operations (merge requests, pipelines)\n* resource usage across different components\n* steps already taken to address the issue\n\nBy providing this level of detail, you enable Chat to:\n* understand the full scope of your environment\n* identify potential bottlenecks more accurately\n* suggest relevant diagnostic steps\n* propose solutions tailored to your specific setup\n\nAvoid recommending steps you've already taken.\n\nRemember, while GitLab Duo Chat is powerful, it's not omniscient. The more relevant information you provide, the better it can assist you. By following these guidelines, you'll get the most out of your interactions with Chat, leading to more effective problem-solving and administration of your GitLab instance.\n\n### Use GitLab Duo Chat's suggestions as a starting point and refine incrementally\n\nChat is an excellent tool for getting started with complex tasks, but it's most effective when used as part of an iterative process. Begin with a broad question, then use Chat's responses to guide your follow-up questions, gradually refining your understanding and solution.\n\n#### Initial query\n\nAdmin: ***How can I set up Geo replication for disaster recovery?***\n\nChat might respond with a basic setup guide, covering:\n- prerequisites for Geo setup\n- steps to configure the primary node\n- process for adding a secondary node\n- initial replication process\n\nThis provides a foundation, but complex setups like Geo often require more nuanced understanding. Here's how you might refine your queries:\n\n**- Follow-up Query 1**\n\nAdmin: ***How do I handle custom data in Geo replication?***\nThis question addresses a specific concern not covered in the initial setup. \n\n**- Follow-up Query 2**\n\nAdmin: ***What's the best way to test failover without disrupting production?***\n\nThis query focuses on a critical operational concern. \n\n**- Follow-up Query 3**\n\nAdmin: ***Can you help me create a runbook for Geo failover?***\n\nThis final query aims to consolidate the gathered information into a practical guide. The benefits of this incremental approach:\n\n1. By breaking down the complex topic of Geo replication into smaller, focused queries, you gain a more thorough understanding of the subject.\n2. Each follow-up question allows you to address specific concerns relevant to your environment, resulting in a more customized solution.\n3. The progression from setup to testing to creating a runbook ensures that you're not just understanding the theory, but also preparing for real-world implementation.\n4. The step-by-step process of refining your queries helps in better retention of the information, as you're actively engaging with the content.\n5. Follow-up questions often reveal aspects of the task you might not have initially considered, leading to a more robust final solution.\n\n#### Best practices for incremental refinement\n\n- Start with broad questions to establish a foundation.\n- Use Chat's responses to identify areas that need more clarification or detail.\n- Ask about specific scenarios or edge cases relevant to your environment.\n- Seek practical advice on implementation, testing, and maintenance.\n- Use your growing understanding to formulate increasingly specific and complex queries.\n- Periodically summarize your understanding and ask Chat to validate or correct it.\n\nRemember, while GitLab Duo Chat is a powerful tool, it's most effective when combined with your own critical thinking and domain knowledge. Use it to guide your learning and decision-making process, but always validate important information and test solutions in a safe environment before applying them to production systems.\n\n### Potential applications for self-managed GitLab instances\n\n#### User management at scale\n\nAdmin: ***We need to onboard 1,000 new users from an acquired company. The data is in a CSV file. How can we automate this process? I am an Admin, can I use a Python script for this?***\n\nChat: ***You can use GitLab's API for bulk user creation. Here's a Python script to get you started:***\n\n```python\nimport requests\nimport csv\n\ndef create_user(username, email, name, password):\n    url = 'https://gitlab.example.com/api/v4/users'\n    headers = {'PRIVATE-TOKEN': 'your_access_token'}\n    data = {\n        'username': username,\n        'email': email,\n        'name': name,\n        'password': password,\n        'skip_confirmation': True\n    }\n    response = requests.post(url, headers=headers, data=data)\n    return response.status_code == 201\n\nwith open('new_users.csv', 'r') as f:\n    reader = csv.reader(f)\n    for row in reader:\n        username, email, name, password = row\n        if create_user(username, email, name, password):\n            print(f\"Created user: {username}\")\n        else:\n            print(f\"Failed to create user: {username}\")\n```\n***This script reads user data from a CSV file and creates users via the GitLab API. Remember to handle errors and rate limiting for large batches.***\n\n#### Project and group administration\n\nAdmin: ***We need to implement a standardized project structure across our organization. How can we automate this? Assume I am an admin. Write me a script to do this via the API.***\n\nChat: ***You can use GitLab's API to create a project template and then apply it to new projects. Here's a bash script to create a new project with a standard structure:***\n\n```\n#!/bin/bash\n\nTOKEN=\"your_access_token\"\nGROUP_ID=\"your_group_id\"\n\ncreate_project() {\n  curl --header \"PRIVATE-TOKEN: $TOKEN\" \\\n  --data \"name=$1&namespace_id=$GROUP_ID\" \\\n  \"https://gitlab.example.com/api/v4/projects\"\n}\n\nadd_file() {\n  curl --request POST --header \"PRIVATE-TOKEN: $TOKEN\" \\\n  --form \"branch=main\" \\\n  --form \"content=$2\" \\\n  --form \"commit_message=Add $1\" \\\n  \"https://gitlab.example.com/api/v4/projects/$3/repository/files/$1\"\n}\n\nPROJECT_ID=$(create_project \"New-Standardized-Project\" | jq '.id')\n\nadd_file \"README.md\" \"# Welcome to our standardized project\" $PROJECT_ID\nadd_file \".gitlab-ci.yml\" \"stages:\\n  - build\\n  - test\\n  - deploy\" $PROJECT_ID\nadd_file \"CONTRIBUTING.md\" \"## How to contribute to this project\" $PROJECT_ID\n\necho \"Project created with ID: $PROJECT_ID\"\n```\n\n***This script creates a new project with a README, a basic CI/CD configuration, and a CONTRIBUTING guide. You can expand this to include more files or even clone a template repository.***\n\n#### Performance optimization\n\nAdmin: ***Our merge request creation process is slow. How can we diagnose and improve this? Assume I am an admin.***\n\nChat: ***As an instance admin, there are a few potential areas you can investigate to diagnose and improve the merge request creation process:\nDatabase Performance: The provided quotes show some example SQL queries related to merge request metrics. Slow database queries can significantly impact merge request creation performance. You should review the database performance, indexes, and query plans for any queries involved in the merge request creation process.***\n\n- ***Background jobs: Merge request creation may involve background jobs (e.g., for data processing, notifications, etc.). If these jobs are backed up or running slowly, it can impact the overall merge request creation time. Check the background job queues and workers.***\n- ***Code optimization: Analyze the code responsible for merge request creation to identify any potential bottlenecks or inefficiencies. This could include things like unnecessary database queries, inefficient algorithms, or lack of caching.***\n- ***Resource utilization: Monitor the resource utilization (CPU, memory, disk I/O) of the GitLab application servers during merge request creation. High resource utilization can lead to performance degradation.***\n- ***Network performance: If your GitLab instance is distributed across multiple nodes or servers, network performance between these components can impact merge request creation times. Check for any network bottlenecks or latency issues.***\n- ***Caching: Ensure that appropriate caching mechanisms are in place and functioning correctly. Inefficient or incorrect caching can lead to unnecessary overhead during merge request creation.***\n- ***Load testing: Perform load testing to simulate real-world scenarios and identify any performance bottlenecks or scalability issues that may arise under high load.***\n- ***Logging and monitoring: Enable detailed logging and monitoring for the merge request creation process. This can help identify specific areas of slowness or bottlenecks.***\n\n***To effectively diagnose and improve the merge request creation process, you'll likely need to combine multiple techniques, such as profiling, code analysis, database optimization, and load testing. Additionally, consulting the GitLab documentation and community resources can provide valuable insights and best practices specific to your GitLab version and configuration.***\n\n#### Troubleshooting complex issues\n\nAdmin: ***We're experiencing intermittent 502 errors on our GitLab instance. How can we troubleshoot this? I am an instance admin, how can I check the logs to find answers?***\n\nChat: ***To troubleshoot intermittent 502 errors on your GitLab instance as an admin, you can follow these steps:***\n\n***1. Check the main GitLab logs while reproducing the issue by running:***\n\n```\nsudo gitlab-ctl tail | tee /tmp/\u003Ccase-ID-and-keywords>.log\n```\n\n***2. Press Ctrl+C to stop tailing the logs.***\n\n***3. Run GitLabSOS to gather broader diagnostics about your instance:***\n\n```\nsudo /opt/gitlab/embedded/bin/gitlab-sos\n```\n\n***4. Use the fast-stats tool to analyze performance statistics from the logs:***\n\n```\nsudo /opt/gitlab/embedded/bin/fast-stats /var/log/gitlab/gitlab-rails/production.log\n```\n\n***5.Look for relevant log entries using the correlation ID that is present in most requests.***\n\n***6. Check the Pages logs (gitlab_pages_error.log) for any specific errors related to Pages communication issues with the GitLab API or loopback timeouts if using an AWS Network Load Balancer.***\n\n***7. Ensure your gitlab-secrets.json file is synced across all GitLab Pages instances if using `domain_config_source=auto`.***\n\n***8. If using systemd, configure GitLab Pages to listen on an explicit IP and port to avoid /tmp being cleaned up.***\n\n## Get started with GitLab Duo Chat\n\nGitLab Duo Chat is a powerful ally for administrators of self-managed GitLab instances. By leveraging its capabilities, you can tackle complex tasks more efficiently, learn new techniques, and ultimately become a more effective GitLab administrator.\n\nWe encourage you to experiment with Chat in your administrative workflows. Remember to use it responsibly and always verify the solutions it provides.\n\n> [Try GitLab Duo free for 60 days](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/).\n\n### Resources\n- [GitLab Duo documentation](https://docs.gitlab.com/ee/user/gitlab_duo/)\n- [GitLab Rails Console Cheat Sheet](https://docs.gitlab.com/ee/administration/operations/rails_console.html)\n- [GitLab API documentation](https://docs.gitlab.com/ee/api/)\n- [10 best practices for using AI-powered GitLab Duo Chat](https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/)\n- [GitLab Duo Chat 101: Get more done on GitLab with our AI assistant](https://about.gitlab.com/blog/gitlab-duo-chat-101-get-more-done-on-gitlab-with-our-ai-assistant/)\n",[786,746,478,9,701],{"slug":4576,"featured":90,"template":683},"mastering-gitlab-admin-tasks-with-gitlab-duo-chat","content:en-us:blog:mastering-gitlab-admin-tasks-with-gitlab-duo-chat.yml","Mastering Gitlab Admin Tasks With Gitlab Duo Chat","en-us/blog/mastering-gitlab-admin-tasks-with-gitlab-duo-chat.yml","en-us/blog/mastering-gitlab-admin-tasks-with-gitlab-duo-chat",{"_path":4582,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4583,"content":4589,"config":4595,"_id":4597,"_type":13,"title":4598,"_source":15,"_file":4599,"_stem":4600,"_extension":18},"/en-us/blog/mastering-the-all-remote-environment",{"title":4584,"description":4585,"ogTitle":4584,"ogDescription":4585,"noIndex":6,"ogImage":4586,"ogUrl":4587,"ogSiteName":670,"ogType":671,"canonicalUrls":4587,"schema":4588},"Mastering the all-remote environment: My top 5 challenges and solutions","Unlocking potential and overcoming challenges in an all-remote environment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673105/Blog/Hero%20Images/joshua-tree-desert-sunset.jpg","https://about.gitlab.com/blog/mastering-the-all-remote-environment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Mastering the all-remote environment: My top 5 challenges and solutions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Shawn Winters\"}],\n        \"datePublished\": \"2019-12-30\",\n      }",{"title":4584,"description":4585,"authors":4590,"heroImage":4586,"date":4592,"body":4593,"category":996,"tags":4594},[4591],"Shawn Winters","2019-12-30","\nSince joining GitLab in late 2018, I’ve experienced a whirlwind of excitement, travel, and continuous change. While GitLab provides the [flexibility](/company/culture/all-remote/benefits/) I always wanted in a career, functioning within an all-remote organization has its [challenges](/company/culture/all-remote/drawbacks/). I’m highlighting these, along with solutions I’ve discovered and engineered, in hopes of helping others who are new to remote work.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/QTPeyRW766Q\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn this [GitLab Unfiltered video](https://youtu.be/QTPeyRW766Q) above, I sit down with Darren Murph to talk about working in an all-remote setting, providing a glimpse at what's possible by embracing this style of work.\n{: .note.text-center}\n\n## The lack of physical human interaction\n\nTurns out, I crave human interaction. The buzz of being around others gives me energy. Although small talk and watercooler banter can be distracting at times, social interaction is (overall) a calming and rewarding experience for me.\n\nI overcame this by leveraging technology like Slack and Zoom to [constantly communicate](/company/culture/all-remote/informal-communication/) with my colleagues. I’m surprised by how well these tools simulate the effect of being in the office. In fact, video calls oftentimes add an element of intimacy not found in the office, as I’m frequently able to visit a colleague’s home, coworking space, or favorite workplace. This allows [a more authentic connection](/blog/tips-for-mastering-video-calls/) than what’s typically brought into a colocated office setting.\n\n## Questioning my productivity\n\nI struggled early on without the social validation that comes with working in an office. At GitLab, team members are given autonomy to be a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one), which can take time to fully embrace and appreciate.\n\nTo overcome this, I was intentional about defining what a solid day’s work looked like in my role. I asked myself what things I should aim to accomplish each day, no matter what, to be productive based on [goals and objectives](/company/okrs/) that applied to me. This produced a sense of freedom I had not experienced before, and relieved a mental burden. It also allowed me to spend additional time with family and enjoying hobbies.\n\n## Grappling with a chaotic, overloaded calendar\n\nMeetings are a necessary evil in some instances, but GitLab [views them very differently](/company/culture/all-remote/meetings/) than most organizations. It is important to stay on top of what the company is doing, while also making sure you're up-to-date on your particular business unit. I looked for ways to bridge this gap given that there are no hallway conversations in an all-remote setting.\n\nDespite GitLab’s bias towards [asynchronous communication](/blog/remote-communication/), I still found the quantity of meetings on my calendar to be overwhelming. I felt like I had no time to get my actual job done. As I acclimated to all-remote life, I realized that every meeting was recorded. This allowed me to go back and listen to important meetings during downtime.\n\nI also embraced the reality that many GitLab meetings are optional. Once I understood which meetings were vital to my success, and which were helpful for my knowledge of how the company was operating, I was able to use meetings to my advantage rather than being at the mercy of an overloaded schedule.\n\n## Can you _really_ document everything?\n\nGitLab is a huge proponent of documenting everything in our [company handbook](/handbook/about/#count-handbook-pages). In a typical office setting, there are people around to answer every question. Here, I’m encouraged to search for information first – to see if my question has already been answered and documented – which was a major challenge for me early on. My instinct was to ask someone instead of searching in the handbook, and I realized that part of this stemmed from my desire to take any excuse to socialize with colleagues.\n\nI overcame this by retraining myself and flipping an old habit on its head. If I was unable to find an answer in the handbook, I was not only empowered to seek answers from others, but also to use a [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/#merge-requests) to document the solution and help others.\n\n## Turning my video on\n\nGitLab conducts all meetings – internal and external – using a video conferencing platform. With no offices, we lean on video calls to maintain human contact. As participants in a video conference, we voluntarily enable a face-to-face interaction with a person (or persons) on the other side, which requires some level of courage and humility. Initially, this was a challenge for me. I was very uncomfortable turning my video on, routinely concerned with my appearance, my surroundings, and my background.\n\nI overcame this challenge by embracing GitLab’s reminder that [meetings are about the work, not the background](/company/culture/all-remote/meetings/#meetings-are-about-the-work-not-the-background). By being vulnerable, I learned that bringing my genuine self to a video call enabled me to build stronger relationships with colleagues and prospects. Now, I make it my goal to have my video turned on as much as possible. This has helped me overcome my fear of being self-conscious, while allowing me to engage with more people in a meaningful way.\n\nAs more companies embrace all-remote, it’s important for us to collectively discuss challenges and solutions with one another. We're interested in hearing about challenges faced by others implementing remote work, so we can ideally find and document solutions.\n\nLearn more about [requesting a Pick Your Brain interview on all-remote](/company/culture/all-remote/pick-your-brain/)!\n\n*Cover image by [Darren Murph](https://twitter.com/darrenmurph).*\n",[9,680,998],{"slug":4596,"featured":6,"template":683},"mastering-the-all-remote-environment","content:en-us:blog:mastering-the-all-remote-environment.yml","Mastering The All Remote Environment","en-us/blog/mastering-the-all-remote-environment.yml","en-us/blog/mastering-the-all-remote-environment",{"_path":4602,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4603,"content":4608,"config":4613,"_id":4615,"_type":13,"title":4616,"_source":15,"_file":4617,"_stem":4618,"_extension":18},"/en-us/blog/meet-gitlab-duo-the-suite-of-ai-capabilities",{"title":4604,"description":4605,"ogTitle":4604,"ogDescription":4605,"noIndex":6,"ogImage":2641,"ogUrl":4606,"ogSiteName":670,"ogType":671,"canonicalUrls":4606,"schema":4607},"Meet GitLab Duo, the suite of AI capabilities powering your workflows","Learn about GitLab Duo, an expanding toolbox of features integrated directly into the GitLab platform to assist DevSecOps teams.","https://about.gitlab.com/blog/meet-gitlab-duo-the-suite-of-ai-capabilities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet GitLab Duo, the suite of AI capabilities powering your workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2023-06-22\",\n      }",{"title":4604,"description":4605,"authors":4609,"heroImage":2641,"date":4610,"body":4611,"category":806,"tags":4612},[2840],"2023-06-22","\nHave you ever wanted a real-time partner alongside you to help as you develop code, improve operations, and secure your software? [GitLab Duo](https://about.gitlab.com/gitlab-duo/), available now, is a powerful set of AI capabilities within GitLab’s DevSecOps Platform that does just that – suggesting code, explaining vulnerabilities, forecasting value streams, and much more.\n\nThe name GitLab Duo is rooted in You + GitLab AI = the AI dynamic duo. GitLab Duo goes beyond just being an AI pair programmer: It is an expanding toolbox of features integrated into the DevSecOps Platform to help teams across the entire software development environment become more efficient. GitLab Duo is your go-to for planning refinement, security risk resolution, CI/CD pipeline health, and analytics charting. \n\nGitLab Duo is a customer-centric approach focused on privacy first, where customers know their intellectual property is secured.\n\n## GitLab Duo capabilities\nGitLab Duo includes:\n\n- **Code Suggestions** helps developers create new code and update existing code, reducing cognitive load, improving efficiency, and allowing them to spend more time adding unique value to their applications.\n- **Explain this Code** uses AI to examine code, both within a merge request and in the repository view, and provides a natural language explanation, helping to enable all teams to understand the code being merged.\n- **Explain this Vulnerability** helps developers write more secure code by providing a natural language description of the vulnerability and the steps to resolve it.\n- **Generate detailed descriptions of epics, issues, and tasks** helps ensure all teams are aligned and can achieve their common goals faster.\n- **Summarize Issue Comments** helps get everyone up to speed quickly in epics, issues, and tasks.  \n- **Chat** enables users to ask configuration questions and receive natural language explanations, as well as links to GitLab Docs. \n\nThroughout the year, all the GitLab Duo capabilities will become available via GitLab Duo Chat. As humans, we gravitate towards conversational chat, which is why we expect GitLab Duo Chat to become a de facto choice for how users interact with GitLab AI capabilities. We will be adding new capabilities to GitLab Duo, including assisting users with generating planning descriptions, using natural language for CI configuration and chart generation, refactoring vulnerabilities from code, suggesting a fix for failed tests, helping resolve CI/CD pipeline failures, summarizing vulnerability reports, and assisting with merge request reviews.\n\nAt GitLab, we believe everyone can contribute. By bringing GitLab Duo capabilities to every persona who uses GitLab, everyone can benefit from AI-powered workflows and organizations can ship secure software faster.\n\n## The impact of GitLab Duo on workflow efficiency\nOur goal is to help you achieve a 10x improvement in workflow efficiency by tapping into all of the [DevSecOps Platform’s AI capabilities](https://about.gitlab.com/blog/ai-ml-in-devsecops-series/). With GitLab 16, business leaders get an enterprise-grade solution that delivers greater efficiency by reducing tool sprawl and gives teams greater visibility into their workflows.\n\nTo learn more about the exciting features and capabilities of GitLab Duo, [watch the replay of our GitLab 16 event](https://about.gitlab.com/sixteen/).\n\nStay tuned for more updates, and get ready to experience a new era of AI-powered DevSecOps workflows with [GitLab Duo](https://about.gitlab.com/gitlab-duo/).\n",[678,9,786,703],{"slug":4614,"featured":6,"template":683},"meet-gitlab-duo-the-suite-of-ai-capabilities","content:en-us:blog:meet-gitlab-duo-the-suite-of-ai-capabilities.yml","Meet Gitlab Duo The Suite Of Ai Capabilities","en-us/blog/meet-gitlab-duo-the-suite-of-ai-capabilities.yml","en-us/blog/meet-gitlab-duo-the-suite-of-ai-capabilities",{"_path":4620,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4621,"content":4627,"config":4631,"_id":4633,"_type":13,"title":4634,"_source":15,"_file":4635,"_stem":4636,"_extension":18},"/en-us/blog/meet-partner-the-good-docs-project",{"title":4622,"description":4623,"ogTitle":4622,"ogDescription":4623,"noIndex":6,"ogImage":4624,"ogUrl":4625,"ogSiteName":670,"ogType":671,"canonicalUrls":4625,"schema":4626},"How The Good Docs Project uses GitLab for documentation as code and more","In this video interview, meet our new Open Source Partner, The Good Docs Project, and learn about the benefits they are extracting from the DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682841/Blog/Hero%20Images/documentation1.jpg","https://about.gitlab.com/blog/meet-partner-the-good-docs-project","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How The Good Docs Project uses GitLab for documentation as code and more\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-07-06\",\n      }",{"title":4622,"description":4623,"authors":4628,"heroImage":4624,"date":2194,"body":4629,"category":827,"tags":4630},[3504],"\n\n[The Good Docs Project](https://thegooddocsproject.dev/welcome/) wants to help improve software documentation across the entire [open source](https://go.gitlab.com/spHNym) ecosystem. The community provides templates and other resources to help open source developers write, maintain, and improve project documentation. Last year, they voted to migrate to GitLab. Since then, they've discovered how using an all-in-one DevSecOps platform can streamline and accelerate work in open source communities like theirs.\n\nThey've now joined the [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) community, and they're sharing their knowledge and resources with other open source projects also using GitLab to build a world where anyone can contribute.\n\nI sat down with some community members from The Good Docs Project to learn what brought them together, what motivates their work, and where they're headed next.\n\nIn this interview, you'll learn:\n* How switching to GitLab enabled an open source project to unify planning, development, and testing work onto a single platform\n* How a community of technical writers and editors uses GitLab to develop documentation as code\n* How an open source project built community-focused git toolchain training on GitLab\n\n### Watch the interview\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Bek7vLmNmME\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more\n\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n\nCover image by \u003Ca href=\"https://unsplash.com/@beatriz_perez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Beatriz Pérez Moya\u003C/a> on \u003Ca href=\"https://unsplash.com/photos/XN4T2PVUUgk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>  \n{: .note}\n",[1187,266,9],{"slug":4632,"featured":6,"template":683},"meet-partner-the-good-docs-project","content:en-us:blog:meet-partner-the-good-docs-project.yml","Meet Partner The Good Docs Project","en-us/blog/meet-partner-the-good-docs-project.yml","en-us/blog/meet-partner-the-good-docs-project",{"_path":4638,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4639,"content":4645,"config":4651,"_id":4653,"_type":13,"title":4654,"_source":15,"_file":4655,"_stem":4656,"_extension":18},"/en-us/blog/meltano-functional-group-update-post",{"title":4640,"description":4641,"ogTitle":4640,"ogDescription":4641,"noIndex":6,"ogImage":4642,"ogUrl":4643,"ogSiteName":670,"ogType":671,"canonicalUrls":4643,"schema":4644},"New Meltano personas, priorities, and updates from the team","There's a lot going on — here are some of the highlights on user research, dogfooding Meltano, embedding engineers, and hiring!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678847/Blog/Hero%20Images/meltano-fgu.jpg","https://about.gitlab.com/blog/meltano-functional-group-update-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New Meltano personas, priorities, and updates from the team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jacob Schatz\"}],\n        \"datePublished\": \"2018-10-08\",\n      }",{"title":4640,"description":4641,"authors":4646,"heroImage":4642,"date":4648,"body":4649,"category":849,"tags":4650},[4647],"Jacob Schatz","2018-10-08","\nJacob Schatz here, Staff Engineer for [Meltano](https://gitlab.com/meltano)! We've been heads down working on improving Meltano, and figured it was time for an update. We've had some great conversations that have helped us identify two general personas. Our team is also growing, and we're ready for frontend contributions, but more on that later.\n\nWe've been conducting interviews to zero in on what our users will want, what they're currently doing, and what tools they're using. Over the course of those conversations, we saw two main scenarios emerge. People either wanted a command line interface (CLI) or a graphical user interface (GUI). The GUIs that exist are painful to use, and not very intuitive. In both scenarios, people we spoke with are frustrated. This goes back to the original reason [we decided to create Meltano](/blog/hey-data-teams-we-are-working-on-a-tool-just-for-you/) — our data team members were relying on frustrating and expensive toolsets with poor UIs.\n\n### What are the Meltano personas?\n\nOur conversations revealed two general types of users:\n* Users who have engineers on staff\n* Users who do not have engineers on staff, or their engineers do not have bandwidth to help them\n\nThe Data team at GitLab, for example, has data engineers on staff who are willing, able, and happy to write Python. We won't be able to write every extractor and loader, so our users can follow our [specifications](https://gitlab.com/meltano/specifications), which are based off of the [Singer specifications](https://github.com/singer-io/getting-started). We want to make that as easy as possible, so Meltano can be the glue between all these different pieces.\n\nFor the other teams who don’t have the technical resources, we want to make it as if they had engineers on staff. Ideally, they'll just need to click a couple of buttons, run extract, load and transform with the extractors and loaders that we already have. Hopefully in the future the community can contribute more to these types of different extractors and loaders.\n\nYou can check out our updated [readme](https://gitlab.com/meltano/meltano/blob/master/README.md) with more info about Meltano and our personas. We're working iteratively, so if you have a different setup or scenario to share, we want to hear from you about your experience! Get in touch with us and tell us about your struggles or successes with your data team.\n\n### What’s next?\n\nWe're focused on our own CLI and GUI, and continuing to build more extractors and loaders (or [\"taps and targets\"](https://www.singer.io/)). We will be the glue that ties everything together. While current Singer taps and targets support extracting and loading, we'll be supporting much more, like removal of PII. Our CLI will support all of this from one configuration. We also want the CLI to have a really nice user experience, so I'm working with GitLab UX to help make it happen.\n\nAs always, we’re looking for contributors! In the [Dashboard project](https://gitlab.com/meltano/dashboard) you’ll see the Chart.js library that I’m building to make really nice dashboards for Meltano. Although we've had a ton of great Python contributions, we haven’t had as many contributors to the frontend, so we’d love your help there.\n\n### In other news\nThere's a lot going on, here are some of the highlights!\n\n#### Dogfooding\nIn my experience, unless one experiences the direct results of the code they write, and feel the pain their users feel when they hit a bug, one might not correctly solve the problem. Currently, we fulfill the data team's requests, but if something doesn't work they merely report back to us, without us experiencing the pain ourselves. We're changing how we work in order to imprint the idea that if something is broken, it's the Meltano team's responsibility. We’re all investigating every single pipeline failure, regardless of whose “fault” it is, because these suggest that it may be a poor user experience.\n\n#### Embedded engineers\nIn order to dogfood better, we've taken a data engineer from the data team, and an engineer from the Meltano team. They split their work 50/50 so each does half of their usual work and half of each other's work. It's already made a huge difference by giving us more eyes and ears on lots of issues, and allowing the engineers to approach problems from a different angle. Another added benefit is that every Meltano engineer gets direct exposure and experience from the data team, to make them better data scientists as well product engineers.\n\nThat's all for now, get in touch with us in our [issue tracker](https://gitlab.com/groups/meltano/-/boards), and tweet us [@meltanodata](https://twitter.com/meltanodata)!\n\nCover [image](https://unsplash.com/photos/2FPjlAyMQTA) by [John Schnobrich](https://unsplash.com/@johnschno) on Unsplash\n{: .note}\n\n[Emily von Hoffmann](https://about.gitlab.com/company/team/#emvonhoffmann) contributed to this post.\n{: .note}\n",[976,9,3058,680,894],{"slug":4652,"featured":6,"template":683},"meltano-functional-group-update-post","content:en-us:blog:meltano-functional-group-update-post.yml","Meltano Functional Group Update Post","en-us/blog/meltano-functional-group-update-post.yml","en-us/blog/meltano-functional-group-update-post",{"_path":4658,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4659,"content":4664,"config":4669,"_id":4671,"_type":13,"title":4672,"_source":15,"_file":4673,"_stem":4674,"_extension":18},"/en-us/blog/merge-request-changes-summary-ai",{"title":4660,"description":4661,"ogTitle":4660,"ogDescription":4661,"noIndex":6,"ogImage":906,"ogUrl":4662,"ogSiteName":670,"ogType":671,"canonicalUrls":4662,"schema":4663},"ML experiment: Summarize merge request changes","Learn how GitLab is experimenting with ML-powered merge request changes summarization in this sixth installment of our ongoing AI/ML in DevSecOps series.","https://about.gitlab.com/blog/merge-request-changes-summary-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Summarize merge request changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2023-04-20\",\n      }",{"title":4660,"description":4661,"authors":4665,"heroImage":906,"date":4666,"body":4667,"category":806,"tags":4668},[2370],"2023-04-20","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i> \n\nMerge requests are the central point of collaboration for code changes in GitLab. They often contain a variety of changes across many files and services within a project. Often, merge requests communicate the intent of the change as it relates to an issue being resolved, but they might not describe what was changed to achieve that. As review cycles progress, the current state of the merge request can become out of sync with the realities of the proposed changes and keeping people informed. We believe that we can leverage AI and large language models (LLMs) to help provide relevant summaries of a merge request and its proposed changes, so reviewers and authors can spend more time discussing changes and less time keeping descriptions updated.\n\nIn a rapid prototype, [Kerri Miller](https://gitlab.com/kerrizor), Staff Backend Engineer for our [Code Review Group](/handbook/product/categories/#code-review-group), used AI to summarize the merge request changes directly within the [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/). She developed a `/summarize_diff` quick action to post a summary of changes into a comment:\n\n![Merge request summary via AI](https://about.gitlab.com/images/blogimages/merge-request-changes-summary-ai.gif){: .shadow}\n\n## Iterating on AI/ML features\nWhile just an experiment today, we are iterating on how to effectively bring features like this to our customers. We're starting with providing complete summaries of what changes a merge request makes, and are beginning to look at more targeted flows to enhance the review cycle experience. Current areas we're investigating include providing:\n\n- Summaries of what's changed between each review cycle in a merge request.\n- Summaries of review feedback to merge request authors.\n\nThis experiment is just the start of the ways we're looking to infuse GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[851,701,9,786],{"slug":4670,"featured":6,"template":683},"merge-request-changes-summary-ai","content:en-us:blog:merge-request-changes-summary-ai.yml","Merge Request Changes Summary Ai","en-us/blog/merge-request-changes-summary-ai.yml","en-us/blog/merge-request-changes-summary-ai",{"_path":4676,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4677,"content":4682,"config":4687,"_id":4689,"_type":13,"title":4690,"_source":15,"_file":4691,"_stem":4692,"_extension":18},"/en-us/blog/merge-request-suggest-a-test",{"title":4678,"description":4679,"ogTitle":4678,"ogDescription":4679,"noIndex":6,"ogImage":2187,"ogUrl":4680,"ogSiteName":670,"ogType":671,"canonicalUrls":4680,"schema":4681},"ML experiment: Generate tests for code changes","Learn how GitLab is experimenting with ML-powered test suggestions in this latest installment of our ongoing 'AI/ML in DevSecOps' series.","https://about.gitlab.com/blog/merge-request-suggest-a-test","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Generate tests for code changes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2023-04-27\",\n      }",{"title":4678,"description":4679,"authors":4683,"heroImage":2187,"date":4684,"body":4685,"category":806,"tags":4686},[2370],"2023-04-27","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nProposing changes and new features via merge requests is great, but what about the tests? Sometimes, tests can be the hardest part of any code change you make. Maybe you're not sure how to start writing the tests? Maybe the test doesn't cover all the scenarios that need to be tested? Maybe you just want to get a second opinion on the tests that were written? We believe that we can use generative AI and large language models (LLMs) to help provide relevant test coverage for the proposed changes, so reviewers and authors can have confidence in the quality of code changes being submitted.\n\nIn a rapid prototype, [Phil Hughes](https://gitlab.com/iamphill), Staff Frontend Engineer for our [Code Review Group](/handbook/product/categories/#code-review-group), used AI to generate suggested test coverage for changes directly in the [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/). He added a new option on merge request files to provide suggested tests in a sidebar:\n\n![Merge request test generation AI](https://about.gitlab.com/images/blogimages/merge-request-generate-tests-ai.gif){: .shadow}\n\n## Iterating on AI/ML features\n\nWhile just an experiment today, we are iterating on how to effectively bring features like this to our customers. We're beginning by generating these test suggestions, and seeking ways to incorporate them into the review flow. We're exploring ideas like:\n\n- Automatic detection of missing tests, with suggestions to add coverage\n- Automated review of the proposed tests in the merge request, for appropriateness and completeness\n\nThis experiment is just the start of the ways we're infusing GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](https://about.gitlab.com/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":4688,"featured":6,"template":683},"merge-request-suggest-a-test","content:en-us:blog:merge-request-suggest-a-test.yml","Merge Request Suggest A Test","en-us/blog/merge-request-suggest-a-test.yml","en-us/blog/merge-request-suggest-a-test",{"_path":4694,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4695,"content":4701,"config":4706,"_id":4708,"_type":13,"title":4709,"_source":15,"_file":4710,"_stem":4711,"_extension":18},"/en-us/blog/merge-trains-explained",{"title":4696,"description":4697,"ogTitle":4696,"ogDescription":4697,"noIndex":6,"ogImage":4698,"ogUrl":4699,"ogSiteName":670,"ogType":671,"canonicalUrls":4699,"schema":4700},"How to use merge train pipelines with GitLab","Read here an introduction on what merge trains are, how to use them and how to incorporate them to your GitLab project.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667210/Blog/Hero%20Images/merge-train-explained-banner.jpg","https://about.gitlab.com/blog/merge-trains-explained","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use merge train pipelines with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2020-12-14\",\n      }",{"title":4696,"description":4697,"authors":4702,"heroImage":4698,"date":4703,"body":4704,"category":849,"tags":4705},[1869],"2020-12-14","This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-01-20.\n{: .alert .alert-info .note}\n\n[Merge trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) is a powerful GitLab feature that empowers users to harness the potential of [pipelines for merge results](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) to the fullest and also automatically merge a series of (queued) merge requests (MRs) without breaking the target branch. However, due to the structural complexity of the concept, users are often unable to use it effectively for their projects and play it safe by restricting their usage to MRs that pose minimum or no conflict with the target branch.\n\nAs a [senior product designer for Continuous Integration (CI)](/company/team/#veethikaa), I often deconstruct certain concepts and logic for features related to CI so that I have a strong foundation of understanding when making design proposals. Recently, I had a chance to hold a discussion around a very interesting feature - merge trains — with the team. This post unpacks the concept of merge trains by explaining the difference between merge trains, pipelines for MRs, and pipelines for merge results.\n\n## Pipelines for merge requests\n\nGenerally, when a new merge request is created, a pipeline runs to check if the new changes are eligible to be merged to the target branch. This is called the pipeline for merge requests (MRs). A good practice is to only keep the necessary jobs for validating the changes at this step, so the pipeline doesn’t take a long time to complete and CI minutes are not overused. GitLab allows users to [configure the pipeline for MRs](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) by adding `rules:if: $CI_MERGE_REQUEST_IID` to the jobs they wish to run for MRs.\n\n![Pipeline for merge request](https://about.gitlab.com/images/blogimages/merge-train-explained-pipeline-for-merge-requests.jpg)\n\n### Pipelines for merge results\n\nMerge request pipelines verify the branch in isolation. The target branch may change several times during the lifetime of the MR, and these changes are not taken into consideration. In the time during which the pipeline for the MR runs (and succeeds), if the target branch progresses in the background and a user merges the changes to the target branch, they might eventually end up with a broken target.\n\nWhen a [pipeline for merge results](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) runs, GitLab CI performs a _pretend_ merge against the updated target branch by creating a commit on an internal ref from the source branch, and then runs a pipeline against it. This pipeline validates the result prior to merging, therefore increasing the chances of keeping the target branch green.\n\n![Pipeline for merge results](https://about.gitlab.com/images/blogimages/merge-train-explained-pipeline-for-merge-results.jpg)\n\nWe should keep in mind that this pipeline does not run automatically with every update to the target branch. To learn more about this feature in detail and understand the process of enabling it in your GitLab instance, you can refer to the [official documentation on merge results](https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipelines.html).\n\nHowever, if a long time has passed since the last successful pipeline ran, by the time the MR is ready to be merged, the target branch may have already changed and advanced. If we go ahead and merge your MR without re-running the pipeline for MRs, we could end up with a broken target branch. Merge trains can prevent this from happening.\n\n### About merge trains\n\nPipeline for merge results is an extremely useful feature in itself, but tracking the right slot to merge the feature branch into the target and remembering to run the pipeline manually before doing so is a lot to expect from a developer buried in tasks that involve deep logical thinking.\n\nTo tackle this complexity in workflow, GitLab introduced [the merge trains feature](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) in [GitLab Premium 12.0](/releases/2019/06/22/gitlab-12-0-released/#sequential-merge-trains). Merge trains allow users to capitalize on the capabilities of pipelines for merge results to automate the process of merging to the target branch with minimum chances of breaking it.\n\nWith merge trains enabled, a merge request can be added to the train, which takes care of it until merged.\nA merge train can be imagined as a queue of MRs that is automatically managed for you.\n\n#### How do merge trains work?\n\nWhen users queue up their MRs in a merge train, GitLab performs a pretend merge for each source branch on top of the previous branch in the queue, where the first branch on the train is merged against the target branch.\nBy creating a temporary commit for each of these merges, GitLab can run merged result pipelines.\nThe first MR in the queue, after having a successful pipeline run for MRs, gets merged to the target branch.\n\nEvery time a merge request is merged into the target branch, the pipelines for the newly added MRs in the train would run against the target branch and the newly added changes from the recently merged MR and changes that are from MRs already in the train.\n\n![Pipeline for merge results](https://about.gitlab.com/images/blogimages/merge-train-explained-working.gif)\n\nMerge trains carry an immense possibility for innovation with GitLab as a toolchain. But to be able to build upon the concept, it is imperative to have a holistic understanding of the same at the system level.\n\nHopefully, this post does the job of breaking down the concept into layman's terms, thereby opening doors for future collaboration within [stage groups](/handbook/product/categories/) at GitLab.\n\nHave suggestions around improving merge trains? please leave your thoughts on this [epic](https://gitlab.com/groups/gitlab-org/-/epics/5122).\n",[1396,1397,9,851,680],{"slug":4707,"featured":6,"template":683},"merge-trains-explained","content:en-us:blog:merge-trains-explained.yml","Merge Trains Explained","en-us/blog/merge-trains-explained.yml","en-us/blog/merge-trains-explained",{"_path":4713,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4714,"content":4719,"config":4725,"_id":4727,"_type":13,"title":4728,"_source":15,"_file":4729,"_stem":4730,"_extension":18},"/en-us/blog/migrating-arch-linux-packaging-infrastructure-gitlab",{"title":4715,"description":4716,"ogTitle":4715,"ogDescription":4716,"noIndex":6,"ogImage":1367,"ogUrl":4717,"ogSiteName":670,"ogType":671,"canonicalUrls":4717,"schema":4718},"Migrating Arch Linux's packaging infrastructure to GitLab","Arch Linux developer Levente Polyak explains how the project recently migrated its packaging infrastructure to GitLab and what Arch Linux gained as a result.","https://about.gitlab.com/blog/migrating-arch-linux-packaging-infrastructure-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrating Arch Linux's packaging infrastructure to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Levente Polyak\"}],\n        \"datePublished\": \"2023-09-11\",\n      }",{"title":4715,"description":4716,"authors":4720,"heroImage":1367,"date":4722,"body":4723,"category":827,"tags":4724},[4721],"Levente Polyak","2023-09-11","\nThree years ago, the Arch Linux community began a migration to the GitLab DevSecOps Platform to modernize our software development tooling and processes.\nWe recently announced a major moment on that journey: [migrating our entire packaging toolchain to Git and GitLab](https://archlinux.org/news/git-migration-completed/).\nThis move completely reshaped our packaging workflow, tooling, and storage — the very backbone of our package creation process.\n\nThe move has been pivotal for our continued success as a project.\nOur [package repositories](https://archlinux.org/packages/) contain nearly 14,000 packages at the time of this writing, and [GitLab's collaborative features](/features/) empower our package maintainers to seamlessly collaborate, promoting efficient and effective teamwork.\nUsing GitLab as a central platform also enhances visibility across the project.\nWe can now effortlessly trace the history of changes, collaborate on enhancements and bugs, and follow the evolution of each package — all in a single place.\n\n> [Join GitLab at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about our dedication to open source.\n\nI'm a devoted free open source software engineer and currently have the privilege of serving as the project leader of Arch Linux.\nIn this article, I'll explain how and why we undertook this complex, but ultimately worthwhile, endeavor.\n\n## Understanding Arch Linux's infrastructure\nTo understand the complexity of this migration, you'll first need to understand the history of Arch's infrastructure.\n\nCentral to our distribution are our [PKGBUILD](https://wiki.archlinux.org/title/PKGBUILD) packaging sources, which are the essential blueprints that shape each package installable with [pacman](https://archlinux.org/pacman/) from our official repositories. Previously, our [packaging infrastructure](https://wiki.archlinux.org/title/Creating_packages) relied on [Subversion](https://subversion.apache.org/) for managing our packaging sources.\n\nFor more than a decade of [Arch Linux's development](https://archlinux.org/releng/releases/), Subversion served as a reliable companion for working with our packaging source code. However, the open source software development landscape has transformed significantly since the advent of the Arch Linux project; technologies have advanced and collaboration dynamics have evolved (note, for example, the popularization of [DevOps](https://about.gitlab.com/topics/devops/) processes and practices).\n\nRecognizing the need to adapt and optimize, we started a journey that would shape the future of how members of the Arch Linux community work together. To enhance collaboration and pave the way for future improvements to Arch, we decided to undertake migration of our packaging sources to individual Git repositories, and we chose to host them with GitLab.\n\n## Migrating 14,000 Arch Linux packages\nThis would be no small task.\nCurrently, the Arch Linux community maintains 13,930 installable packages, all of which are now managed in 12,138 individual Git repositories.\nBut we knew the benefits would be worth the effort involved in such an enormous migration.\n\nFor example, one of the standout advantages of Git is its ability to empower packagers with a new level of insight into their work.\nThe ease of inspecting local history would become a game-changer, especially as packaging evolved into a collective effort, with multiple maintainers collaborating to refine and enhance individual packages (Subversion requires a client-server connection to inspect the history).\n\nBut the decision to migrate was not just about adopting Git.\nIt also reflected our aspiration to provide our community with an environment that fosters extensive collaboration. Our history with Subversion had shown its limitations in this regard (more on that in a moment).\nThe synergy between Git packaging repositories and the GitLab platform was evident; it opened doors to enhanced collaboration, offered powerful version control features, and laid the groundwork for more efficient packaging processes.\n\nThe migration of Arch Linux's packaging infrastructure to GitLab was the pinnacle of several factors aligning perfectly.\nThe need for a more robust collaboration platform, the growing prominence of Git, and the desire to utilize the benefits of modern version control converged to make this move a natural progression for Arch.\n\nWe decided it was time to get it done.\n\n## Three years and a weekend\nArch Linux has been gradually adopting and migrating operations to GitLab over the course of three years.\nExtending that migration to our packaging infrastructure was the next vital step of the process — and the pivotal moment of switching to GitLab hosting and workflow for packaging occurred within [the span of a single weekend](https://archlinux.org/news/git-migration-announcement/).\n\nA change of this magnitude touches the very core of our distribution, and it was only possible with thorough, meticulous preparation.\nFor weeks, our migration team diligently crafted [a runbook](https://md.archlinux.org/utjjQ-bQTsipIKntPrpf8g#) that ensured every major aspect and change were considered, minimizing risk and boosting our confidence.\n\nWhen our concentrated migration effort began, the migration team focused entirely on this rollout, everyone collaborating in a [Jitsi](https://meet.jit.si/) video call with screen sharing.\nThe strategic choice of a weekend for performing the migration aligned perfectly with our volunteer-driven community, offering sufficient time for a buffer and quick resolution to any unforeseen hiccups.\n\nThe first challenge was transferring our extensive Subversion history to GitLab. For some time, we had been running `git-svn` with a timer to be able to provide some packaging history to another repository. \nOur [custom tooling](https://gitlab.archlinux.org/archlinux/arch-svn-package-to-git/) made use of `git-svn` imports, which was a gigantic monorepo containing all packages as individual branches.\n\nOur migration solution was a carefully crafted script that used [git-filter-repo](https://github.com/newren/git-filter-repo), of which we could run several instances in parallel and which also supported the ability to convert only repositories that changed since the last run (determined by deltas).\nThe script also filtered history, commit messages, rewrote author data to incorporate our GitLab user handles, filtered unwanted files, and more.\nAdditionally, we tagged all previous releases where we could determine the origin of the exact commit.\n\nBut the migration wasn't confined to a mere transfer of Subversion history to GitLab; it involved revisiting workflows, tools, and all software that interacted *with* the version control system.\nFrom redefining workflows to embracing new tools, every step was vital to ensuring that Arch Linux developed in a coherent way.\n\nWe also wanted to seize the moment as an opportunity to reimagine and revamp package maintainer tooling.\nSo we also created [pkgctl](https://man.archlinux.org/man/pkgctl.1.en), a modern interface that not only refreshed and streamlined our tooling but also enhanced user and contributor experience.\n\nFortunately, the entire migration flowed seamlessly.\nBy the end of the weekend, we had succeeded.\n\n## Benefits of a journey with GitLab\nOur packaging migration was the latest milestone in Arch Linux's overall journey with GitLab.\nMigrating our packaging infrastructure to GitLab allows us to maximize and enjoy those improvements even more.\n\nSince the Arch Linux community began [migrating to GitLab in 2020](https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/gitlab-open-source-partners/community-support/-/issues/11), Arch maintainers and contributors have enjoyed a significantly improved experience interacting with and contributing to the project. \nThe advantages not only enhance our current workflows but also open up exciting possibilities for the future.\n\nHere's a rundown of the benefits we've seen from our overall migration so far.\n\n### Deeper collaboration\nBefore the migration, for example, lack of a dedicated collaborative platform for our packaging sources posed challenges to both users and package maintainers. While [Flyspray](https://wiki.archlinux.org/title/Flyspray), our bug tracker, was valuable, its scope was limited to tracking issues rather than facilitating meaningful collaboration.\nProposed changes were often submitted as patch files in attachments, resulting in a cumbersome experience for users suggesting improvements and maintainers reviewing these changes.\n\nThe process of iterating through these patch files was tedious because we lacked the ability to comment on specific lines (not to mention the ability to discuss diverse sub-topics in individual threads).\n\nToday, GitLab's standard [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/) feature has improved this process dramatically. It helps us collaborate smoothly, allowing [threaded discussions](https://docs.gitlab.com/ee/user/discussions/index.html), precise comments, and [code suggestions](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/suggestions.html) on individual code segments. Although merge requests are a simple, staple feature, their impact on streamlining our processes is invaluable, serving as the bedrock of GitLab's collaborative strength.\n\nThe ability to seamlessly integrate issue tracking and merge requests within the same platform fosters a more cohesive and efficient workflow for our entire community. We're looking forward to tracking and managing packaging-related issues, bugs, and enhancements directly within GitLab soon.\n\n### Better automation\nOur use of [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) has played a crucial role in automating our development work across our software projects.\n\nWe utilize CI/CD pipelines for everything from running tests to auditing dependencies—even publishing release artifacts, such as Rust crates, automatically using a tag pipeline. The efficiency we gain through this functionality is invaluable for ensuring the integrity and quality of our projects. We've realized some security improvements, too. Automating our usage of dependencies means we become aware of tracked security issues in our software projects used dependencies via commit pipelines, as well as scheduled pipelines (so we can bump and potentially deploy/release our software projects in case its necessary).\n\n### Stronger community\nAdopting GitLab has helped us better serve our community. The [Service Desk feature](https://docs.gitlab.com/ee/user/project/service_desk/) has emerged as a game-changer, offering a streamlined channel to manage specific user requests.\nThis integration with GitLab enhances the workflow without sacrificing overview.\n\nAnd recently, we've significantly increased our use of [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/).\nWe rely on Pages for publishing documentation, monthly reports, our Web Key Directory and static sites, and we're enthusiastic about expanding its application in the future.\n\n## More than new tools\nArch Linux's migration wasn't just about adopting the latest tools. Our motivation for migrating — and the positive consequences of the upgrade — reflect the values of open source communities like ours, where working together is essential for moving forward.\nBy adopting GitLab, Arch Linux is improving our project's overall atmosphere, creating a space where contributions are welcomed, reviewed, and integrated more easily, and in a way that conforms to contemporary best practices.\n\nWe're proud to be [GitLab Open Source Partners](https://go.gitlab.com/BM5JwV), and we extend our gratitude to GitLab for providing a platform that seamlessly aligns with our vision.\n\n[Join GitLab at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about our dedication to open source.\n{: .note}\n",[1187,266,9],{"slug":4726,"featured":6,"template":683},"migrating-arch-linux-packaging-infrastructure-gitlab","content:en-us:blog:migrating-arch-linux-packaging-infrastructure-gitlab.yml","Migrating Arch Linux Packaging Infrastructure Gitlab","en-us/blog/migrating-arch-linux-packaging-infrastructure-gitlab.yml","en-us/blog/migrating-arch-linux-packaging-infrastructure-gitlab",{"_path":4732,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4733,"content":4739,"config":4744,"_id":4746,"_type":13,"title":4747,"_source":15,"_file":4748,"_stem":4749,"_extension":18},"/en-us/blog/migrating-to-puma-on-gitlab",{"title":4734,"description":4735,"ogTitle":4734,"ogDescription":4735,"noIndex":6,"ogImage":4736,"ogUrl":4737,"ogSiteName":670,"ogType":671,"canonicalUrls":4737,"schema":4738},"How we migrated application servers from Unicorn to Puma","It's been a long journey but with the release of GitLab 13.0 Puma is our default application server. Here's what we did and learned along the way.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681413/Blog/Hero%20Images/appserverpuma.jpg","https://about.gitlab.com/blog/migrating-to-puma-on-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we migrated application servers from Unicorn to Puma\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Craig Gomes\"}],\n        \"datePublished\": \"2020-07-08\",\n      }",{"title":4734,"description":4735,"authors":4740,"heroImage":4736,"date":1351,"body":4742,"category":849,"tags":4743},[4741],"Craig Gomes","\n\nIt’s been years in the making, but our journey to migrate our application servers from Unicorn to Puma is complete. With the Gitlab 12.9 release Puma was running on GitLab.com and now with 13.0 it is the default application server for everyone. This is the story about how we migrated from Unicorn to Puma and the results we’ve seen.\n\n## A starting point\n\nBoth [Unicorn](https://yhbt.net/unicorn/) and [Puma](https://puma.io) are web servers for Ruby on Rails. The big difference is that Unicorn is a single-threaded process model and Puma uses a multithreaded model. \n\nUnicorn has a multi-process, single-threaded architecture to make better use of available CPU cores (processes can run on different cores) and to have stronger fault tolerance (most failures stay isolated in only one process and cannot take down GitLab entirely). On startup, the Unicorn ‘main’ process loads a clean Ruby environment with the GitLab application code, and then spawns ‘workers’ which inherit this clean initial environment. The ‘main’ never handles any requests; that is left to the workers. The operating system network stack queues incoming requests and distributes them among the workers.\n\nUnlike Unicorn, Puma can run multiple threads for each worker. Puma can be tuned to run multiple threads and workers to make optimal use of your server and workload. For example, in Puma defining \"N workers\" with 1 thread is essentially equivalent to \"N Unicorn workers.\" In multi-threaded processes thread safety is critical to ensure proper functionality. We encountered one thread safety issue while migrating to Puma and we'll get to that shortly.\n\n### Technical Descriptions\n\nUnicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between unicorn and slow clients.\n\nPuma is a multi-threaded web server and our replacement for Unicorn. Unlike other Ruby Webservers, Puma was built for speed and parallelism. Puma is a small library that provides a very fast and concurrent HTTP 1.1 server for Ruby web applications. It is designed for running Rack apps only.\n\nWhat makes Puma so fast is the careful use of a Ragel extension to provide fast, accurate HTTP 1.1 protocol parsing. This makes the server scream without too many portability issues.\n\n## Why Puma?\n\nWe began early investigations into Puma believing it would help resolve some of our [memory growth issues](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3700) and also to help with scalability. By switching from Unicorn's single threaded process we could cut down on the number of processes running and the memory overhead of each of these processes. Ruby processes take up a significant amount of memory.  Threads, on the other hand, consume a much smaller amount of memory than workers because they are able to share a significantly larger portion of application memory.  When I/O causes a thread to pause, another thread can continue with its application request. In this way, multi-thread makes the best use of the available memory and CPU, reducing memory consumption by [approximately 40%](/releases/2020/05/22/gitlab-13-0-released/#reduced-memory-consumption-of-gitlab-with-puma).\n\n## The early appearance of Puma\n\nThe first appearance of Puma in a GitLab issue was in a discussion about using [multithreaded application servers](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3592), dating back to November 20, 2015. In our spirit of iteration, the first attempt at adding experimental support for Puma followed shortly after with a [merge request](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/1899) on November 25, 2015. The initial [results](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3592#note_2805965) indicated a lack of stability and thus did not merit us moving forward with Puma at the time. While the push [to improve our memory footprint](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/25421) continued, the efforts to move forward with Puma stalled for a while.\n\n## Experimental development use\n\nIn May, 2018 Puma was configured for [experimental development use](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/532) in GitLab Rails and [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2801). Later that year, we added [Puma metrics to Prometheus](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52769) to track our internal experimental usage of Puma. By early spring of 2019 GitLab moved forward with the creation of the [Memory Team](/blog/why-we-created-the-gitlab-memory-team/) whose early set of identified tasks was to deploy Puma to GitLab.com.\n\n\n## Implementation steps\n\nThe efforts to implement Puma on GitLab.com and for our self-managed customers started in earnest in early 2019 with the [Enable Puma Web Server for GitLab](https://gitlab.com/groups/gitlab-org/-/epics/954) epic and the creation of the Memory Team. One of the early steps we took was to [enable Puma by default in the GDK ](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/490) to get metrics and feedback from the community and our customers while we worked to deploy on GitLab.com.\n\nThe ability to measure the improvements achieved by the Puma deployment was critical to determining whether we had achieved our goals of overall memory reduction. To capture these metrics we set up [two identical environments](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62877) to test changes on a daily basis. This would allow us to quickly make changes to the worker/thread ratio within Puma and quickly review the impact of the changes.\n\n### A roll out plan\n\nWe have multiple pre-production environments and we follow a progression of deploying Puma to each of these stages (dev->ops->staging->canary->production). Within each of these stages we would deploy the changes to enable Puma and test the changes. Once we confirmed a successful deployment we would measure and make configuration changes for optimal performance and memory reduction.\n\n### Issues and Tuning\n\nEarly on we determined that our usage of [ChronicDuration](https://gitlab.com/gitlab-org/gitlab/-/issues/31285) was not thread-safe. We ended up [forking the code](https://gitlab.com/gitlab-org/gitlab/-/issues/31285#note_215961555) and distributing our own [gitlab-chronic-duration](https://gitlab.com/gitlab-org/gitlab-chronic-duration) to solve our thread-safety issues.\n\nWe encountered only minor issues in the previous environments but once we deployed to Canary our infrastructure team reported some [unacceptable latency issues](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7455#note_239070865). We spent a significant amount of time tuning [Puma](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/8334) for the optimal configuration of workers to threads. We also discovered some changes required to our [health-check endpoint](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4835) to ensure minimal to no downtime during upgrades.\n\n### Puma Upstream Patch\n\nAs we zeroed in on tuning GitLab.com with Puma we discovered that the capacity was not being evenly distributed. Puma capacity is calculated by `workers * threads`, so if you have 2 workers and 2 threads you have a capacity of 4. Since Puma uses round-robin to schedule requests, and no other criteria, we saw evidence of some workers being saturated while others sat idle. The simple [fix](https://github.com/puma/puma/pull/2079/files) proposed by [Kamil Trzcinski](https://gitlab.com/ayufan) was to make Puma inject a minimal amount of latency between requests if the worker is already processing requests. This would allow other workers (that are idle) to accept socket much faster than our worker that is already processing other traffic.\n\nYou can read more details about the discovery and research [here](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8334#note_247859173).\n\n## Our results\n\nOnce we deployed Puma to our entire web fleet we observed a drop in memory usage from 1.28T to approximately 800GB (approximately a 37% drop) while our request queuing, request duration and CPU usage all remained roughly the same.\n\nMore details and graphs can be found [here](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/1684#note_291225063). \n\nPuma is now on by default for all GitLab customers in the [GitLab 13.0 release](/releases/2020/05/22/gitlab-13-0-released/).\n\n## What's next\n\nWe want to review our infrastructure needs! The efficiency gains brought about by deploying Puma will allow us to re-examine the memory needs of Rails nodes in production. \n\nAlso, Puma has enabled us to continue to pursue our efforts to enable [real time editing](https://gitlab.com/groups/gitlab-org/-/epics/52). \n\n**More about GitLab's infrastructure:**\n\n[How we scaled Sidekiq](/blog/scaling-our-use-of-sidekiq/)\n\n[Make your pipelines more flexible](/blog/directed-acyclic-graph/)\n\n[The inside scoop on the building of our Status Page](/blog/how-we-built-status-page-mvc/)\n\nCover image by [John Moeses Bauan](https://unsplash.com/@johnmoeses) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[680,9,2018],{"slug":4745,"featured":6,"template":683},"migrating-to-puma-on-gitlab","content:en-us:blog:migrating-to-puma-on-gitlab.yml","Migrating To Puma On Gitlab","en-us/blog/migrating-to-puma-on-gitlab.yml","en-us/blog/migrating-to-puma-on-gitlab",{"_path":4751,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4752,"content":4757,"config":4762,"_id":4764,"_type":13,"title":4765,"_source":15,"_file":4766,"_stem":4767,"_extension":18},"/en-us/blog/ml-experiment-sql",{"title":4753,"description":4754,"ogTitle":4753,"ogDescription":4754,"noIndex":6,"ogImage":906,"ogUrl":4755,"ogSiteName":670,"ogType":671,"canonicalUrls":4755,"schema":4756},"ML experiment: Writing SQL is about to get a lot easier","Learn how GitLab is experimenting with ML-powered product features in this third installment of our ongoing AI/ML in DevSecOps series.","https://about.gitlab.com/blog/ml-experiment-sql","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Writing SQL is about to get a lot easier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2023-03-30\",\n      }",{"title":4753,"description":4754,"authors":4758,"heroImage":906,"date":4759,"body":4760,"category":806,"tags":4761},[2333],"2023-03-30","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nSQL, the structured query language, has long been the backbone of data analysis and manipulation. But let's face it, not everyone is an SQL wizard. For many, writing even a simple SQL query can be a daunting task, let alone tackling more advanced queries. Even experienced data analysts spend lots of time and effort writing and debugging complex queries just to answer simple business intelligence questions.\n\nWith the recent advancements in AI and natural language processing, it's now possible for AI models to generate SQL code from simple English language queries. This means that even people without a deep understanding of SQL can generate complex queries to analyze their data. This technology not only improves accessibility but can also save valuable time and effort for data analysts.\n\n## AI-assisted SQL generation\nAt GitLab, we’re experimenting with AI-assisted SQL generation in our [Product Analytics group](https://docs.gitlab.com/ee/user/product_analytics/). This area is focused on helping users understand and gain insights from usage patterns. GitLab Product Analytics can track events within your project applications, which enables you to explore your data and generate dashboards with interactive graphs and charts. You can use our visual designer or YAML to define them, and we envision it becoming even easier with AI assistance. You can learn more about our Product Analytics plans in our [sneak peek blog post](/blog/introducing-product-analytics-in-gitlab/).\n\nIn a simple experiment, our own [Tim Zallmann](https://gitlab.com/timzallmann), Senior Director of Engineering, prototyped leveraging AI-generated queries from simple natural language parsing. The results quickly showcase how powerful using natural language can be to help generate the SQL to populate the Product Analytics dashboards. \n\n![Animated gif image of SQL generation](https://about.gitlab.com/images/blogimages/sql-query-generation-lg.gif){: .shadow}\n\nAbove, you can see an example of how we're using natural language to generate SQL queries to power dashboard charts and graphs. You can watch the full demo in the video below. \n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/q3HZy0P0ugw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Iterating on AI/ML features\nWhile just an experiment today, we are iterating on how to effectively bring features like this to our customers. This experiment is just the start of many ways we’re looking to infuse GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI Assisted features. We’ll be sharing more of these demos in this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[851,701,9,786],{"slug":4763,"featured":6,"template":683},"ml-experiment-sql","content:en-us:blog:ml-experiment-sql.yml","Ml Experiment Sql","en-us/blog/ml-experiment-sql.yml","en-us/blog/ml-experiment-sql",{"_path":4769,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4770,"content":4776,"config":4782,"_id":4784,"_type":13,"title":4785,"_source":15,"_file":4786,"_stem":4787,"_extension":18},"/en-us/blog/mobile-devops-with-gitlab-part-2",{"title":4771,"description":4772,"ogTitle":4771,"ogDescription":4772,"noIndex":6,"ogImage":4773,"ogUrl":4774,"ogSiteName":670,"ogType":671,"canonicalUrls":4774,"schema":4775},"Mobile DevOps with GitLab, Part 2 - Code signing for Android with GitLab","This second part of our tutorial series shows how to use Project-level Secure Files to sign an Android application.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668592/Blog/Hero%20Images/teddy-gr--adWwTRAm1g-unsplash.jpg","https://about.gitlab.com/blog/mobile-devops-with-gitlab-part-2","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Mobile DevOps with GitLab, Part 2 - Code signing for Android with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Darby Frey\"}],\n        \"datePublished\": \"2022-09-28\",\n      }",{"title":4771,"description":4772,"authors":4777,"heroImage":4773,"date":4779,"body":4780,"category":1513,"tags":4781},[4778],"Darby Frey","2022-09-28","\n\nIn Part 1 of this tutorial series, we talked about a new feature in GitLab called [Project-level Secure Files](/blog/mobile-devops-with-gitlab-part-1/). With Project-level Secure Files, you can securely store your build keys as part of your project in GitLab, and avoid [some](https://www.reddit.com/r/androiddev/comments/a4ydhj/how_to_update_app_when_lost_keystore_file/) [painful](https://www.reddit.com/r/gamemaker/comments/v98den/lost_keystore_for_publishing_to_google_play_store/) [problems](https://www.reddit.com/r/androiddev/comments/95oa55/is_there_anyway_to_update_my_app_after_having/) caused by lost keystore files.\n\nIn this blog post, I'll show you how to create a Keystore file and use it to sign an Android application. Then I'll show you how to quickly create a CI pipeline in GitLab using Project-level Secure Files.\n\n## Generate a private signing key\n\nThe first thing you'll need is a Keystore file. This file is used to securely sign the application. You can generate a Keystore file from your machine by running the following command:\n\n```\nkeytool -genkey -v -keystore release-keystore.jks -alias release -keyalg RSA -keysize 2048 -validity 10000\n```\n\nDuring this process, you'll be asked to create a new password for the Keystore file and provide some information about you and your organization. See the example below:\n\n![Generate Android Keystore](https://about.gitlab.com/images/blogimages/2022-09-19-mobile-devops-with-gitlab-part-2-code-signing-for-android-with-gitlab/generate-keystore.png)\n\n\n## Configure your application\n\nThe next step is to set some environment variables and update build.gradle to add the new signing configuration. First, set the following environment variables in either a .env file or in the shell via export.\n\n* `ANDROID_KEY_ALIAS` is the alias you gave for the key in the keytool command above. In this example the value is release.\n* `ANDROID_KEYSTORE_PASSWORD` is the new password you supplied to the keytool command above.\n* `ANDROID_KEY_STOREFILE` is the path to the new keystore file you just created. In this example we're using `../release-keystore.jks`.\n\nWith the environment variables set, the next step is to update the build configuration to use the new Keystore in the build process. In the `app/build.gradle` file add the following configuration inside the Android block for the release signing config.\n\n```\nandroid {\n    ...\n    defaultConfig { ... }\n    signingConfigs {\n        release {\n           storeFile file(System.getenv('ANDROID_KEY_STOREFILE'))\n           storePassword System.getenv('ANDROID_KEYSTORE_PASSWORD')\n           keyAlias System.getenv('ANDROID_KEY_ALIAS')\n           keyPassword System.getenv('ANDROID_KEYSTORE_PASSWORD')\n        }\n    }\n    buildTypes {\n        release {\n            ...\n            signingConfig signingConfigs.release\n        }\n    }\n}\n```\n\nSave these changes to the `app/build.gradle file`, and run the build locally to ensure everything works. Use the following command to run the build:\n\n```\n./gradlew assembleRelease\n```\n\nIf everything worked you'll see a message saying **BUILD SUCCESSFUL**.\n\n## Configure project\n\nWith the build running locally, it takes just a couple of steps to get it running in GitLab [CI](/topics/ci-cd/). The first step is to upload your Keystore file in GitLab. \n\n1. On the top bar, select **Menu > Projects** and find your project.\n2. On the left sidebar, select **Settings > CI/CD**.\n3. In the **Secure Files** section, select **Expand**.\n4. Select **Upload File**.\n5. Find the file to upload, select **Open**, and the file upload begins immediately. The file shows up in the list when the upload is complete.\n\n![Upload Secure File](https://about.gitlab.com/images/blogimages/2022-09-19-mobile-devops-with-gitlab-part-2-code-signing-for-android-with-gitlab/upload-secure-file.png)\n\n![List Secure Files](https://about.gitlab.com/images/blogimages/2022-09-19-mobile-devops-with-gitlab-part-2-code-signing-for-android-with-gitlab/list-secure-files.png)\n\nThe next step is to set the CI variables in your project. \n\n1. On the top bar, select **Menu > Projects** and find your project.\n2. On the left sidebar, select **Settings > CI/CD**.\n3. In the **Variables** section, select **Expand**.\n4. Create entries for the three environment variables set earlier: `ANDROID_KEY_ALIAS`, `ANDROID_KEY_STOREFILE`, `ANDROID_KEYSTORE_PASSWORD`.\n\n![List Secure Files](https://about.gitlab.com/images/blogimages/2022-09-19-mobile-devops-with-gitlab-part-2-code-signing-for-android-with-gitlab/list-ci-variables.png)\n\n## CI/CD pipelines\n\nOnce the project is configured, the final step is to create the build configuration in the `.gitlab-ci.yml` file. Below is a sample file.\n\n```\nstages:\n  - build\n\nbuild_android:\n  image: fabernovel/android:api-31-v1.6.1\n  stage: build\n  variables:\n    SECURE_FILES_DOWNLOAD_PATH: './'\n  script:\n    - apt update && apt install -y curl\n    - curl --silent \"https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer\" | bash\n    - ./gradlew assembleRelease\n  artifacts:\n    paths:\n      - app/build/outputs/apk/release\n```\n\nA few interesting bits from this configuration:\n\n1. Image: [https://github.com/faberNovel/docker-android](https://github.com/faberNovel/docker-android) provides a collection of prebuilt Docker images that work great for CI systems. Find the right version for your project in Docker Hub [https://hub.docker.com/r/fabernovel/android/tags](https://hub.docker.com/r/fabernovel/android/tags). \n2. Script: Depending on the image, you may need to install curl; the first line of the example script installs curl to be used in the second line to download and execute the [download-secure-files](https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files) tool.\n3. Variables: `SECURE_FILES_DOWNLOAD_PATH` tells [download-secure-files](https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files) where to download the Keystore file.\n4. Artifacts: Make the build output available to be downloaded from the CI job, or used in subsequent jobs in the pipeline.\n\nCommit the changes to your `.gitlab-ci.yml` file and after you push the changes to GitLab the build will start.\n\nTake a look at [this branch in the sample project](https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/android_demo/-/tree/basic_build) for reference.\n\nGive it a try, and let us know what you think in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/362407). Then, check out Part 3, which deals with [code signing for iOS](/blog/mobile-devops-with-gitlab-part-3-code-signing-for-ios-with-gitlab-and-fastlane/). \n\n\n\n_Cover image by  \u003Ca href=\"https://unsplash.com/@teddygr?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Teddy GR\u003C/a> on \u003Ca href=\"https://unsplash.com/s/photos/google-phone?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>_\n",[851,1164,9,108],{"slug":4783,"featured":6,"template":683},"mobile-devops-with-gitlab-part-2","content:en-us:blog:mobile-devops-with-gitlab-part-2.yml","Mobile Devops With Gitlab Part 2","en-us/blog/mobile-devops-with-gitlab-part-2.yml","en-us/blog/mobile-devops-with-gitlab-part-2",{"_path":4789,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4790,"content":4796,"config":4801,"_id":4803,"_type":13,"title":4804,"_source":15,"_file":4805,"_stem":4806,"_extension":18},"/en-us/blog/mobile-static-application-security-testing-for-android",{"title":4791,"description":4792,"ogTitle":4791,"ogDescription":4792,"noIndex":6,"ogImage":4793,"ogUrl":4794,"ogSiteName":670,"ogType":671,"canonicalUrls":4794,"schema":4795},"Android App Security Testing with SAST","Learn how to secure your Android application with Static Application Security Testing.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666816/Blog/Hero%20Images/security-cover.png","https://about.gitlab.com/blog/mobile-static-application-security-testing-for-android","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Android App Security Testing with SAST\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2020-12-16\",\n      }",{"title":4791,"description":4792,"authors":4797,"heroImage":4793,"date":4798,"body":4799,"category":704,"tags":4800},[2234],"2020-12-16","\n\nAt GitLab, everyone can contribute! [GitLab 13.5](/releases/2020/10/22/gitlab-13-5-released/) included an [integration for Mobile Static\nApplication Security Testing (SAST)](/releases/2020/10/22/gitlab-13-5-released/#sast-support-for-ios-and-android-mobile-apps) from one of our customers. For their contribution, the \n[H-E-B Digital](https://digital.heb.com/) team were [October 2020's MVP](/releases/2020/10/22/gitlab-13-5-released/#mvp).\n\nTheir contribution enables SAST for mobile applications. This includes iOS apps written in Objective-C\nand Swift as well as Android apps written in Java and Kotlin. \n\nThis blog post will go over how Mobile SAST works on Android.\n\n## Static Application Security Testing\n\n[Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/) analyzes source code for known vulnerabilities.\nSAST is used to detect potentially dangerous attributes in a class, or unsafe code that can\nlead to unintended code execution, as well as other issues such as SQL Injection. More information\non SAST can be seen in the [OWASP Documentation](https://owasp.org/www-community/controls/Static_Code_Analysis).\n\nHere is a video which goes over [setting up SAST for Mobile](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features), as well as a sample application\nyou can use to get started:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/v0GhEHZWtdw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn a nutshell, after the scanner has been configured, whenever an MR is created the\nscanner runs on the application source code and looks for patterns to determine if\nthat code is vulnerable. This is covered below.\n\nInitially this analyzer supports source code analysis but we intend to [expand support for binary\nscanning](https://gitlab.com/gitlab-org/gitlab/-/issues/269915) of .ipa and .apk files in the near future.\n\n## Understanding security rules\n\nSAST for mobile applications uses the Mobile Security Framework (MobSF) to scan source code. MobSF\nuses certain rules in order to determine if an application is vulnerable. The rules used to scan\nmobile applications can be seen in their [rules file](https://github.com/MobSF/Mobile-Security-Framework-MobSF/tree/master/StaticAnalyzer/views/android/rules).\nThese rules use [regex](https://en.wikipedia.org/wiki/Regular_expression) in order to find vulnerabilities in the static code.\n \nYou can also [contribute your own rules](https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/master/.github/CONTRIBUTING.md) if you have thoghts on enhancements.\nI made a small change to [enable a regex to work on Kotlin](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/1611).\nNot only can everyone contribute at GitLab, we encourage team members to contribute to other open source projects.\n\nNote: You will have to test your changes before they can be approved. In order to do this, you must [install\nyour branch as seen here](https://mobsf.github.io/docs/#/installation).\n\n## Adding your own scanners\n\nGitLab allows for lots of extensibility. Using our [integration guidance](https://docs.gitlab.com/ee/development/integrations/secure.html), you can bring your own scanners into the\nmerge request pipeline and the security dashboards. This was done for MobSF SAST, as well as the [WhiteSource\nDependency Scanner](/blog/whitesource-for-dependency-scanning/).\n\nI hope you enjoyed this blog post. Now you can start making your Android applications more secure.\nYou can reach out on Twitter and share your thoughts with us [@GitLab](https://twitter.com/gitlab)!\n",[704,851,9,230,1187],{"slug":4802,"featured":6,"template":683},"mobile-static-application-security-testing-for-android","content:en-us:blog:mobile-static-application-security-testing-for-android.yml","Mobile Static Application Security Testing For Android","en-us/blog/mobile-static-application-security-testing-for-android.yml","en-us/blog/mobile-static-application-security-testing-for-android",{"_path":4808,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4809,"content":4815,"config":4821,"_id":4823,"_type":13,"title":4824,"_source":15,"_file":4825,"_stem":4826,"_extension":18},"/en-us/blog/monitor-application-performance-with-distributed-tracing",{"title":4810,"description":4811,"ogTitle":4810,"ogDescription":4811,"noIndex":6,"ogImage":4812,"ogUrl":4813,"ogSiteName":670,"ogType":671,"canonicalUrls":4813,"schema":4814},"Monitor application performance with Distributed Tracing","Learn how Distributed Tracing helps troubleshoot application performance issues by providing end-to-end visibility and seamless collaboration across your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098000/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5x6kH5vwjz8cwKgSBh1w11_1750098000511.png","https://about.gitlab.com/blog/monitor-application-performance-with-distributed-tracing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Monitor application performance with Distributed Tracing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sacha Guyon\"}],\n        \"datePublished\": \"2024-06-13\",\n      }",{"title":4810,"description":4811,"authors":4816,"heroImage":4812,"date":4818,"body":4819,"category":701,"tags":4820},[4817],"Sacha Guyon","2024-06-13","Downtime due to application defects or performance issues can have devastating financial consequences for businesses. An hour of downtime is estimated to cost firms $301,000 or more, according to [Information Technology Intelligence Consulting's 2022 Global Server Hardware and Server OS Reliability Survey](https://itic-corp.com/server-and-application-by-the-numbers-understanding-the-nines/). These issues often originate from human-introduced changes, such as code or configuration changes.\n\nResolving such incidents requires development and operations teams to collaborate closely, investigating the various components of the system to find the root cause change, and promptly restore the system back to normal operation. However, these teams commonly use separate tools to build, manage, and monitor their application services and infrastructure. This approach leads to siloed data, fragmented communication, and inefficient context switching, increasing the time spent to detect and resolve incidents.\n\nGitLab aims to address this challenge by combining software delivery and monitoring functionalities within the same platform. Last year, we released [Error Tracking](https://docs.gitlab.com/ee/operations/error_tracking.html) as a general availability feature in [GitLab 16.0](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#error-tracking-is-now-generally-available). Now, we're excited to announce the [Beta release of Distributed Tracing](https://docs.gitlab.com/ee/operations/tracing), the next step toward a comprehensive observability offering seamlessly integrated into the GitLab DevSecOps platform.\n\n## A new era of efficiency: GitLab Observability\n\nGitLab Observability empowers development and operations teams to visualize and analyze errors, traces, logs, and metrics from their applications and infrastructure. By integrating application performance monitoring into existing software delivery workflows, context switching is minimized and productivity is increased, keeping teams focused and collaborative on a unified platform.\n\nAdditionally, GitLab Observability bridges the gap between development and operations by providing insights into application performance in production. This enhances transparency, information sharing, and communication between teams. Consequently, they can detect and resolve bugs and performance issues arising from new code or configuration changes sooner and more effectively, preventing those issues from escalating into major incidents that could negatively impact the business.\n\n## What is Distributed Tracing?\n\nWith Distributed Tracing, engineers can identify the source of application performance issues. A trace represents a single user request that moves through different services and systems. Engineers are able to analyze the timing of each operation and any errors as they occur.\n\nEach trace is composed of one or more spans, which represent individual operations or units of work. Spans contain metadata like the name, timestamps, status, and relevant tags or logs. By examining the relationships between spans, developers can understand the request flow, identify performance bottlenecks, and pinpoint issues.\n\nDistributed Tracing is especially valuable for [microservices architecture](https://about.gitlab.com/topics/microservices/), where a single request may involve numerous service calls across a complex system. Tracing provides visibility into this interaction, empowering teams to quickly diagnose and resolve problems.\n\n![tracing example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098009139.png)\n\nFor example, this trace illustrates a how a user request flows through difference services to fetch product recommendations on a e-commerce website:\n\n- `User Action`: This indicates the user's initial action, such as clicking a button to request product recommendations on a product page.\n-  `Web front-end`: The web front-end sends a request to the recommendation service to retrieve product recommendations.\n- `Recommendation service`: The request from the web front-end is handled by the recommendation service, which processes the request to generate a list of recommended products.\n- `Catalog service`: The recommendation service calls the catalog service to fetch details of the recommended products. An alert icon suggests an issue or delay at this stage, such as a slow response or error in fetching product details.\n- `Database`: The catalog service queries the database to retrieve the actual product details. This span shows the SQL query in the database.\n\nBy visualizing this end-to-end trace, developers can identify performance issues – here, an error in the Catalog service – and quickly diagnose and resolve issues across the distributed system.\n\n![End-to-end trace](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098009140.png)\n\n## How Distributed Tracing works\n\nHere is a breakdown of how Distributed Tracing works.\n\n### Collect data from any application with OpenTelemetry\n\nTraces and spans can be collected using [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/), an open-source observability framework that supports a wide array of SDKs and libraries across [major programming languages and frameworks](https://opentelemetry.io/docs/languages/). This framework offers a vendor-neutral approach for collecting and exporting telemetry data, enabling developers to avoid vendor lock-in and choose the tools that best fit their needs.\n\nThis means that if you are already using OpenTelemetry with another vendor, you can send data to us simply by adding our endpoint to your configuration file, making it very easy to try out our features!\n\n![Distributed tracing workflow diagram](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098009141.png)\n\n### Ingest and retain data at scale with fast, real-time queries\n\nObservability requires the storage and querying of vast amounts of data while maintaining low latency for real-time analytics. To meet these needs, we developed a horizontally scalable, long-term storage solution using ClickHouse and Kubernetes, based on our [acquisition of Opstrace](https://about.gitlab.com/press/releases/2021-12-14-gitlab-acquires-opstrace-to-expand-its-devops-platform-with-open-source-observability-solution/). This [open-source platform](https://gitlab.com/gitlab-org/opstrace/opstrace) ensures rapid query performance and enterprise-grade scalability, all while minimizing costs.\n\n### Explore and analyze traces effortlessly\nAn advanced, native-level user interface is crucial for effective data exploration. We built such an interface from the ground up, starting with our Trace Explorer, which allows users to examine traces and understand their application's performance:\n- __Advanced filtering:__ Filter by services, operation names, status, and time range. Autocomplete helps simplify querying.\n- __Error highlighting:__ Easily identify error spans in search results.\n- __RED metrics:__ Visualize the Requests rate, Errors rate, and average Duration as a time-series chart for any search in real-time.\n- __Timeline view:__ Individual traces are displayed as a waterfall diagram, providing a complete view of a request distributed across different services and operations.\n- __Historical data:__ Users can query traces up to 30 days in the past.\n\n![Distributed Tracing - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098009141.png)\n\n## How we use Distributed Tracing at GitLab\n[Dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is a core value and practice at GitLab. We've been already using early versions of Distributed Tracing for our engineering and operations needs. Here are a couple example use cases from our teams:\n\n### 1. Debug errors and performance Issues in GitLab Agent for Kubernetes\n\nThe [Environments group](https://handbook.gitlab.com/handbook/engineering/development/ops/deploy/environments/) has been using Distributed Tracing to troubleshoot and resolve issues with the [GitLab Agent for Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent), such as timeouts or high latency issues. The Trace List and Trace Timeline views offer valuable insights for the team to address these concerns efficiently. These traces are shared and discussed in the [related GitLab issues](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/386#note_1576431796), where the team collaborates on resolution.\n\n\u003Ccenter>\u003Ci>\"The Distributed Tracing feature has been invaluable in pinpointing where latency issues are occurring, allowing us to focus on the root cause and resolve it faster.\" - Mikhail, GitLab Engineer\u003C/i>\u003C/center>\u003Cp>\n\n### 2. Optimize GitLab’s build pipeline duration by identifying performance bottlenecks\n\nSlow deployments of GitLab source code can significantly impact the productivity of the whole company, as well as our compute spending. Our main repository runs [over 100,000 pipelines every month](https://gitlab.com/gitlab-org/gitlab/-/pipelines/charts). If the time it takes for these pipelines to run changes by just one minute, it can add or remove more than 2,000 hours of work time. That's 87 extra days!\n\nTo optimize pipeline execution time, GitLab's [platform engineering teams](https://handbook.gitlab.com/handbook/engineering/infrastructure/) utilize a [custom-built tool](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace) that converts GitLab deployment pipelines into traces.\n\nThe Trace Timeline view allows them to visualize the detailed execution timeline of complex pipelines and pinpoint which jobs are part of the critical path and slowing down the entire process. By identifying these bottlenecks, they can optimize job execution – for example, making the job fail faster, or running more jobs in parallel – to improve overall pipeline efficiency.\n\n![Distributed Tracing - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098009143.gif)\n\n[The script is freely available](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace), so you can adapt it for your own pipelines.\n\n\u003Ccenter>\u003Ci>\"Using Distributed Tracing for our deployment pipelines has been a game-changer. It's helped us quickly identify and eliminate bottlenecks, significantly reducing our deployment times.\"- Reuben, GitLab Engineer\u003C/i>\u003C/center>\u003Cp>\n\n## What's coming next?\n\nThis release is just the start: In the next few months, we'll continue to expand our observability and monitoring features with the upcoming Metrics and Logging releases. Check out [our Observability direction page](https://about.gitlab.com/direction/monitor/platform-insights/) for more info, and keep an eye out for updates!\n\n## Join the private Beta\n\nInterested in being part of this exciting journey? [Sign up to enroll in the private Beta](https://docs.gitlab.com/operations/observability/) and try out our features. Your contribution can help shape the future of observability within GitLab, ensuring our tools are perfectly aligned with your needs and challenges.\n\n> Help shape the future of GitLab Observability. [Join the Distributed Tracing Beta.](https://docs.gitlab.com/operations/observability/)",[2018,9,678,478,829],{"slug":4822,"featured":90,"template":683},"monitor-application-performance-with-distributed-tracing","content:en-us:blog:monitor-application-performance-with-distributed-tracing.yml","Monitor Application Performance With Distributed Tracing","en-us/blog/monitor-application-performance-with-distributed-tracing.yml","en-us/blog/monitor-application-performance-with-distributed-tracing",{"_path":4828,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4829,"content":4835,"config":4842,"_id":4844,"_type":13,"title":4845,"_source":15,"_file":4846,"_stem":4847,"_extension":18},"/en-us/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated",{"title":4830,"description":4831,"ogTitle":4830,"ogDescription":4831,"noIndex":6,"ogImage":4832,"ogUrl":4833,"ogSiteName":670,"ogType":671,"canonicalUrls":4833,"schema":4834},"More granular product usage insights for GitLab Self-Managed and Dedicated","Learn how event-level data helps GitLab improve the DevSecOps platform. Opt-out option is always available.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099221/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750099221690.png","https://about.gitlab.com/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"More granular product usage insights for GitLab Self-Managed and Dedicated\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tanuja Jayarama Raju\"}],\n        \"datePublished\": \"2025-03-26\",\n      }",{"title":4830,"description":4831,"authors":4836,"heroImage":4832,"date":4838,"body":4839,"category":701,"tags":4840,"updatedDate":4841},[4837],"Tanuja Jayarama Raju","2025-03-26","In GitLab 18.0, we plan to enable event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances – while ensuring privacy, transparency, and customer control every step of the way.\n\nWe know data powers valuable insights to help you understand the performance of your DevSecOps practices. Similarly, platform usage data enables us to prioritize the investments and product improvements that drive more impact for you.\t\n\nHistorically, we’ve collected both event and aggregate product usage data from GitLab.com. However, for GitLab Self-Managed and Dedicated instances, the absence of event data has required the GitLab Customer Success team to rely on manual data extraction methods to gather key insights, including job runtimes, runner usage for cost optimization, pipeline success rates, and deployment frequency for assessing DevSecOps maturity. Access to event-level data reduces the need for workarounds and enables more efficient reporting and optimizations. \n\n**Note: Throughout this blog, when we discuss event collection, we are exclusively referring to the collection of events for all features except those included in GitLab Duo. For more details, please refer to our [Customer Product Usage Information page](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/).**\n\n## Understanding event-level data\n\nEvent-level data tracks product usage interactions within the GitLab platform, such as initiating CI/CD pipelines, merging a merge request, triggering a webhook, or creating a new issue. User identifiers are pseudonymized to protect privacy, and GitLab does not undertake any processes to re-identify or associate the metrics with individual users. Importantly, event-level data does not include source code or other customer-created content stored within GitLab. To learn more, visit our [Customer Product Usage Information page](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/) and [event data documentation](https://docs.gitlab.com/administration/settings/event_data/).\n\nHere is an example of a data sample we collect:\n\n![event-level data - code example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099231/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099230972.png)\n\n## How event-level data collection benefits you\n\nEvent-level data offers a wealth of insights beyond what aggregated data can provide. It enables slicing and aggregating pseudonymized system instrumentation to identify trends, highlight unused or underused areas, and signal product improvements. By analyzing usage patterns in context, we can understand which features are used, how, and in what sequence. This visibility uncovers bottlenecks and optimization opportunities that aggregated data would miss.\n\n* **In-depth feature usage analysis**  \n  Rather than just knowing which features are used weekly or monthly, event-level data provides a clearer picture of how users experience GitLab and the frequency of their usage. This enables us to gain a deeper understanding of user behavior and highlights areas for improvement.  \n* **Trend discovery**  \n  Event-level data helps identify trends in GitLab adoption that can’t be seen with rolling aggregates. With these insights, the GitLab Customer Success team can help customers make more informed decisions on feature adoption and usage, improving overall efficiency.  \n* **Smarter product improvements**  \n  Event-level data gives GitLab’s Product team a clearer picture of real-world customer needs. By analyzing usage patterns, product improvements can be aligned with customer priorities, leading to continuous enhancements that make GitLab more powerful, efficient, and user-friendly.  \n* **Custom insights for your use case**  \n  Event-level data will enable GitLab Customer Success to provide tailored insights based on your organization's overall product usage without identifying individual users. This flexibility helps our teams provide recommendations that address your unique needs and challenges.\n\n## You stay in control of your data\n\n![event-level data - screen of choices](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099231/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-04-02_at_12.14.12_PM_aHR0cHM6_1750099230972.png)\n\nWe’re committed to rolling this out with a strong focus on privacy. Here’s what we’re doing to ensure transparency and choice:\n\n✅ **Pre-deployment early opt-out** – Data sharing can be disabled by instance admins in the 17.11 release before event collection begins in 18.0. The pre-deployment early opt-out option will remain available after 18.0; just upgrade to 17.11 first and disable data sharing.\n\n✅ **Proactive communication** – Updates on the progress of this initiative shared via blog posts, emails to GitLab admins, and updates through your GitLab account team.\n\n ✅ **No third-party collectors** - GitLab’s event-level instrumentation will not use any third-party collectors; it’s built and operated by GitLab, and events are sent directly to GitLab-managed environments, similar to [Service Ping](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/#service-ping-formerly-known-as-usage-ping).\n\n✅ **Detailed documentation** – Detailed documentation is available [here](https://docs.gitlab.com/administration/settings/event_data/), and a list of FAQs is available [here](http://handbook.gitlab.com/handbook/legal/privacy/product-usage-events-faq/).\n\n✅ **De-identification approach** – We will continue to apply aggregation and/or pseudonymization to any event-level data collected from Self-Managed and Dedicated.\n\n## What’s next\n\n* **Product enhancements (coming up!)** - Improvements to GitLab user experiences and adoption insights made possible by event-level data.\n\n*Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*",[701,478,9],"2025-05-14",{"slug":4843,"featured":90,"template":683},"more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated","content:en-us:blog:more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated.yml","More Granular Product Usage Insights For Gitlab Self Managed And Dedicated","en-us/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated.yml","en-us/blog/more-granular-product-usage-insights-for-gitlab-self-managed-and-dedicated",{"_path":4849,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4850,"content":4856,"config":4861,"_id":4863,"_type":13,"title":4864,"_source":15,"_file":4865,"_stem":4866,"_extension":18},"/en-us/blog/mvcs-with-big-results",{"title":4851,"description":4852,"ogTitle":4851,"ogDescription":4852,"noIndex":6,"ogImage":4853,"ogUrl":4854,"ogSiteName":670,"ogType":671,"canonicalUrls":4854,"schema":4855},"4 Examples of MVCs with big results","Small change, big impact. Here are four recent tweaks to GitLab which exemplify our value of iteration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678764/Blog/Hero%20Images/mvcs-big-results.jpg","https://about.gitlab.com/blog/mvcs-with-big-results","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 Examples of MVCs with big results\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n        \"datePublished\": \"2018-09-07\",\n      }",{"title":4851,"description":4852,"authors":4857,"heroImage":4853,"date":4858,"body":4859,"category":298,"tags":4860},[1550],"2018-09-07","\nIteration is [one of our values](https://handbook.gitlab.com/handbook/values/#iteration), and it's often the hardest to stick to. It’s difficult to determine the smallest feature or update that will still bring additional value to users. The benefit is that we can ship quickly and get feedback from GitLab users within days or weeks, instead of months or quarters.\n\nAt GitLab we practice iteration by shipping Minimally Viable Changes (MVCs). This can be a new feature scoped to a small functionality, or incremental improvements on it thereafter. Read more about MVC in our [Product handbook](/handbook/product/product-principles/#the-minimal-viable-change-mvc).\n\nDespite being small, these new features often nonetheless have a big impact. Here are some of our recent MVCs that did just that:\n\n## 1. Function: Assignee lists and milestone lists\n\nIntroduced in 11.1, [issue board assignee lists](/releases/2018/06/22/gitlab-11-0-released/#issue-board-assignee-lists) offer a way to monitor team bandwidth right within your issue board, by showing all issues assigned to a specific user. See [4 ways to use GitLab Issue Boards](/blog/4-ways-to-use-gitlab-issue-boards/#3-team-visibility-with-assignee-lists) for more details, and [check out the documentation for assignee lists here](https://docs.gitlab.com/ee/user/project/issue_board.html#assignee-lists).\n\nIn 11.2, we added [milestone lists](/releases/2018/08/22/gitlab-11-2-released/#issue-board-milestone-lists) to allow you to view all issues assigned to a specific milestone. With this visibility, you can move issues across different milestones easily to balance [issue weight](/releases/2018/08/22/gitlab-11-2-released/#summed-weights-in-issue-board-list). View [the documentation for milestone lists here](https://docs.gitlab.com/ee/user/project/issue_board.html#milestone-lists).\n\n## 2. Design: Merge request widget info and pipeline sections redesign\n\nSometimes it's not new functionality that makes a big difference, but just changing how you view it. In 11.1, we [tweaked the design of the information and pipeline sections](/releases/2018/07/22/gitlab-11-1-released/#merge-request-widget-info-and-pipeline-sections-redesign) in a [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/), making them easier to digest.\n\n![Merge request redesign](https://about.gitlab.com/images/11_1/mr-widget-info-pipeline.png){: .shadow.medium.center}\n\n## 3. Navigation: Groups dropdown\n\nAlso in 11.1, we made it easier to switch between groups and avoid disruption to your workflow by adding a [dropdown to the groups link in the top navigation](/releases/2018/07/22/gitlab-11-1-released/#groups-dropdown-in-navigation). There's no need to navigate away from your work, and your frequently visited groups are handily displayed for quick access.\n\n## 4. Shortcut: Confidential issue quick action\n\n[Quick actions](https://docs.gitlab.com/ee/user/project/quick_actions.html) make your GitLab life easier and are easy to contribute! As of 11.1 you can quickly and easily [mark an issue confidential right from the comment field](/releases/2018/07/22/gitlab-11-1-released/#confidential-issue-quick-action), thanks to a community contribution.\n\nInspired to contribute an MVC yourself? Find out [how to start contributing to GitLab](/community/contribute/). You can also check out some more [MVCs coming up in 11.3](/blog/epics-roadmap/).\n\nPhoto by [Ravali Yan](https://unsplash.com/photos/fleZeABaSWY?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/upwards?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,680,1187],{"slug":4862,"featured":6,"template":683},"mvcs-with-big-results","content:en-us:blog:mvcs-with-big-results.yml","Mvcs With Big Results","en-us/blog/mvcs-with-big-results.yml","en-us/blog/mvcs-with-big-results",{"_path":4868,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4869,"content":4874,"config":4881,"_id":4883,"_type":13,"title":4884,"_source":15,"_file":4885,"_stem":4886,"_extension":18},"/en-us/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance",{"title":4870,"description":4871,"ogTitle":4870,"ogDescription":4871,"noIndex":6,"ogImage":3028,"ogUrl":4872,"ogSiteName":670,"ogType":671,"canonicalUrls":4872,"schema":4873},"New CIS GitLab Benchmark scanner boosts security and compliance","GitLab's gitlabcis scanner determines level of compliance for GitLab projects. Learn how to install and use the tool with this tutorial, as well as what's on the roadmap.","https://about.gitlab.com/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New CIS GitLab Benchmark scanner boosts security and compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mitra Jozenazemian\"},{\"@type\":\"Person\",\"name\":\"Neil McDonald\"},{\"@type\":\"Person\",\"name\":\"Nate Rosandich\"}],\n        \"datePublished\": \"2024-10-29\",\n      }",{"title":4870,"description":4871,"authors":4875,"heroImage":3028,"date":699,"body":4879,"category":704,"tags":4880},[4876,4877,4878],"Mitra Jozenazemian","Neil McDonald","Nate Rosandich","GitLab's CIS Benchmark scanner, [gitlabcis](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis), is open source and available. The [Python](https://www.python.org/downloads/) CLI tool audits a GitLab project against the [Center for Internet Security (CIS) GitLab Benchmark](https://workbench.cisecurity.org/benchmarks/17538), and delivers [recommendations as code](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/gitlabcis/recommendations?ref_type=heads#recommendations) formatted in YAML.\n\nIn April, we introduced the [CIS GitLab Benchmark](https://about.gitlab.com/blog/gitlab-introduces-new-cis-benchmark-for-improved-security/) to improve security and offer hardening recommendations to GitLab's customers. [The benchmark is available for download](https://workbench.cisecurity.org/benchmarks/17538) from the CIS website.\n\nIn this article, you'll learn:\n* [How to install and use the gitlabcis scanner](#how-to-install-and-use-the-gitlabcis-scanner)\n* [gitlabcis scanner details](#gitlabcis-scanner-details)\n* [GitLab scanner and product roadmap](#gitlab-scanner-and-product-roadmap)\n\n## How to install and use the gitlabcis scanner\n\nYou can download and install the scanner using pip via [pypi](https://pypi.org/project/gitlabcis/), or download the source code from our [releases page](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/releases).\n\n```sh\npip install gitlabcis\n```\n\nThe scanner takes one positional argument (`URL`) and then options. The format is: `gitlabcis URL OPTIONS`\n\n```sh\n# example: generate a json report\ngitlabcis \\\n    https://gitlab.example.com/path/to/project \\\n    -o results.json \\\n    -f json\n```\n\nThe full command line options can be found in [the documentation](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/docs?ref_type=heads#gitlabcis-usage).\n\n![GitLab CIS Benchmark scanner](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675788/Blog/Content%20Images/Screenshot_2024-10-26_at_8.16.22_AM.png)\n\n## gitlabcis scanner details\n\nThe team extracted all of the recommendation controls from the [CIS GitLab Benchmark](https://workbench.cisecurity.org/benchmarks/17538) and created them in YAML to be used as [controls as code](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/gitlabcis/recommendations?ref_type=heads).\n\nEach control has its own [dedicated function](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/gitlabcis/benchmarks?ref_type=heads) to enhance readability. This also allows an individual to observe how the control performs its audit.\n\nAdditionally, certain control functions have limitations. We have identified each of these, which can be found in our [limitations document](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/docs/limitations.md?ref_type=heads).\n\nCurrently, the tool only accepts a _project URL_ input. It then only observes configuration at a _project_ level. It does however support administrative controls.\n\n* For example, the [1.1.2 - Code Tracing](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/gitlabcis/recommendations/source_code_1/code_changes_1_1/code_tracing.yml) control attempts to audit _\"... any change to code can be traced back to its associated task\"_.\n    * This can be achieved with crosslinking issues in merge requests.\n    * Merge requests can be found at a project level, group level, or event instance level.\n    * The scanner currently only checks _at the project level_.\n* See [our roadmap](#gitlab-scanner-and-product-roadmap), which aims to address this functionality gap.\n\n> Contribute to the [gitlabcis scanner](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/) project.\n\n## GitLab scanner and product roadmap\n\nThe creation of the scanner allowed us to contribute two features back into the product with the help of the community.\n\n* [Show crosslinked/related issues in merge requests via the API](https://gitlab.com/gitlab-org/gitlab/-/issues/461536)\n* [Groups API: Add Restrict group access by Domain](https://gitlab.com/gitlab-org/gitlab/-/issues/351494)\n\nWe want to augment the scanner to be able to accept instances or groups as input. For example, if you host GitLab at: [gitlab.example.com](http://gitlab.example.com), this could be used as an input to check at the instance level if you are compliant against the CIS GitLab Benchmark and the same for groups.\n\nAdditionally, certain controls can be set at the instance or group level and trickle down to the project level. There is work ongoing to include this functionality into the scanner. Check out the [epic](https://gitlab.com/groups/gitlab-org/govern/compliance/engineering/cis/-/epics/2) for more information\n\nOne important aspect is incorporating [this functionality into the GitLab product itself](https://gitlab.com/groups/gitlab-org/-/epics/7854). The GitLab compliance team is working on [incorporating the CIS GitLab Benchmark](https://gitlab.com/groups/gitlab-org/-/epics/13823) and other standards into the [Compliance Adherence Report](https://docs.gitlab.com/ee/user/compliance/compliance_center/). This will allow customers real-time reviews of instances, groups, and projects across a wide set of standards, not just CIS.\n\n> Learn more about the CIS GitLab Benchmark in our [public project](https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis).\n",[704,9,703],{"slug":4882,"featured":6,"template":683},"new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance","content:en-us:blog:new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance.yml","New Cis Gitlab Benchmark Scanner Boosts Security And Compliance","en-us/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance.yml","en-us/blog/new-cis-gitlab-benchmark-scanner-boosts-security-and-compliance",{"_path":4888,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4889,"content":4894,"config":4900,"_id":4902,"_type":13,"title":4903,"_source":15,"_file":4904,"_stem":4905,"_extension":18},"/en-us/blog/new-elasticsearch-version-requirements",{"title":4890,"description":4891,"ogTitle":4890,"ogDescription":4891,"noIndex":6,"ogImage":1622,"ogUrl":4892,"ogSiteName":670,"ogType":671,"canonicalUrls":4892,"schema":4893},"GitLab 11.5 adds Elasticsearch 6, removes ES 5.5 support","GitLab 11.5 will support Elasticsearch version 6 and 5.6, sunsetting support for versions 5.5 and earlier.","https://about.gitlab.com/blog/new-elasticsearch-version-requirements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab 11.5 to support Elasticsearch 6, sunset support for Elasticsearch 5.5\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mario de la Ossa\"}],\n        \"datePublished\": \"2018-11-16\",\n      }",{"title":4895,"description":4891,"authors":4896,"heroImage":1622,"date":4897,"body":4898,"category":849,"tags":4899},"GitLab 11.5 to support Elasticsearch 6, sunset support for Elasticsearch 5.5",[2213],"2018-11-16","\nIn Gitlab 11.5 (to be released on Nov. 22, 2018), GitLab's [Elasticsearch integration](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html)\nwill support Elasticsearch version 6, and will no longer support versions 5.5 or earlier.\nPlease make plans to upgrade Elasticsearch to version 5.6 or 6.x immediately before upgrading to GitLab 11.5. After you upgrade GitLab, you will also need\nto perform a [reindex](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html),\nas the changes required to support these Elasticsearch versions are incompatible with the indexes of previous versions.\n\nIn summary, starting with 11.5, GitLab will support:\n- Elasticsearch version 5.6\n- Elasticsearch version 6.x\n\nIf you are using GitLab.com, this does not impact you in any way. This is only relevant\nfor [self-managed GitLab](/pricing/#self-managed).\n{: .alert .alert-info}\n\nGitLab uses Elasticsearch for [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_search.html)\nand [Advanced Syntax Search](https://docs.gitlab.com/ee/user/search/advanced_search.html).\n\n## Why are we doing this?\n\nElasticsearch version 6 brings with it two large changes that were incompatible with the way we currently index:\n\n- The [removal of mapping types](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html).\n- Parent-child relationships are now established via a [`join` datatype](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/parent-join.html).\n\nWe'll go into some detail on how each of these changes affects GitLab.\n\n### Removal of mapping types\n\nIn Elasticsearch 6, all documents under the same index must be of the same 'type.' We need to keep all documents under the same index\nin order to be able to query based on project membership and permissions, so this change forced us to implement our own\n`type` field in order to still be able to query only a single type (for example, issues).\n\nThis removal of mapping types also affected [the way parent-child relationships work](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html#_parent_child_without_mapping_types).\n\n### `join` datatype\n\nWith the mapping type change comes a change to the way parent-child relationships\nare expressed. Elasticsearch 5.6 and 6.x have introduced a [`join` datatype](https://www.elastic.co/guide/en/elasticsearch/reference/6.0/parent-join.html)\nthat GitLab 11.5 puts to use. (As of 6.0, it is the required method for defining these relationships.)\n\nWhen using `join`, all insertions and deletions must be routed relative to their\nparent – which means we must send the parent's ID in the `routing` field. In 5.6,\nthis means that the `_parent` field is ignored, and in 6.x it is removed.\n\n### Why Elasticsearch 5.6 remains compatible\n\nAs noted in the [schedule for removal of mapping types](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/removal-of-types.html#_schedule_for_removal_of_mapping_types),\nversion 5.6 is the first Elasticsearch version where the `join` datatype is available, as well as the first version where `single_type`\nbehavior can be enabled.\n\nWe tested versions 5.5 and below, and unfortunately they have no support for `join` datatypes, so we need to end support for these versions as of GitLab 11.5.\n\nWe're especially looking forward to supporting Elasticsearch version 6 as it brings with it some great [improvements](https://www.elastic.co/blog/elasticsearch-6-0-0-released), including:\n\n- Major improvements for sparsely populated fields\n- Faster query times with sorted indices\n- Search scalability across shards\n",[9,893],{"slug":4901,"featured":6,"template":683},"new-elasticsearch-version-requirements","content:en-us:blog:new-elasticsearch-version-requirements.yml","New Elasticsearch Version Requirements","en-us/blog/new-elasticsearch-version-requirements.yml","en-us/blog/new-elasticsearch-version-requirements",{"_path":4907,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4908,"content":4914,"config":4918,"_id":4920,"_type":13,"title":4921,"_source":15,"_file":4922,"_stem":4923,"_extension":18},"/en-us/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management",{"title":4909,"description":4910,"ogTitle":4909,"ogDescription":4910,"noIndex":6,"ogImage":4911,"ogUrl":4912,"ogSiteName":670,"ogType":671,"canonicalUrls":4912,"schema":4913},"New Scheduled Reports Generation tool simplifies value stream management","Proactively receive the most recent metrics from the GitLab Value Streams Dashboard, streamlining the reporting process. This walkthrough shows you how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669134/Blog/Hero%20Images/blog-image-template-1800x945__17_.png","https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New Scheduled Reports Generation tool simplifies value stream management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2024-06-20\",\n      }",{"title":4909,"description":4910,"authors":4915,"heroImage":4911,"date":4476,"body":4916,"category":1513,"tags":4917},[2014],"Optimizing processes and performance is crucial for staying competitive in the fast-paced world of software development. [GitLab Value Stream Management (VSM)](https://www.youtube.com/watch?v=8pLEucNUlWI) is a powerful solution that helps organizations achieve this by providing a holistic view of the entire software delivery lifecycle. VSM enables teams to measure, manage, and improve their workflows, ensuring that every step adds value and minimizes waste. GitLab VSM also includes [AI Impact Analytics](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/), which helps managers quantify the impact of [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our AI-powered suite of features to power DevSecOps workflows, on productivity, providing deeper insights into how AI enhances developer efficiency. Now, we are announcing the next step in this VSM journey: Scheduled Reports Generation, available now.\n\nWith the Scheduled Reports Generation tool, value stream management becomes easier and more effective. Scheduled Reports Generation is designed to streamline the reporting process, providing you with the most recent [metrics from the Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports), delivered on a scheduled basis.\n\nThe Value Streams Dashboard tracks key metrics throughout the software development lifecycle, assesses the impact of process improvements, and drills down into roadblocks. It helps to compare best practices across teams in turn improving workflow and delivering customer value faster.\n\n> Learn more with our [Value Streams Dashboard tutorial](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/).\n\n## Why scheduled VSM Reports are important\n\nScheduled Reports Generation provides software managers a powerful partner in their quest for continuous improvement. This tool offers the ability to automate the creation and distribution of detailed value stream reports across the software delivery lifecycle. Here’s why this is valuable:\n\n1. **Consistent monitoring:** Having automated reports ensures that software managers receive regular updates on critical metrics without manual intervention. This consistency helps in maintaining a continuous feedback loop.\n\n2. **Data-driven decision-making:** With up-to-date and accurate data at their fingertips, managers can make better and faster decisions, driving better results.\n\n3. **Time savings:** Automating report generation frees up valuable time for managers, allowing them to focus on strategic initiatives rather than routine data collection and analysis.\n\n### Inside the Scheduled Reports Generation tool\n\nHere is how the VSM tool works:\n\n1. The VSM reporting tool is a [CI/CD Catalog component](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) that allows you to periodically schedule reports.\n\n2. These reports collect metrics from projects or groups via the public GitLab GraphQL API and are built using [GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html).\n\n3. As the final step, the tool opens an issue in the designated project, complete with a markdown comparison metrics table, as shown in the example below.\n\n![Scheduled reports generation - issue generation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677009/Blog/Content%20Images/Screenshot_2024-06-20_at_18.38.05.png)\n\n> To learn more and for additional examples, please visit the [Scheduled Reports Generation's README file](https://gitlab.com/components/vsd-reports-generator#example-for-monthly-executive-value-streams-report).\n\n### Get to know the Value Streams Dashboard\nWatch this intro video to get familiar with Value Streams Dashboard.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/8pLEucNUlWI?si=aIdrvREPVBwfC4wM\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Additional resources\n- [Getting started with the new GitLab Value Streams Dashboard](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n- [Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)",[9,478,678],{"slug":4919,"featured":6,"template":683},"new-scheduled-reports-generation-tool-simplifies-value-stream-management","content:en-us:blog:new-scheduled-reports-generation-tool-simplifies-value-stream-management.yml","New Scheduled Reports Generation Tool Simplifies Value Stream Management","en-us/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management.yml","en-us/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management",{"_path":4925,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4926,"content":4932,"config":4937,"_id":4939,"_type":13,"title":4940,"_source":15,"_file":4941,"_stem":4942,"_extension":18},"/en-us/blog/next-gen-telecom-with-gitlab",{"title":4927,"description":4928,"ogTitle":4927,"ogDescription":4928,"noIndex":6,"ogImage":4929,"ogUrl":4930,"ogSiteName":670,"ogType":671,"canonicalUrls":4930,"schema":4931},"Developing next-generation telecommunications with GitLab","Learn more about Project Sylva, a cross-industry collaboration to build a cloud-native, open source telecommunications platform using GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682864/Blog/Hero%20Images/telecomabstract.jpg","https://about.gitlab.com/blog/next-gen-telecom-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Developing next-generation telecommunications with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-08-07\",\n      }",{"title":4927,"description":4928,"authors":4933,"heroImage":4929,"date":4934,"body":4935,"category":827,"tags":4936},[3504],"2023-08-07","\nIn November 2022, the Linux Foundation Europe [announced the launch of Project Sylva](https://www.linuxfoundation.org/press/linux-foundation-europe-announces-project-sylva-to-create-open-source-telco-cloud-software-framework-to-complement-open-networking-momentum), a cloud-native, [open source](https://go.gitlab.com/spHNym) telecommunications software stack. The initiative represents a cross-industry collaboration between major telecommunications providers and vendors (Telefonica, Telecom Italia, Orange, Vodafone, Deutsche Telekom, Ericsson, and Nokia), who formally agreed to collaborate on building the foundation of a next-generation telecommunications system in the open.\n\nToday that work continues [on GitLab](https://gitlab.com/sylva-projects), where the project is gaining momentum as its contributor community grows. Eager to hear what that community has achieved since last year, I sat down with [André Vieira](https://gitlab.com/andre.macedo.av), the project's communications lead. \n\nWatch our interview to learn more about Sylva's guiding mission and vision, its successes, its challenges, and its future.\n\n## Watch the interview\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mblgJpmvkZI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[1187,266,9],{"slug":4938,"featured":6,"template":683},"next-gen-telecom-with-gitlab","content:en-us:blog:next-gen-telecom-with-gitlab.yml","Next Gen Telecom With Gitlab","en-us/blog/next-gen-telecom-with-gitlab.yml","en-us/blog/next-gen-telecom-with-gitlab",{"_path":4944,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4945,"content":4951,"config":4956,"_id":4958,"_type":13,"title":4959,"_source":15,"_file":4960,"_stem":4961,"_extension":18},"/en-us/blog/next-generation-gitlab-container-registry-goes-ga",{"title":4946,"description":4947,"ogTitle":4946,"ogDescription":4947,"noIndex":6,"ogImage":4948,"ogUrl":4949,"ogSiteName":670,"ogType":671,"canonicalUrls":4949,"schema":4950},"Next-generation GitLab container registry goes GA","Starting in GitLab 17.3, GitLab self-managed instances can access the generally available container registry, which features efficient zero-downtime garbage collection and other benefits.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/next-generation-gitlab-container-registry-goes-ga","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Next-generation GitLab container registry goes GA\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2024-07-23\",\n      }",{"title":4946,"description":4947,"authors":4952,"heroImage":4948,"date":4953,"body":4954,"category":701,"tags":4955},[1040],"2024-07-23","Last year, we embarked on an ambitious journey to [re-architect the GitLab container registry](https://gitlab.com/gitlab-org/container-registry/-/issues/199) and unlock powerful new capabilities like zero-downtime garbage collection. After successfully migrating GitLab.com to this next-generation registry, we [opened up a beta program](https://about.gitlab.com/blog/gitlabs-next-generation-container-registry-is-now-available/) for self-managed customers to test out the new architecture and provide feedback.\n\nThe results from the beta program have been outstanding – participants are already realizing major benefits, including the following:\n\n- significant storage cost and maintenance time savings from efficient zero-downtime garbage collection, with no required downtime or manual interventions\n- improved performance and reliability for tag cleanup policies and the container registry API and UI\n- early access to new features like better sorting/filtering and storage usage visibility\n\nBased on the positive feedback and successful migrations during the beta, we are excited to announce that the next-generation GitLab container registry will become generally available – but off by default – for self-managed deployments starting with GitLab 17.3.\n\nBelow are the goals and non-goals for reaching this point. The goals are what we need to have in place to officially call this feature GA. The non-goals clarify what will not be present or required at the start of GA support for bringing your own database; however, these features may be added later.\n\n__Goals__\n- The import process is free of known bugs.\n- Import documentation reflects known best practices and addresses feedback from the [beta program](https://gitlab.com/gitlab-org/gitlab/-/issues/423459).\n- Registry API, metadata database, and zero-downtime garbage collection are stable and reliable.\n- Able to automatically apply database schema migrations for Charts installs during upgrades.\n- Provide registry database as an opt-in improvement.\n\n__Non-goals__\n- Automatically provision registry database.\n- Automatically apply database schema migrations for omnibus installs during upgrades.\n- Automatically import object storage data.\n- Provide Geo support to ensure your registry is highly available.\n\nFor existing self-managed instances, here's what you can expect:\n\n- In GitLab 17.3, the new registry will be included, but disabled by default to allow time for planning migrations.\n- Enabling the database will be an opt-in process outlined in the [documentation](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html).\n- The legacy container registry will still receive security updates, but new features and improvements will only be developed for the next-gen version.\n- We will target GitLab 19.0 for the legacy registry to stop being supported after over a year of co-existence.\n- Our goal is to make this transition as seamless as possible while putting customers in control of their migration timeline. The [documentation](https://docs.gitlab.com/ee/administration/packages/container_registry_metadata_database.html) covers all the details on how to plan and execute the move to the next-gen registry.\n\nThis architectural investment lays the foundation for an even more powerful container registry experience in the years ahead. Some of the significant improvements on our roadmap include:\n\n- protected repositories and immutable tags\n- improved Helm chart management\n- improved support for signing and attestations\n- many more UX/UI enhancements are only possible with the database architecture\n\nWe couldn't have reached this GA milestone without the valuable feedback from our beta participants. As always, please continue to share your experiences so we can make the GitLab container registry an indispensable part of your DevSecOps toolchain.\n\n> You can try the container registry today with a [free, 30-day trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).",[478,9,4341,701],{"slug":4957,"featured":90,"template":683},"next-generation-gitlab-container-registry-goes-ga","content:en-us:blog:next-generation-gitlab-container-registry-goes-ga.yml","Next Generation Gitlab Container Registry Goes Ga","en-us/blog/next-generation-gitlab-container-registry-goes-ga.yml","en-us/blog/next-generation-gitlab-container-registry-goes-ga",{"_path":4963,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4964,"content":4970,"config":4977,"_id":4979,"_type":13,"title":4980,"_source":15,"_file":4981,"_stem":4982,"_extension":18},"/en-us/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development",{"title":4965,"description":4966,"ogTitle":4965,"ogDescription":4966,"noIndex":6,"ogImage":4967,"ogUrl":4968,"ogSiteName":670,"ogType":671,"canonicalUrls":4968,"schema":4969},"Observability's role in cloud-native app development","Want better visibility into the entire software development lifecycle across environments? Learn how observability can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663993/Blog/Hero%20Images/2018-developer-report-cover.jpg","https://about.gitlab.com/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Observability is key to cloud-native transitions and modern application development\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-04-05\",\n      }",{"title":4971,"description":4966,"authors":4972,"heroImage":4967,"date":4974,"body":4975,"category":1249,"tags":4976},"Observability is key to cloud-native transitions and modern application development",[4973],"Sandra Gittlen","2022-04-05","\n\n_This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes._\n\nModern application development requires DevOps teams to be able to collaborate and react to what is happening across the software development lifecycle. Yet, as companies move away from monolithic code bases resident on a server or cluster of virtual machines to cloud-native environments, this goal becomes more difficult to achieve. Cloud-native architectures are more complex with more elements to configure, protect, execute, and measure. To ensure maximum visibility and responsiveness to issues early on in application development and throughout the lifecycle, companies are adopting observability.\n\n## Observability defined\n\nObservability, which [451 Research](https://451research.com/) defines as the collection and analysis of data logs, metrics, and traces, becomes critical and essential with cloud-native technologies and acts as a step beyond monitoring. “The need for such an approach has been brought to the fore by complex, distributed microservices-based applications where the variables are so numerous that it can be impossible to know exactly what metrics need to be collected for the gamut of potential events that could arise,” 451 Research’s “Voice of the Enterprise: DevOps, Organizational Dynamics - Advisory Report” states.\n\n“A need to know what is happening with infrastructure and applications, particularly across hybrid and multi-cloud infrastructure, has driven broad adoption of observability,” according to the report.\n\n## How observability improves cloud-native tech adoption\n\nMore than half of organizations surveyed by 451 Research report either full adoption or some adoption at the team level of cloud-native technologies such as containers, Kubernetes, service mesh, and serverless computing. Another quarter to one-third of respondents plans to deploy cloud-native technologies.\n\nThe challenge is visibility across this new, more complex architecture. While cloud-native technologies offer more flexibility and cost efficiencies for computing resources, they can make it difficult to gain end-to-end visibility of software vulnerabilities, application performance, and quality assessments, and to be able to know where and how to affect change early on in the development lifecycle.\n\nDevOps improvements such as security and analytics are driving the adoption of observability, as is the increased need for compliance. With observability, according to 451 Research’s report, “one can query the data they have and ask any number of questions about a system, and, ideally, get an answer without having to predefine the exact data collected or tagging applied to answer the question.”\n\nIn other words, observability can provide a more flexible toolkit and enable a more active drill-down into what’s actually happening in the development lifecycle. With properly implemented observability, DevOps teams can, in real-time, identify a problem, fix it, benchmark the improvement, and measure it going forward – even in a cloud-native environment that is abstracted from knowledge of underlying systems. Having the ability to observe and measure your end-to-end DevOps efforts can reduce risk and provide greater control of cloud-native environments. \n\nDigital transformation leaders and laggards alike understand the need for observability. Nearly two-thirds of all respondents say they have adopted observability (41%) or have it in discovery/proof of concept (23%). Nearly a third plan to implement it within 12 to 24 months.\n\n“While it is great to see these adoption rates, the ultimate goal is to evolve observability’s inputs into actionable insights that positively impact the business,” says Sebastien Pahl, principal product manager at GitLab and co-founder of observability start-up OpsTrace (which was [acquired by GitLab in 2021](/press/releases/2021-12-14-gitlab-acquires-opstrace-to-expand-its-devops-platform-with-open-source-observability-solution.html)).\n\n## The benefits of observability\n\nIn modern application development, dev, sec, and ops teams share the responsibility of software development and delivery. In mature organizations, DevOps can extend to include stakeholders from compliance, legal, finance, and other departments with a direct stake in value delivery. Observability provides DevOps teams greater flexibility in how to utilize and share data across an organization.\n\nPahl likens observability to a flight crew being able to see, learn from, and react to all the data from instruments and dashboards on a plane as it is flying. “With observability, everyone can look at the same data through a different lens,” he says.\n\nObservability has significant benefits, including the following:\n\n- Developers can add code early in the development lifecycle for events they want to observe.\n\n- DevOps teams can move faster because they know when something is wrong and exactly what is wrong. They can fix problems once and move on.\n\n- Organizations can detect problems before customers do.\n\n- DevOps teams can assign certain alerts to specific individuals or teams so ops teams won’t be burned out responding to general alerts.\n\n- The inputs and metrics written through observability lay the foundation for AI and machine learning.\n\n## Observability and the DevOps Platform\n\nGitLab believes that [observability is foundational](https://opstrace.com/blog/gitlabobsvervabilityui) to a DevOps platform, and will make the capability available to all GitLab users. [Our vision](/direction/monitor/) is to make every GitLab project observable by default, with features that are easy to operate without specialized, expert skills. Teams can connect the dots between every deployment, incident, and other noteworthy events using and collaborating with telemetry data, which ultimately decreases the frequency and severity of production issues.\n\nGitLab’s observability capability is completely open-sourced and relies on open APIs such as Prometheus and OpenTelemetry so users don’t have to worry about vendor lock-in from instrumentation to alerting. It’s built into the GitLab DevOps platform to help you use the capability right away within your native workflow.\n\nLearn more about [observability and the DevOps Platform](https://about.gitlab.com/).\n\n\n\n\n\n\n\n",[851,4341,1187,9],{"slug":4978,"featured":6,"template":683},"observability-is-key-to-cloud-native-transitions-and-modern-application-development","content:en-us:blog:observability-is-key-to-cloud-native-transitions-and-modern-application-development.yml","Observability Is Key To Cloud Native Transitions And Modern Application Development","en-us/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development.yml","en-us/blog/observability-is-key-to-cloud-native-transitions-and-modern-application-development",{"_path":4984,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":4985,"content":4991,"config":4996,"_id":4998,"_type":13,"title":4999,"_source":15,"_file":5000,"_stem":5001,"_extension":18},"/en-us/blog/open-source-tools-for-citizen-journalists",{"title":4986,"description":4987,"ogTitle":4986,"ogDescription":4987,"noIndex":6,"ogImage":4988,"ogUrl":4989,"ogSiteName":670,"ogType":671,"canonicalUrls":4989,"schema":4990},"How the Colmena project uses GitLab to support citizen journalists","Find out why the Colmena project, a GitLab Open Source Partner, relies on a DevSecOps platform to develop and deliver open source tools for citizen journalism.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683016/Blog/Hero%20Images/citizenjournalism.png","https://about.gitlab.com/blog/open-source-tools-for-citizen-journalists","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the Colmena project uses GitLab to support citizen journalists\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-09-27\",\n      }",{"title":4986,"description":4987,"authors":4992,"heroImage":4988,"date":4993,"body":4994,"category":827,"tags":4995},[3504],"2023-09-27","\nIn an increasingly crowded media ecosystem, finding an audience — and being heard — can be difficult, especially for indigenous communities with limited access to global platforms. But using the open source [Colmena project](https://blog.colmena.media/), anyone can collaboratively plan, record, edit, and distribute hyperlocal and community-focused media products that reach audiences worldwide.\n\nThe Colmena project (which takes its name from the Spanish word for \"beehive\") is a [GitLab Open Source Partner](https://go.gitlab.com/030Ue3). I recently spoke with community members [Nils Brock](https://gitlab.com/nilsbrock), [Vivienne Gager](https://gitlab.com/vivienne.maria), and [Santiago Garcia Gago](https://gitlab.com/SantiagoGG) about how they use GitLab to help people find their voices, tell their stories, and help their communities.\n\nWe conducted our interview iteratively, asynchronously, and collaboratively [via merge request](https://gitlab.com/gitlab-com/marketing/developer-relations/open-source-program/gitlab-open-source-partners/publications-and-presentations/-/merge_requests/9).\n\n**Welcome to the the GitLab Open Source Partners community! We're so delighted you're here. Tell our readers more about Colmena. What is it?**\n\nBrock, Gager, and Garcia Gago: Colmena is open technology for journalists. Think of it as a mobile digital newsroom for field reporters and media outlets. Our software enables users to create and share content. But here is what's special: The solution is developed together with local and community media from the Global South, is free to use, and is completely open source. \n\nThe backbone of Colmena is a custom-made digital newsroom for production teams, which includes all essential features for content creation, with special consideration for audio productions and transmissions. So we have audio streaming and podcast production workflows, a mobile recording option (face-to-face and online interviews), and mobile text and audio editing tools. All tools are set up for cross-media collaboration and are highly customizable. It's also important to note that Colmena is already available in eight languages, including English, Arabic, and Ukranian.\n\nBut Colmena doesn't need to stop there. We are always open for new suggestions.\n\n**Where can users download Colmena? How can they use it?**\n\nAs a lightweight app (a so-called \"progressive web application,\" or PWA), Colmena performs on a wide range of mobile and desktop devices for easy online/offline creation and collaboration. On the server side, we have established a secure and federated architecture, offering cloud-based sharing, storage, and publishing wherever you want, be it your own website on social media or other platforms.\n\n**How did the project get started? What mission, vision, and values drive it?**\n\nThe initiative [was born as a response to the COVID-19 pandemic](https://p.dw.com/p/3ydGf), and it's led by DW Akademie and the Mexican NGO Redes por la Diversidad, Equidad y Sustentabilidad A.C. The project is supported by the German Federal Ministry of Economic development and Cooperation (BMZ) as part of the Global Crisis Initiative (GKI).\n\n[Our vision](https://p.dw.com/p/40B1S) is to provide safe and inclusive digital tools for the communication, creation, and sharing of human rights-based content, to defend and extend freedom of expression to all parts of the world. And as the driving force behind the Colmena project, our mission is to sustainably maintain and develop the open source Colmena software as a commons, based on the needs of community-centered communication, networking, and media practices of the global majority.\n\nCollaboration is an important aspect of Colmena's development model. We develop the application working closely with [media partners](https://p.dw.com/p/4B1ID), to whom we refer as \"communities of practice\" (CoPs). Generally, one or two members of each CoP serve as representatives of their media outlets in the Colmena project. One might say they have the most important role in the project. Colmena is a collective response to their needs, and we want to design it to overcome challenges they face.\n\n**How does the Colmena project use GitLab to accomplish all this?**\n\nWe use of GitLab for the Colmena Project in three different ways. The first use is quite technical: We use it as [a development platform and code repository](https://git.colmena.network/maia). All repositories for the Colmena PWA are public; we keep only the \"infra\" project private (since that's where the data of our development servers are stored).\n\nSecondly, [GitLab's wiki feature](https://docs.gitlab.com/ee/user/project/wiki/) serves us quite well as a documentation space for both our general work team and additional collaborators, who are the coordinators of our CoPs and the media partners involved in the co-creation of Colmena. [In the wiki](https://git.colmena.network/maia/frontend/-/wikis/home), for instance, we socialize information for the onboarding of new team members — like general information on the project, additional literature, and manuals of the tools we use in the project and documentation of conducted workshops for internal knowledge sharing. Before we had this documentation stored in a Nextcloud instance, but using GitLab for this work creates deeper understanding between the users, coordinators, and the development team about Colmena development processes and workflows.\n\nFinally, we maintain [an open \"support\" project](https://git.colmena.network/maia/support/-/issues?scope=all&state=all). In this project, the coordinators of the CoPs, who work with 30 media outlets from different countries, collect suggestions or detected bugs and report them. The development team evaluates and responds to each of them. If they need specialized attention — for example, development of a new feature or some bug fixing — we move these these issues to the corresponding development projects. We are currently migrating this repository from our self-hosted instance [to Gitlab.com](https://gitlab.com/colmena-project/communities-of-practice).\n\n**Why did the Colmena project choose GitLab as its development platform?**\n\nColmena was born as a free and open source software project; many of the developers and members of the coordination team have been involved in free software and community media projects before (for example, in the [Network of Community Radios and Free Software](https://liberaturadio.org/)). Our project always wanted to maintain this philosophy when looking for suitable software development platforms. That's why we chose GitLab: It shares our ideals regarding software development and knowledge sharing. Furthermore, Colmena is proud to use GitLab together with other free software projects that we have been using for ages, such as [Inkscape, Debian, and VLC](https://go.gitlab.com/030Ue3).\n\nBesides the shared philosophy, however, GitLab offers us technical options that other platforms do not. For example, it can be self-hosted, allows for management of groups and subgroups is, and features integrated planning tools like [epics](https://docs.gitlab.com/ee/user/group/epics/) and [roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/) that really benefit the development process.\n\n**How can potential contributors learn more about Colmena?**\n\nIf you want to get in touch with us, please visit [our website](https://colmena.media) or write the team directly at `info@colmena.media`. You can also [browse the project and contirbute on GitLab](https://gitlab.com/colmena-project).\n\n## Watch the webcast \nWatch our interview with the Colmena project.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/4wIg2M1EoHI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Learn more\nThe [GitLab Open Source Partners](https://go.gitlab.com/030Ue3) are building the future of open source on GitLab. Connect with them on [Gitlab.com](https://gitlab.com/gitlab-com/marketing/community-relations/open-source-program/gitlab-open-source-partners).\n",[1187,266,9],{"slug":4997,"featured":6,"template":683},"open-source-tools-for-citizen-journalists","content:en-us:blog:open-source-tools-for-citizen-journalists.yml","Open Source Tools For Citizen Journalists","en-us/blog/open-source-tools-for-citizen-journalists.yml","en-us/blog/open-source-tools-for-citizen-journalists",{"_path":5003,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5004,"content":5010,"config":5016,"_id":5018,"_type":13,"title":5019,"_source":15,"_file":5020,"_stem":5021,"_extension":18},"/en-us/blog/parallels-between-all-remote-and-cloud-computing",{"title":5005,"description":5006,"ogTitle":5005,"ogDescription":5006,"noIndex":6,"ogImage":5007,"ogUrl":5008,"ogSiteName":670,"ogType":671,"canonicalUrls":5008,"schema":5009},"The parallels between all-remote and cloud computing","The rise of the remote workplace has many parallels with the rise of cloud computing.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673019/Blog/Hero%20Images/vintage-keyboards.jpg","https://about.gitlab.com/blog/parallels-between-all-remote-and-cloud-computing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The parallels between all-remote and cloud computing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joyce Tompsett\"}],\n        \"datePublished\": \"2019-10-29\",\n      }",{"title":5005,"description":5006,"authors":5011,"heroImage":5007,"date":5013,"body":5014,"category":996,"tags":5015},[5012],"Joyce Tompsett","2019-10-29","\nAs a GitLab team member, I’m frequently asked what it’s like to work in an [all-remote company](/company/culture/all-remote/). Folks are curious – they like the idea of being able to work from home, but the idea of a company that is *fully* remote is a strange and [wondrous thing](/blog/all-remote-is-for-everyone/). Occasionally, I also encounter people for whom remote is an inconceivable concept. They argue it cannot be done, and won’t work, despite the fact that we (and a [growing list of others](/company/culture/all-remote/jobs/)) continue to thrive as a successful all-remote organization.\n\nThe rise of the remote workplace draws many parallels to the rise of [cloud computing](/blog/google-cloud-next-anthos-kubernetes/).\n\n## Bringing cloud computing to the mainstream\n\nWhile many were comfortable with the idea of network computing for a long time, the notion of cloud computing started to appear with more frequency at the turn of the millennium, championed by companies like Google and Amazon.\n\nThe notion behind cloud computing was that users could access their files, programs and even their compute resources over the network, and potentially from somewhere that was entirely removed from their physical location. There was no physical data center specific to that organization. The capability offered was important but the physical location of the resources was less relevant, as long as it met the users’ requirements.\n\nInitially, those requirements were challenging. Performance, reliability, and security were closely critiqued, but the *primary* challenge for humans was this: They would have to trust something they could not physically touch.\n\nAs confidence and familiarity with cloud computing increased, software as a service (SaaS) companies emerged. Salesforce and Workday were designed to run in the cloud from inception – and as they became successful, a bevy of SaaS applications emerged. Many companies, GitLab included, offer options for both on-premises and SaaS versions of their applications, and discussions in data centers are about migrating or modernizing legacy mission-critical applications to a cloud environment – a once unthinkable idea.\n\nCloud, once scoffed at by many, is now an expected part of most firms’ [strategic technology portfolio](/blog/kubernetes-chat-with-kelsey-hightower/).\n\n![Focus on outputs, not inputs such as being seen in an office](https://about.gitlab.com/images/blogimages/working-remotely-el-salvador.jpg){: .shadow.medium.center}\nFocus on outputs, not inputs such as being seen in an office.\n{: .note.text-center}\n\n## The evolution of the remote workplace\n\nA similar progression is occurring with remote work. Working off-premises has occurred for years, but it was typically reserved for certain positions or types of companies, and certainly was not a mainstream option.\n\nMany companies that offer remote work are [hybrid-remote](/company/culture/all-remote/hybrid-remote/), where an employee may work remotely, but the bulk of the company reports to a physical infrastructure, either centralized or distributed. The rise of [all-remote companies](/company/culture/all-remote/) such as GitLab is analogous to the rise of cloud-based companies such as Salesforce or Workday. We are starting to see other all-remote companies form and at GitLab we expect all-remote will become more common as we develop [best practices](/company/culture/all-remote/meetings/) and evolve more [efficient ways](/company/culture/all-remote/management/) of working remotely.\n\nWe believe that [all-remote is the future of work](/blog/all-remote-is-for-everyone/) – that it will be as likely that an organization is remote as not — particularly if physical manufacturing isn’t involved.\n\n## What all-remote and cloud computing have in common\n\nIn addition to the similarities in how they evolved, many of the benefits of cloud computing have analogues to those of remote work. Some of the cloud benefits we also see with remote working include:\n\n1. Increased agility: Remote work increases an organization’s flexibility to add, expand, or deploy employees in line with the company’s needs.\n1. Cost reductions: Many capital expenditures arguably become operational in all-remote workplaces. The lack of physical infrastructure to lease or buy and maintain offers cost savings to companies. This also lowers barriers to entry for new companies entering the market.\n1. Employee (compute) location independence: Distributed workplaces enables companies to attract and hire the best talent regardless of location, just as users can connect to the company from anywhere they have adequate Internet access.\n1. Productivity often increases as [asynchronous communication](/company/culture/all-remote/informal-communication/) allows multiple employees to work on the same data simultaneously, rather than waiting for synchronous meetings that function like bottlenecks.\n\nThis innovative deployment of people is strikingly similar to the innovative deployment of cloud computing. The key challenge the same for cloud and remote: Organizations need to [trust](/company/culture/all-remote/management/) the model and realize the [benefits](/company/culture/all-remote/benefits/) for themselves.\n\nCover image by [Darren Murph](https://twitter.com/darrenmurph)\n{: .note}\n",[9,680,998],{"slug":5017,"featured":6,"template":683},"parallels-between-all-remote-and-cloud-computing","content:en-us:blog:parallels-between-all-remote-and-cloud-computing.yml","Parallels Between All Remote And Cloud Computing","en-us/blog/parallels-between-all-remote-and-cloud-computing.yml","en-us/blog/parallels-between-all-remote-and-cloud-computing",{"_path":5023,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5024,"content":5030,"config":5035,"_id":5037,"_type":13,"title":5038,"_source":15,"_file":5039,"_stem":5040,"_extension":18},"/en-us/blog/parent-child-pipelines",{"title":5025,"description":5026,"ogTitle":5025,"ogDescription":5026,"noIndex":6,"ogImage":5027,"ogUrl":5028,"ogSiteName":670,"ogType":671,"canonicalUrls":5028,"schema":5029},"How to get started with Parent-child pipelines","We introduced improvements to pipelines to help scale applications and their repo structures more effectively. Here's how they work.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667040/Blog/Hero%20Images/parent_pipeline_graph.png","https://about.gitlab.com/blog/parent-child-pipelines","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to get started with Parent-child pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Ward\"}],\n        \"datePublished\": \"2020-04-24\",\n      }",{"title":5025,"description":5026,"authors":5031,"heroImage":5027,"date":5032,"body":5033,"category":849,"tags":5034},[1080],"2020-04-24","As applications and their repository structures grow in complexity, a repository `.gitlab-ci.yml` file becomes difficult to manage, collaborate on, and see benefit from. This problem is especially true for the increasingly popular \"[monorepo](https://en.wikipedia.org/wiki/Monorepo)\" pattern, where teams keep code for multiple related services in one repository. Currently, when using this pattern, developers all use the same `.gitlab-ci.yml` file to trigger different automated processes for different application components, likely causing merge conflicts, and productivity slowdown, while teams wait for \"their part\" of a pipeline to run and complete.\n\nTo help large and complex projects manage their automated workflows, we've added two new features to make pipelines even more powerful: Parent-child pipelines, and the ability to generate pipeline configuration files dynamically.\n\n## Meet Parent-child pipelines\n\nSo, how do you solve the pain of many teams collaborating on many inter-related services in the same repository? \nLet me introduce you to [Parent-child pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html), released with with [GitLab 12.7](/releases/2020/01/22/gitlab-12-7-released/#parent-child-pipelines). Splitting complex pipelines into multiple pipelines with a parent-child relationship can improve performance by allowing child pipelines to run concurrently. This relationship also enables you to compartmentalize configuration and visualization into different files and views. \n\n### Creating a child pipeline\n\nYou trigger a child pipeline configuration file from a parent by including it with the `include` key as a parameter to the `trigger` key. You can name the child pipeline file whatever you want, but it still needs to be valid YAML.\n\nThe parent configuration below triggers two further child pipelines that build the Windows and Linux version of a C++ application. \n\n```cpp\n#include \u003Ciostream>\nint main()\n{\n  std::cout \u003C\u003C \"Hello GitLab!\" \u003C\u003C std::endl;\n  return 0;\n}\n```\n\nThe setup is a simple one but hopefully illustrates what is possible.\n\n```yaml\nstages:\n  - triggers\n\nbuild_windows:\n  stage: triggers\n  trigger:\n    include: .win-gitlab-ci.yml\n  rules:\n    - changes:\n      - cpp_app/*\n\nbuild_linux:\n  stage: triggers\n  trigger:\n    include: .linux-gitlab-ci.yml\n  rules:\n    - changes:\n      - cpp_app/*\n```\n\nThe important values are the `trigger` keys which define the child configuration file to run, and the parent pipeline continues to run after triggering it. You can use all the normal sub-methods of `include` to use local, remote, or template config files, up to a maximum of three child pipelines.\n\nAnother useful pattern to use for parent-child pipelines is a `rules` key to trigger a child pipeline under certain conditions. In the example above, the child pipeline only triggers when changes are made to files in the _cpp_app_ folder.\n\nThe Windows build child pipeline (`.win-gitlab-ci.yml`) has the following configuration, and unless you want to trigger a further child pipeline, it follows standard a configuration format:\n\n```yaml\nimage: gcc\nbuild:\n  stage: build\n  before_script:\n    - apt update && apt-get install -y mingw-w64\n  script:\n    - x86_64-w64-mingw32-g++ cpp_app/hello-gitlab.cpp -o helloGitLab.exe\n  artifacts:\n    paths:\n      - helloGitLab.exe\n```\n\nDon't forget the `-y` argument as part of the `apt-get install` command, or your jobs will be stuck waiting for user input.\n\nThe Linux build child pipeline (`.linux-gitlab-ci.yml`) has the following configuration, and unless you want to trigger a further child pipeline, it follows standard a configuration format:\n\n```yaml\nimage: gcc\nbuild:\n  stage: build\n  script:\n    - g++ cpp_app/hello-gitlab.cpp -o helloGitLab\n  artifacts:\n    paths:\n      - helloGitLab\n```\n\nIn both cases, the child pipeline generates an artifact you can download under the _Job artifacts_ section of the Job result screen.\n\nPush all the files you created to a new branch, and for the pipeline result, you should see the two jobs and their subsequent child jobs.\n\n![Parent-child pipeline result](https://about.gitlab.com/images/blogimages/non-dynamic-pipelines.png){: .shadow.medium.center}\nThe result of a parent-child pipeline\n{: .note.text-center}\n\n## Dynamically generating pipelines\n\nTaking Parent-child pipelines even further, you can also dynamically generate the child configuration files from the parent pipeline. Doing so keeps repositories clean of scattered pipeline configuration files and allows you to generate configuration in your application, pass variables to those files, and much more.\n\nLet's start with the parent pipeline configuration file:\n\n```yaml\nstages:\n  - setup\n  - triggers\n\ngenerate-config:\n  stage: setup\n  script:\n    - ./write-config.rb\n    - git status\n    - cat .linux-gitlab-ci.yml\n    - cat .win-gitlab-ci.yml\n  artifacts:\n    paths:\n      - .linux-gitlab-ci.yml\n      - .win-gitlab-ci.yml\n\ntrigger-linux-build:\n  stage: triggers\n  trigger:\n    include:\n      - artifact: .linux-gitlab-ci.yml\n        job: generate-config\n\ntrigger-win-build:\n  stage: triggers\n  trigger:\n    include:\n      - artifact: .win-gitlab-ci.yml\n        job: generate-config\n```\n\nDuring our self-defined `setup` stage the pipeline runs the `write-config.rb` script. For this article, it's a Ruby script that writes the child pipeline config files, but you can use any scripting language. The child pipeline config files are the same as those in the non-dynamic example above. We use `artifacts` to save the generated child configuration files for this CI run, making them available for use in the child pipelines stages.\n\nAs the Ruby script is generating YAML, make sure the indentation is correct, or the pipeline jobs will fail.\n\n```ruby\n#!/usr/bin/env ruby\n\nlinux_build = \u003C\u003C~YML\n    image: gcc\n    build:\n        stage: build\n        script:\n            - g++ cpp_app/hello-gitlab.cpp -o helloGitLab\n        artifacts:\n            paths:\n                - helloGitLab\nYML\n\nwin_build = \u003C\u003C~YML\n    image: gcc\n    build:\n        stage: build\n        before_script:\n            - apt update && apt-get install -y mingw-w64\n        script:\n            - x86_64-w64-mingw32-g++ cpp_app/hello-gitlab.cpp -o helloGitLab.exe\n        artifacts:\n            paths:\n                - helloGitLab.exe\nYML\n\nFile.open('.linux-gitlab-ci.yml', 'w'){ |f| f.write(linux_build)}\nFile.open('.win-gitlab-ci.yml', 'w'){ |f| f.write(win_build)}\n```\n\nThen in the `triggers` stage, the parent pipeline runs the generated child pipelines much as in the non-dynamic version of this example but instead using the saved `artifact` files, and the specified `job`.\n\nPush all the files you created to a new branch, and for the pipeline result, you should see the three jobs (with one connecting to the two others) and the subsequent two children.\n\n![Dynamic parent-child pipeline result](https://about.gitlab.com/images/blogimages/dynamic-pipelines.png){: .shadow.medium.center}\nThe result of a dynamic parent-child pipeline\n{: .note.text-center}\n\n## Pipeline flexibility\n\nThis blog post showed some simple examples to give you an idea of what you can now accomplish with pipelines. With one parent, multiple children, and the ability to generate configuration dynamically, we hope you find all the tools you need to [build CI/CD workflows](/topics/ci-cd/) you need.\n\nYou can also watch a demo of Parent-child pipelines below:\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/n8KpBSqZNbk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[108,9,680,746],{"slug":5036,"featured":6,"template":683},"parent-child-pipelines","content:en-us:blog:parent-child-pipelines.yml","Parent Child Pipelines","en-us/blog/parent-child-pipelines.yml","en-us/blog/parent-child-pipelines",{"_path":5042,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5043,"content":5049,"config":5056,"_id":5058,"_type":13,"title":5059,"_source":15,"_file":5060,"_stem":5061,"_extension":18},"/en-us/blog/parent-child-vs-multi-project-pipelines",{"title":5044,"description":5045,"ogTitle":5044,"ogDescription":5045,"noIndex":6,"ogImage":5046,"ogUrl":5047,"ogSiteName":670,"ogType":671,"canonicalUrls":5047,"schema":5048},"CI/CD patterns with parent-child and multi-project pipelines","Parent-child pipelines inherit a lot of the design from multi-project pipelines, but they also have differences that make them unique.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659961/Blog/Hero%20Images/parent-child-multi-project-pipelines-unsplash.jpg","https://about.gitlab.com/blog/parent-child-vs-multi-project-pipelines","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Breaking down CI/CD complexity with parent-child and multi-project pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabio Pitino\"}],\n        \"datePublished\": \"2022-02-22\",\n      }",{"title":5050,"description":5045,"authors":5051,"heroImage":5046,"date":5053,"body":5054,"category":849,"tags":5055},"Breaking down CI/CD complexity with parent-child and multi-project pipelines",[5052],"Fabio Pitino","2022-02-22","\nSoftware requirements change over time. Customers request more features and the application needs to scale well\nto meet user demands. As software grows in size, so does its complexity, to the point where we might decide that it's\ntime to split the project up into smaller, cohesive components.\n\nAs we proceed to tackle this complexity we want to ensure that our CI/CD pipelines continue to validate\nthat all the pieces work correctly together.\n\nThere are two typical paths to splitting up software projects:\n\n- **Isolating independent modules within the same repository**: For example, separating the UI from the backend,\n  the documentation from code, or extracting code into independent packages.\n- **Extracting code into a separate repository**: For example, extracting some generic logic into a library, or creating\n  independent microservices.\n\nWhen we pick a path for splitting up the project, we should also adapt the CI/CD pipeline to match.\n\nFor the first path, [GitLab CI/CD](/topics/ci-cd/) provides [parent-child pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) as a feature that helps manage complexity while keeping it all in a monorepo.\n\nFor the second path, [multi-project pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html)\nare the glue that helps ensure multiple separate repositories work together.\n\nLet's look into how these two approaches differ, and understand how to best leverage them.\n\n## Parent-child pipelines\n\nIt can be challenging to maintain complex CI/CD pipeline configurations, especially when you need to coordinate many jobs that may relate\nto different components, while at the same time keeping the pipeline efficient.\n\nLet's imagine we have an app with all code in the same repository, but split into UI and backend components. A \"one-size-fits-all\" pipeline for this app probably would have all the jobs grouped into common stages that cover all the components. The default is to use `build`, `test`, and `deploy` stages.\nUnfortunately, this could be a source of inefficiency because the UI and backend represent two separate tracks of the pipeline.\nThey each have their own independent requirements and structure and likely don't depend on each other.\nThe UI might not need the `build` stage at all, but it might instead need a `system-test` stage with jobs that test the app end-to-end.\nSimilarly, the UI jobs from `system-test` might not need to wait for backend jobs to complete.\n\n[Parent-child pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) help here,\nenabling you to extract cohesive parts of the pipeline into child pipelines that runs in isolation.\n\nWith parent-child pipelines we could break the configurations down into two separate\ntracks by having two separate jobs trigger child pipelines:\n\n- The `ui` job triggers a child pipeline that runs all the UI jobs.\n- The `backend` job triggers a separate child pipeline that runs all the backend jobs.\n\n```yaml\nui:\n  trigger:\n    include: ui/.gitlab-ci.yml\n    strategy: depend\n  rules:\n    - changes: [ui/*]\nbackend:\n  trigger:\n    include: backend/.gitlab-ci.yml\n    strategy: depend\n  rules:\n    - changes: [backend/*]\n```\n\nThe modifier `strategy: depend`, which is also available for multi-project pipelines, makes the trigger job reflect the status of the\ndownstream (child) pipeline and waits for it to complete. Without `strategy: depend` the trigger job succeeds immediately after creating the downstream pipeline.\n\nNow the frontend and backend teams can manage their CI/CD configurations without impacting each other's pipelines. In addition to that, we can now explicitly visualize the two workflows.\n\n![example parent-child pipeline](https://about.gitlab.com/images/blogimages/2022-02-01-parent-child-vs-multi-project-pipelines/parent-child.png){: .shadow.medium.center}\n\nThe two pipelines run in isolation, so we can set variables or configuration in one without affecting the other. For example, we could use `rules:changes` or `workflow:rules` inside `backend/.gitlab-ci.yml`, but use something completely different in `ui/.gitlab-ci.yml`.\n\nChild pipelines run in the same context of the parent pipeline, which is the combination of project, Git ref and commit SHA. Additionally, the child pipeline inherits some information from the parent pipeline, including Git push data like `before_sha`, `target_sha`, the related merge request, etc.\nHaving the same context ensures that the child pipeline can safely run as a sub-pipeline of the parent, but be in complete isolation.\n\nA programming analogy to parent-child pipelines would be to break down long procedural code into smaller, single-purpose functions.\n\n## Multi-project pipelines\n\nIf our app spans across different repositories, we should instead leverage [multi-project pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html). Each repository defines a pipeline that suits the project's needs. Then, these standalone and independent pipelines can be chained together to create essentially a much bigger pipeline that ensures all the projects are integrated correctly.\n\nThere can be endless possibilities and topologies, but let's explore a simple case of asking another project\nto run a service for our pipeline.\n\nThe app is divided into multiple repositories, each hosting an independent component of the app.\nWhen one of the components changes, that project's pipeline runs.\nIf the earlier jobs in the pipeline are successful, a final job triggers a pipeline on a different project, which is the project responsible for building, running smoke tests, and\ndeploying the whole app. If the component pipeline fails because of a bug, the process is interrupted and there is no\nneed to trigger a pipeline for the main app project.\n\nThe component project's pipeline:\n\n```yaml\nbuild:\n  stage: build\n  script: ./build_component.sh\n\ntest:\n  stage: test\n  script: ./test_component.sh\n\ndeploy:\n  stage: deploy\n  trigger:\n    project: myorg/app\n    strategy: depend\n```\n\nThe full app project's pipeline in `myorg/app` project:\n\n```yaml\nbuild:\n  stage: build\n  script: ./build_app.sh  # build all components\n\nqa-test:\n  stage: test\n  script: ./qa_test.sh\n\nsmoke-test:\n  stage: test\n  script: ./smoke_test.sh\n\ndeploy:\n  stage: deploy\n  script: ./deploy_app.sh\n```\n\n![example multi-project pipeline](https://about.gitlab.com/images/blogimages/2022-02-01-parent-child-vs-multi-project-pipelines/multi-project.png){: .shadow.center}\n\nIn our example, the component pipeline (upstream) triggers a downstream multi-project pipeline to perform a service:\nverify the components work together, then deploy the whole app.\n\nA programming analogy to multi-project pipelines would be like calling an external component or function to\neither receive a service (using `strategy:depend`) or to notify it that an event occurred (without `strategy:depend`).\n\n## Key differences between parent-child and multi-project pipelines\n\nAs seen above, the most obvious difference between parent-child and multi-project pipelines is the project\nwhere the pipelines run, but there are are other differences to be aware of.\n\nContext:\n\n- Parent-child pipelines run on the same context: same project, ref, and commit SHA.\n- Multi-project pipelines run on completely separate contexts. The upstream multi-project pipeline can indicate [a ref to use](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html), which can indicate what version of the pipeline to trigger.\n\nControl:\n\n- A parent pipeline _generates_ a child pipeline, and the parent can have a high degree of control over what the child pipeline\n  runs. The parent can even [dynamically generate configurations for child pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n- An upstream pipeline _triggers_ a downstream multi-project pipeline. The upstream (triggering) pipeline does not have much control over the structure of the downstream (triggered) pipeline.\n  The upstream project treats the downstream pipeline as a black box.\n  It can only choose the ref to use and pass some variables downstream.\n\nSide-effects:\n\n- The final status of a parent pipeline, like other normal pipelines, affects the status of the ref the pipeline runs against. For example, if a parent pipeline fails on the `main` branch, we say that `main` is broken.\n  The status of a ref is used in various scenarios, including [downloading artifacts](https://docs.gitlab.com/ee/api/job_artifacts.html#download-the-artifacts-archive) from the latest successful pipeline.\n\n  Child pipelines, on the other hand, run on behalf of the parent pipeline, and they don't directly affect the ref status. If triggered using `strategy: depend`, a child pipeline affects the status of the parent pipeline.\n  In turn, the parent pipeline can be configured to fail or succeed based on `allow_failure:` configuration on the job triggering the child pipeline.\n- A multi-project downstream pipeline may affect the status of the upstream pipeline if triggered using `strategy: depend`,\n  but each downstream pipeline affects the status of the ref in the project they run.\n- Parent and child pipelines that are still running are all automatically canceled if interruptible when a new pipeline is created for the same ref.\n- Multi-project downstream pipelines are not automatically canceled when a new upstream pipeline runs for the same ref. The auto-cancelation feature only works within the same project.\n  Downstream multi-project pipelines are considered \"external logic\". They can only be auto-canceled when configured to be interruptible\n  and a new pipeline is triggered for the same ref on the downstream project (not the upstream project).\n\nVisibility:\n\n- Child pipelines are not directly visible in the pipelines index page because they are considered internal\n  sub-components of the parent pipeline. This is to enforce the fact that child pipelines are not standalone and they are considered sub-components of the parent pipeline.\n  Child pipelines are discoverable only through their parent pipeline page.\n- Multi-project pipelines are standalone pipelines because they are normal pipelines, but just happen to be triggered by an another project's pipeline. They are all visible in the pipeline index page.\n\n## Conclusions\n\nParent-child pipelines inherit a lot of the design from multi-project pipelines, but parent-child pipelines have differences that make them a very unique type\nof pipeline relationship.\n\nSome of the parent-child pipelines work we at GitLab will be focusing on is about surfacing job reports generated in child pipelines as merge request widgets,\ncascading cancelation and removal of pipelines as well as passing variables across related pipelines.\nSome of the parent-child pipeline work we at GitLab plan to focus on relates to:\n\n- Surfacing job reports generated in child pipelines in merge request widgets.\n- Cascading cancelation down to child pipelines.\n- Cascading removal down to child pipelines.\n- Passing variables across related pipelines.\n\nYou can check [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336884) for planned future developments on parent-child and multi-project pipelines.\nLeave feedback or let us know how we can help.\n\nCover image by [Ravi Roshan](https://unsplash.com/@ravi_roshan_inc?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1396,1397,9],{"slug":5057,"featured":6,"template":683},"parent-child-vs-multi-project-pipelines","content:en-us:blog:parent-child-vs-multi-project-pipelines.yml","Parent Child Vs Multi Project Pipelines","en-us/blog/parent-child-vs-multi-project-pipelines.yml","en-us/blog/parent-child-vs-multi-project-pipelines",{"_path":5063,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5064,"content":5070,"config":5075,"_id":5077,"_type":13,"title":5078,"_source":15,"_file":5079,"_stem":5080,"_extension":18},"/en-us/blog/pat-revocation-coming-soon",{"title":5065,"description":5066,"ogTitle":5065,"ogDescription":5066,"noIndex":6,"ogImage":5067,"ogUrl":5068,"ogSiteName":670,"ogType":671,"canonicalUrls":5068,"schema":5069},"Secret Detection update: Leaked Personal Access Tokens will soon be revoked","Learn about upcoming changes to better protect GitLab users and organizations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682562/Blog/Hero%20Images/michael-dziedzic-1bjsASjhfkE-unsplash.jpg","https://about.gitlab.com/blog/pat-revocation-coming-soon","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secret Detection update: Leaked Personal Access Tokens will soon be revoked\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Connor Gilbert\"}],\n        \"datePublished\": \"2023-01-04\",\n      }",{"title":5065,"description":5066,"authors":5071,"heroImage":5067,"date":5072,"body":5073,"category":678,"tags":5074},[2606],"2023-01-04","\n\nGitLab will soon begin automatically revoking Personal Access Tokens ([PATs](https://docs.gitlab.com/ee/user/profile/personal_access_tokens/)) when GitLab [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) finds them in public repositories, an update that will better protect GitLab users and organizations.\n\nLeaked PATs are a serious security risk – adversaries can and do search public repositories to find tokens and misuse them.\nHowever, it's easy to make a mistake and accidentally commit a token into your codebase, especially if you're committing to the main branch of your repository without [reviewing security findings first](https://docs.gitlab.com/ee/user/application_security/#view-security-scan-information-in-merge-requests).\n\nWe're rolling out this feature over time and giving additional notice so you can prepare.\nWe know that leaked PATs may also be used in automated systems and will need to be replaced.\n\nWe've been [dogfooding](/handbook/product/product-processes/#dogfood-everything) this feature within GitLab and with customers who volunteered to join our [beta test](/releases/2022/11/22/gitlab-15-6-released/#beta-automatic-revocation-of-leaked-personal-access-tokens).\nNow, we're glad we can expand this protection to everyone.\n\n## When revocation happens\n\nThis feature protects projects that:\n- are public. Private projects are unaffected by this change.\n- use [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/). If you haven't enabled Secret Detection for a project, we currently won't search it for PATs to revoke.\n\nTokens are revoked in those projects when they:\n- are committed on the default branch of the repository. Merge requests and other non-default branches currently don't trigger revocation.\n- include the `glpat-` prefix, which has been [added to PATs by default since release 14.5](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#personal-access-token-prefix). Because prefixed tokens are easier to identify, we recommend replacing any un-prefixed tokens with new ones that include the `glpat-` prefix.\n\nLeaked tokens are processed on the same system where they're found: Tokens detected on GitLab.com stay on GitLab.com and tokens detected in Self-Managed instances stay on those instances.\n\n## How to get protected\n\nAutomatic PAT revocation is available for projects that use GitLab Secret Detection.\nSecret Detection scanning is [available in all GitLab tiers](https://docs.gitlab.com/ee/user/application_security/secret_detection/#features-per-tier), but automatic PAT revocation is currently [only available in Ultimate projects](https://docs.gitlab.com/ee/user/application_security/secret_detection/post_processing.html#feature-availability).\n\n- To protect a project, [enable GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#enable-secret-detection).\n- To protect your entire organization, consider [enforcing scan execution](https://docs.gitlab.com/ee/user/application_security/index.html#enforce-scan-execution) to run Secret Detection in all of your projects.\n\n## What happens when a PAT leak is discovered\n\nWhen GitLab finds and revokes a PAT, here's what happens:\n- The user whose PAT was leaked receives an email. The email reads: \"We found your token in a public project and have automatically revoked it to protect your account.\"\n- If you use GitLab Ultimate, Secret Detection still reports the leaked token the same way as before. Leaked tokens are noted in the security widget on merge requests, and they're reported in the Vulnerability Report if they're merged to the default branch.\n\nThis video shows how Secret Detection finds a leaked token and how users are notified:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Z_msn_HwmVI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## What to do if your token is revoked\n\nIf your PAT is automatically revoked, that's because it was exposed publicly.\nYou should consider it to be compromised.\n\nYou'll need to create a new one and use it in any CI/CD variables, configurations, or other places where the leaked token was used.\nWe recommend using separate PATs for different use cases.\nFor more recommendations, check our [token security guidance](https://docs.gitlab.com/ee/security/token_overview.html#security-considerations).\n\n## When changes take effect\n\nWe're rolling out this feature in phases. We currently plan to:\n- Enable automatic PAT revocation on GitLab.com on or after **Jan. 23, 2023**.\n- Enable automatic PAT revocation by default for GitLab Self-Managed in the **GitLab 15.9** release, which we'll publish on **Feb. 22, 2023**.\n    - You can opt in early by [enabling](https://docs.gitlab.com/ee/administration/feature_flags.html) the [feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/382610) before this date. You need to be on GitLab 15.7 or higher to use the feature.\n    - You can choose not to enable this protection by disabling the feature flag.\n- Remove the feature flag so that this protection is always active for GitLab.com and GitLab Self-Managed in a **future release**.\n\nWe don't currently plan to [add a configuration option](/handbook/product/product-principles/#convention-over-configuration) to disable this security feature. So, if you choose to disable it, please [tell us why in our feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/385690) so we can accommodate your use case.\n\n### What's next for Secret Detection\n\nWe're excited to release this feature, and we'll keep [iterating](https://handbook.gitlab.com/handbook/values/#iteration) to continue to strengthen the level of protection GitLab Secret Detection provides.\n\nFor more information about where we're taking Secret Detection, check [our public direction page](/direction/secure/static-analysis/secret-detection/).\n\nDisclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\n{: .note}\n\nCover image by [Michael Dziedzic](https://unsplash.com/@lazycreekimages) from [Unsplash.com](https://www.unsplash.com).\n{: .note}\n",[704,678,9],{"slug":5076,"featured":6,"template":683},"pat-revocation-coming-soon","content:en-us:blog:pat-revocation-coming-soon.yml","Pat Revocation Coming Soon","en-us/blog/pat-revocation-coming-soon.yml","en-us/blog/pat-revocation-coming-soon",{"_path":5082,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5083,"content":5089,"config":5093,"_id":5095,"_type":13,"title":5096,"_source":15,"_file":5097,"_stem":5098,"_extension":18},"/en-us/blog/pipeline-editor-overview",{"title":5084,"description":5085,"ogTitle":5084,"ogDescription":5085,"noIndex":6,"ogImage":5086,"ogUrl":5087,"ogSiteName":670,"ogType":671,"canonicalUrls":5087,"schema":5088},"Meet Pipeline Editor, your one-stop shop for building a CI/CD pipeline","The Pipeline Editor reduces the complexity of configuring your CI/CD pipelines.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665961/Blog/Hero%20Images/image_cover.jpg","https://about.gitlab.com/blog/pipeline-editor-overview","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet Pipeline Editor, your one-stop shop for building a CI/CD pipeline\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2021-02-22\",\n      }",{"title":5084,"description":5085,"authors":5090,"heroImage":5086,"date":1669,"body":5091,"category":849,"tags":5092},[1454],"\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-03-02.\n{: .note .alert-info .text-center}\n\nIn GitLab 13.8, we introduced the first iteration of the [Pipeline Editor](/releases/2021/01/22/gitlab-13-8-released/): a dedicated editor designed for authoring your CI/CD. It is your one-stop shop for everything you need to configure your CI/CD pipelines.\n\n## Why do we need a dedicated editor for pipelines?\n\nGitLab's advanced syntax provides a high degree of customization for sophisticated and demanding CI/CD use cases. However, all of this power and flexibility comes with a fair bit of complexity. The Pipeline Editor helps you mitigate this challenge and serves as a single solution that groups all existing CI authoring features in a single location. It is our foundation, and we plan to build on it with enhancements in future iterations. \n\n## Getting started\n\nIn order for the pipeline editor to work, you'll first need to create a `.gitlab-ci.yml` file in your project. The `.gitlab-ci.yml` is a [YAML file](https://en.wikipedia.org/wiki/YAML) where you configure specific GitLab CI/CD instructions. Check out how we are working on [improving the first-time experience of creating a `.gilab-ci.yml` file directly from the Pipeline Editor](https://gitlab.com/groups/gitlab-org/-/epics/5276). \n\n### Continuous validation\nOnce you have created the `.gitlab-ci.yml` file and navigated to it in the Pipeline Editor, you can begin editing your configuration. Writing YAML can be error prone. No matter how technical or skilled you are, programming mistakes happen. Sometimes an indentation will be missed, the incorrect syntax is used, or the wrong keyword is selected, and that's OK! As you start authoring your pipeline, GitLab will inspect the pipeline configuration using our linting APIs and provide you with an indicator of whether your pipeline configuration is valid or not. We will continuously validate your pipeline without making any changes to your pipeline configuration, so you can have confidence in hitting \"merge\" and running your pipeline without any surprises. \n\n![Continuous validation of pipelines](https://about.gitlab.com/images/blogimages/2020-02-08-Pipeline-editor-overview/image1.png){: .shadow.medium.center}\nContinuous validation of your pipelines\n{: .note.text-center}\n\n### Pipeline visualizer: Seeing is believing\nIt's practically impossible to envision what a pipeline should look like when you start writing from a blank YAML file. Luckily, GitLab provides you with a full pipeline view for every running pipeline. But, what if you want to visualize your pipeline _before_ they begin to run? Well, you can do that now by navigating to the \"Visualize\" tab in the Pipeline Editor. You'll find an illustration that shows how your pipeline should look as you write it, similar to the linter, and GitLab will display the visual before making any commits, before running, or before altering your pipeline in any way.\n\nIn the visualization, we will group all your defined pipeline jobs by stages and add links between the jobs based on the [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) relationships you've configured.\n\nIf we take a look at the example below, you can easily see that I've configured a three-stage pipeline, where the build stage has three jobs (step 1-3), and that step 4 needs steps 1 and 3.\n\n![Pipeline editor overview](https://about.gitlab.com/images/blogimages/2020-02-08-Pipeline-editor-overview/image2.png){: .shadow.medium.center}\nPipeline visualizer\n{: .note.text-center}\n\nHere is what the YAML looks like:\n\n ```yaml\nimage: alpine:latest\n\nstages:\n   - test\n   - build\n   - deploy\n\nprepare:\n   script: exit 0\n   stage: test\n\nstep1:\n   script: echo testo\n   stage: build\nstep2:\n   script: echo testo\n   stage: build\nstep3:\n   script: echo testo\n   stage: build\n\nstep4:\n   needs: ['step1', 'step3']\n   script: exit 0\n   stage: deploy\n ```\n\n### View an expanded version of the CI/CD configuration\nWhen configuring pipelines, you use keywords like 'include' and 'extends' often. These keywords help break down one long pipeline configuration file into multiple files, which increases readability and reduces duplication. Unfortunately, those keywords can make a pipeline configuration hard to follow. In some configurations, a pipeline configuration file can be mostly composed of a list of other included configuration files.\n\nTo make the configuration easier to follow, we've added the ability to view a version of your pipeline configuration with all of the 'includes' and 'extends' configurations merged together as a fourth tab in the Pipeline Editor. Now it's much easier to understand more complex pipeline flows and this simplifies the debugging process.\n\nPipeline configuration example:\n\n![pipeline configuration](https://about.gitlab.com/images/blogimages/2020-02-08-Pipeline-editor-overview/image6.png){: .shadow.medium.center}\n\nThe expanded version of the pipeline configuration:\n\n![expanded pipeline configuration](https://about.gitlab.com/images/blogimages/2020-02-08-Pipeline-editor-overview/image7.png){: .shadow.medium.center}\n\n### Lint\n\nThe CI lint helps you validate your pipeline configuration and provides you with additional information about it. That's why we've copied the existing CI linter (which was well hidden in our jobs page) to the Pipeline Editor as a third tab.\n\nThe linter provides you with detailed information about every job you've configured in your pipeline. For each job, it provides the [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script), [after_script](https://docs.gitlab.com/ee/ci/yaml/#after_script), and [script](https://docs.gitlab.com/ee/ci/yaml/#script) fields, tags, environment names, branches it should run, and more…\n\nIf you look at the following example, just by looking at the linter tab you'll know that the `prepare` job:\n* Runs in the `prepare` stage\n* Contains `before_script`, `script`, and `after_scripts` fields \n* Runs only on master \n* Runs upon failure\n* Tag as production\n* Has the environment set to production \n\n![image3](https://about.gitlab.com/images/blogimages/2020-02-08-Pipeline-editor-overview/image3.png){: .shadow.medium.center}\n\nIn this second example, you can see that the build job is a manual job that runs on all branches and is allowed to fail:\n\n![Manual build job](https://about.gitlab.com/images/blogimages/2020-02-08-Pipeline-editor-overview/image5.png){: .shadow.medium.center}\n\n## How the Pipeline Editor came about\n\nEarlier this year, we decided to split continuous integration into two separate teams: [Continuous Integration](/direction/verify/continuous_integration/), which is responsible for improving the experience of running a CI/CD pipeline, and [Pipeline Authoring](/direction/verify/pipeline_composition/), responsible for helping you author your pipeline. We've defined the Pipeline Authoring team goal as, \"Making the authoring experience as easy as possible for both advanced and novice users.\"\n\n![Verify Groups](https://about.gitlab.com/images/handbook/engineering/verify/verify_groups_banner.jpg){: .shadow.center}\n\nAs a team, we realized that a dedicated authoring area is needed to achieve our [ambitious roadmap](https://youtu.be/hInM7JUEH4Y) – this is when the Pipeline Editor idea was formed. \n\n## Try out Pipeline Editor yourself\n\nThat's it! I hope you found this overview useful. To get started with GitLab CI, you can [try out our hosted GitLab.com solution](/free-trial/), or you can [download GitLab Self-Managed](/free-trial/) and read its documentation for more in-depth coverage of the functionality. \n\nIf you are using our Pipeline Editor, we would love it if you leave us a note on our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/298928)! If you'd like to learn more about the upcoming features, feel free to read through the [Pipeline Editor second iteration epic](https://gitlab.com/groups/gitlab-org/-/epics/4814), and tag `@dhershkovitch` if you have any questions.\n",[1396,1397,851,9],{"slug":5094,"featured":6,"template":683},"pipeline-editor-overview","content:en-us:blog:pipeline-editor-overview.yml","Pipeline Editor Overview","en-us/blog/pipeline-editor-overview.yml","en-us/blog/pipeline-editor-overview",{"_path":5100,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5101,"content":5106,"config":5111,"_id":5113,"_type":13,"title":5114,"_source":15,"_file":5115,"_stem":5116,"_extension":18},"/en-us/blog/pre-filled-variables-feature",{"title":5102,"description":5103,"ogTitle":5102,"ogDescription":5103,"noIndex":6,"ogImage":1055,"ogUrl":5104,"ogSiteName":670,"ogType":671,"canonicalUrls":5104,"schema":5105},"How pre-filled CI/CD variables will make running pipelines easier","Learn more about this future release and how pre-filled variables will save time and reduce errors.","https://about.gitlab.com/blog/pre-filled-variables-feature","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How pre-filled CI/CD variables will make running pipelines easier\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-12-02\",\n      }",{"title":5102,"description":5103,"authors":5107,"heroImage":1055,"date":5108,"body":5109,"category":1249,"tags":5110},[2390],"2020-12-02","\n[CI/CD variables](/topics/ci-cd/) are a useful way to customize pipelines based on their environment. But what if you need to override a variable, or what if you need to run a pipeline manually? These scenarios can create problems.\n\n*   What if you don’t know what variables/values to put in?\n*   What happens if you make a mistake?\n\nHaving to enter variables and values manually is tedious and prone to error. Also, a user may not know all the different variables/values they need to enter. In GitLab 13.7, we’re introducing a feature that helps to solve these problems by generating pre-filled variables from your `.gitlab-ci.yml.` file when you run a pipeline.\n\n### What are CI/CD variables?\n\n[CI/CD variables](https://docs.gitlab.com/ee/ci/variables/) are dynamic values assigned to environments. These environment variables affect the way running processes behave on an operating system. Variables allow teams to customize jobs in GitLab CI/CD.\n\nThere are two places where teams can define variables:\n\n*   The `.gitlab-ci.yml.` file\n*   The GitLab Runner `config.toml.` file\n\nCI/CD variables can be very useful, but what if you need to override a variable or manually run a pipeline? You might do this if the results of a pipeline (for example, a code build) are required outside the normal operation of the pipeline. Teams may also opt for manual deployments to production and need to stop the pipeline early. Running a pipeline manually isn’t unusual, but [defining variables](https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html) and entering them in a manual pipeline hasn’t always been a totally smooth process.\n\nFirst, teams need to run a pipeline/job manually and then navigate into the overview. Then, they have to select all the required variables from a drop-down menu on the “Run Pipeline” page. If developers don’t know all the required variables by heart, they will need to check their references and switch back and forth. If there are numerous key/value pairs to enter, this can be especially tedious. \n\n### What are pre-filled variables?\n\nIn 13.7, we’re introducing a feature that will streamline this process. Now the “Run pipeline” form will [generate pre-filled variables](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) for your pipeline based on the variable definitions in your `.gitlab-ci.yml` file. The response to this feature from the GitLab community was enthusiastic.\n\n![pre-filled variables issue](https://about.gitlab.com/images/blogimages/pre-filled-variables.png)\nPeople are excited about pre-filled variables!\n\n### The benefits of pre-filled variables\n\nHaving variables pre-filled is all about increasing efficiency and reducing the small frustrations that make jobs more difficult than they need to be. \n\nPre-filled variables will *reduce:*\n\n*   Frustration with scrolling dropdown values\n*   Friction with choosing the wrong values\n*   Re-running and debugging pipelines due to wrong values\n*   Errors and click actions\n\n![Run Pipeline](https://about.gitlab.com/images/blogimages/Run-pipeline.gif)\nPre-filled variables in action\n\nFor teams that manually deploy to production, pre-filled variables will make it easier during that review step so that everyone with permissions can manually trigger the deployment pipeline. If the reviewer needs to make an exception they can override a variable, if necessary. \n\nPre-filled variables will help teams save time, reduce errors, and make the manual pipeline process a bit smoother. Do you think we're missing something or have ways that we can streamline the process even further? Leave a comment in [the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) and let us know what you think. Everyone can contribute.\n\n### Other future GitLab CI releases\n\nPre-filled variables are only one CI feature in the works. We release [new features](/upcoming-releases/) on the 22nd of every month, and everyone can contribute to these [public](https://handbook.gitlab.com/handbook/values/#public-by-default) issues. \n\n## More on CI/CD\n\n- [Want a more effective CI/CD pipeline? Try our pro tips](/blog/effective-ci-cd-pipelines/)\n- [Webcast: 7 CI/CD hacks](/webcast/7cicd-hacks/)\n- [How to use GitLab’s CI/CD pipeline templates](/blog/get-started-ci-pipeline-templates/)\n\nCover image by [Gerrie van der Walt](https://unsplash.com/photos/m3TYLFI_mDo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/pipes?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[108,9],{"slug":5112,"featured":6,"template":683},"pre-filled-variables-feature","content:en-us:blog:pre-filled-variables-feature.yml","Pre Filled Variables Feature","en-us/blog/pre-filled-variables-feature.yml","en-us/blog/pre-filled-variables-feature",{"_path":5118,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5119,"content":5125,"config":5132,"_id":5134,"_type":13,"title":5135,"_source":15,"_file":5136,"_stem":5137,"_extension":18},"/en-us/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection",{"title":5120,"description":5121,"ogTitle":5120,"ogDescription":5121,"noIndex":6,"ogImage":5122,"ogUrl":5123,"ogSiteName":670,"ogType":671,"canonicalUrls":5123,"schema":5124},"Prevent secret leaks in source code with GitLab Secret Push Protection","Learn how Secret Push Protection, now generally available, adds to a defense-in-depth detection strategy and decreases the resources needed to remediate secret leaks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097761/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097761137.png","https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Prevent secret leaks in source code with GitLab Secret Push Protection\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amar Patel\"},{\"@type\":\"Person\",\"name\":\"Sara Meadzinger\"}],\n        \"datePublished\": \"2024-06-24\",\n      }",{"title":5120,"description":5121,"authors":5126,"heroImage":5122,"date":5128,"body":5129,"category":704,"tags":5130,"updatedDate":5131},[5127,1953],"Amar Patel","2024-06-24","Secret Push Protection is now generally available for all GitLab Ultimate and GitLab Dedicated customers. [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/) blocks secrets such as keys and API tokens from being pushed to GitLab. The content of each commit is checked for [high-confidence secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html) when pushed to GitLab. If any high-confidence secrets are detected, the push is blocked. By protecting secrets from leaking in the first place, your team can greatly reduce risk and reduce time spent on rotating secrets.\n\n## The risk of leaked secrets\n\nSecrets, such as tokens and API keys, are frequently used by applications to authenticate and provide access to sensitive data. Developers sometimes inadvertently hardcode these secrets, and then push that code into source management systems, like GitLab. Hardcoded secrets stored in plain text are a low-effort, high-value target for malicious actors, as numerous recent high-profile breaches have demonstrated. Secrets do not require any special skills to exploit and many secrets do not automatically expire. Therefore, once a malicious actor has access to a secret, they can continue using it indefinitely to cause data breaches, service disruptions, IP theft, source code theft, and software supply chain compromises. Both [Verizon’s annual Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir) and [IBM’s annual Cost of a Data Breach report](https://www.ibm.com/reports/data-breach) have repeatedly reported that compromised credentials, which include secrets, are one of the most frequent and expensive source of breaches. \n\nIBM’s research also indicates that taking a DevSecOps, or shift-left, approach is the most effective way to reduce the average cost of a data breach. Until now, GitLab’s primary secret detection method has been [Pipeline Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/), which scans committed files after they have been pushed to GitLab and identifies secrets that are already leaked. Once a secret has leaked, it should be considered compromised and must be rotated according to the steps outlined by the secret issuer. Remediating detected secrets requires security teams and developers to work closely together to follow the steps outlined by a secret issuer to rotate the leaked secret. It can be a tedious, confusing, and risky process. Utilizing GitLab’s Secret Push Protection feature, you can shift secret detection further left, protect your secrets from leaking in the first place, and reduce the amount of time and energy required to remediate leaks.\n\n## How Secret Push Protection works\nOnce [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/) is enabled on a project, developers are blocked from pushing code to projects that contain any high-confidence secrets. This ensures a performant experience when pushing your code and also results in a lower number of false alerts. **Note:** Here is the [list of high-confidence patterns Secret Push Protection supports](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/detected_secrets.html). \n\nWhile we are checking the contents of each commit, we've [excluded](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/#coverage) a number of factors in order to optimize the performance of this workflow. Because of this, we recommend using Secret Push Protection in a layered approach alongside [Pipeline Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline). Using both features in tandem maximizes coverage to identify more leaked secrets across the software development lifecycle.\n\n# Get started with Secret Push Protection\n\nWe've put a video playlist together to help you get started on using this feature:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/videoseries?si=kRG65YbljQ-Nu2wa&list=PL05JrBw4t0KoADm-g2vxfyR0m6QLphTv-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Enable Secret Push Protection\n\nOn GitLab Dedicated and Self-managed, you must allow the use of Secret Push Protection in your instance and then enable it per project. On GitLab.com, you only need to enable it per project.\n\nYou must have at least the Maintainer role to enable push protection for the project.\n\n1. On the left sidebar, select **Search** or **Go to** and find your project.\n1. On the left sidebar, select **Secure > Security configuration**.\n1. Turn on the Secret Push Protection toggle.\n\n![secret push protection - toggle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097769/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-10-18_at_12.24.47_PM_aHR0cHM6_1750097769198.png)\n\n## Skip push protection\n\nIn some instances, when a push is blocked, you might find it necessary to skip Secret Push Protection. For example, a developer may need to commit a placeholder secret for testing. You can skip Secret Push Protection via a Git option or commit message, meeting developers in whichever Git client they are using. \n\n## Add exclusions\n\nWe released exclusions, giving you flexibility to exclude certain paths, rules from the default ruleset, or raw values from being scanned, detected, and blocked by push protection. From the Security Configuration page, Maintainers and project Owners can manage push protection exclusion lists within the UI on a per-project basis. \n\n![secret push protection - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097769/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097769199.png)\n\n## Audit events\n\nDisabling Secret Push Protection, or even skipping it altogether, can prove to be costly if not done for the appropriate reasons. We've introduced [audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) to help administrators and security teams understand where and how this feature is being used, and to assist in any secrets-related investigations.\n\nWe currently log audit events when Secret Push Protection is: \n\n- enabled/disabled at an instance level\n- enabled/disabled at project level\n- skipped via a push option\n- skipped via a commit message \n\nAnd when an exclusion is:\n- created\n- updated\n- deleted \n\n![secret push protection - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097769/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097769200.png)\n\nThese audit events can be used in conjunction with [audit event streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/) to manage audit logs in third-party systems (like SIEMs), enabling customers to capture trends such as: how many times push protection is being skipped; which projects frequently bypass push protection; and which secrets are commonly skipped and may need to be excluded moving forward. \n\n# Dogfooding Secret Push Protection\n\nWe [dogfood everything](https://about.gitlab.com/handbook/engineering/development/principles/#dogfooding) here at GitLab. We've [collaborated](https://gitlab.com/groups/gitlab-org/-/epics/13523) with various teams across the organization to enable this feature across key projects, including our primary GitLab codebase. This process has enabled us to identify and address improvements early in the development process, and it has increased our confidence in the stability, performance, and customer workflows for the release of this feature.\n\n# What's next\n\nYou can help us improve this feature by commenting on [this Secret Push Protection feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/467408). We’ll incorporate your feedback and make [additional improvements](https://gitlab.com/groups/gitlab-org/-/epics/13107) as we continue to add new capabilities to the feature.\n\n> Learn more about the [Secret Push Protection](https://docs.gitlab.com/ee/user/application_security/secret_detection/secret_push_protection/).\n\n# Read more\n\n- [How Secret Detection can proactively revoke leaked credentials](https://about.gitlab.com/blog/how-secret-detection-can-proactively-revoke-leaked-credentials) \n- [How to implement secret management best practices with GitLab](https://about.gitlab.com/the-source/security/how-to-implement-secret-management-best-practices-with-gitlab/)\n- [GitLab native secrets manager to give software supply chain security a boost](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost)",[704,746,9,478,701],"2024-10-17",{"slug":5133,"featured":6,"template":683},"prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection","content:en-us:blog:prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection.yml","Prevent Secret Leaks In Source Code With Gitlab Secret Push Protection","en-us/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection.yml","en-us/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection",{"_path":5139,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5140,"content":5146,"config":5151,"_id":5153,"_type":13,"title":5154,"_source":15,"_file":5155,"_stem":5156,"_extension":18},"/en-us/blog/progressive-delivery-using-review-apps",{"title":5141,"description":5142,"ogTitle":5141,"ogDescription":5142,"noIndex":6,"ogImage":5143,"ogUrl":5144,"ogSiteName":670,"ogType":671,"canonicalUrls":5144,"schema":5145},"Progressive Delivery: How to get started with Review Apps","Progressive Delivery is the next evolution of continuous delivery, and Review Apps are a key enabler.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666841/Blog/Hero%20Images/progressive-delivery-review-apps.jpg","https://about.gitlab.com/blog/progressive-delivery-using-review-apps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Progressive Delivery: How to get started with Review Apps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-04-19\",\n      }",{"title":5141,"description":5142,"authors":5147,"heroImage":5143,"date":5148,"body":5149,"category":849,"tags":5150},[846],"2019-04-19","\nIf you're not familiar with [Progressive Delivery](https://redmonk.com/jgovernor/2018/08/06/towards-progressive-delivery/),\nit's a new set of best practices that is gaining hold for delivering safely and frequently to\nproduction. Although it's not a completely new idea in the same way that continuous\ndelivery originally was, it is a clear evolution of those ideas that brings something\nnew to the table. By taking a step back and considering the corpus of knowledge and experience\ngained over the last 10 years, then applying a bit of systems thinking to\nhow all these different practices interact with emerging technologies, it has set a new\nbaseline for how software delivery can be done effectively.\n\nWe discuss our overall vision for Progressive Delivery on our [CI/CD vision page](/direction/ops/#progressive-delivery),\nwhich also links to a few more resources if you're not up to speed with the concept in general.\n\nIn summary, though, continuous delivery gets you out of the mode of shipping one, big, risky\ndeployment to production, and instead breaks that risk up into many tiny parts – each with a\nfraction of the risk. Progressive Delivery takes this a step further by enabling you to\n[canary test code](https://docs.gitlab.com/ee/user/project/canary_deployments.html) in\nproduction with a small portion of your user base, use [feature flags](https://docs.gitlab.com/ee/operations/feature_flags.html)\nto manage rollout pacing, tie everything together with [tracing](https://docs.gitlab.com/ee/operations/tracing.html),\nand automate the further deployment or rollback of that code depending on how it performs.\n\n## How Review Apps can help enable Progressive Delivery\n\nLet me begin by explaining what GitLab Review Apps are:\n\n[GitLab Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) are\nstaging environments that are automatically created for every branch and/or merge request. They are a collaboration tool\nbuilt into GitLab that helps take the hard work out of providing an environment to\nshowcase or validate product changes. There are a lot of different ways to configure\nthem, but the recommended way is to automatically create review app instances during your\n[merge request pipelines](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html). Doing this\nwill ensure that any merge request that is being considered will have an application\nthat developers can connect to to validate their changes.\n\nWith GitLab, we go a step beyond simply creating the review environment: we make it accessible.\n\nOnce configured, on your merge request page you'll now see a \"view app\" button that, as long as your\n[route maps](https://docs.gitlab.com/ee/ci/review_apps/#route-maps) are configured correctly, will allow your\nusers to jump right to the changed content. Review apps do work even without the route maps – in that case\nthey will take you to the home page of your app – but with them they almost feel like magic.\n\n![Review app](https://docs.gitlab.com/ee/ci/review_apps/img/review_apps_preview_in_mr.png \"Review app\"){: .shadow.medium.center}\n\nReview apps are a powerful tool on their own for enabling quick iteration, but if we think about\nthem in the context of Progressive Delivery, a whole new set of possibilities opens up.\n\n## Review apps for progressive validation\n\nAs mentioned above, a typical Progressive Delivery flow involves using targeted feature flags to validate\nchanges as they flow to production environments. Review apps, if configured to point to production\ndata/endpoints instead of ephemeral data, can serve as a merge request-based window into the changes\nthat are being considered for release.\n\nSome of this will of course depend on your code, your testing procedures, and environments. You may\npoint review apps at production endpoints from the moment they are spun up, or perhaps only later\nin your merge request pipeline after some initial validation.\n\nSince anyone can use these environments, you can point anyone with a stake in the success of the\nnew feature to the review app, and they are able to see the live behavior, using their own real\ndata, immediately in their own web browser. This is incredibly powerful for enabling rapid feedback\nand iteration. As a preview, we're also looking to improve this capability by adding an\n[easy-to-use review interface for collecting feedback](https://gitlab.com/gitlab-org/gitlab-ee/issues/10761)\nright into review apps directly.\n\n## Feature flags and tracing\n\nWe can take this idea even one more step further. Using [per-environment feature flag behaviors](https://docs.gitlab.com/ee/operations/feature_flags.html#define-environment-specs), we\ncan control the behavior of the review app environment in any way that the production environment can\nbe controlled. This opens up the possibility of validating any combination.\n\nFinally, since review apps are built and deployed from GitLab CI/CD, all the predefined CI/CD environment\nvariables are available to the deploy script. You could configure your application to use your\nmerge request ID (`CI_MERGE_REQUEST_ID`) as its unique ID for transaction tracing, tying transactions\nin the system automatically to the appropriate GitLab merge request.\n\n## As you can see, there's a ton of potential for Progressive Delivery here\n\nReview apps don't replace\nthe role of feature flags in a Progressive Delivery pipeline, but they provide an incredible\nsupplement that enables segmented validation in a completely new way. All in all, it's such an exciting time for\ncontinuous delivery – there's so much innovation happening on the process and technology fronts, and I'm\ncertain we're only scratching the surface of where we're headed.\n\nReview Apps is just one way [GitLab CI/CD](/solutions/continuous-integration/) enables Progressive Delivery. Join us for our webcast _Mastering continuous software development_ and learn how GitLab’s built-in CI/CD helps teams implement Progressive Delivery workflows, without the complicated integrations and plugin maintenance.\n\n[Watch the GitLab CI/CD webcast](/webcast/mastering-ci-cd/)\n{: .alert .alert-gitlab-purple .text-center}\n\nIf you have more ideas on how to use review apps even more effectively, or where you see the technology\nevolving next, please share in the comments.\n\nPhoto by [Helloquence](https://unsplash.com/photos/5fNmWej4tAA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[108,9,1396],{"slug":5152,"featured":6,"template":683},"progressive-delivery-using-review-apps","content:en-us:blog:progressive-delivery-using-review-apps.yml","Progressive Delivery Using Review Apps","en-us/blog/progressive-delivery-using-review-apps.yml","en-us/blog/progressive-delivery-using-review-apps",{"_path":5158,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5159,"content":5164,"config":5170,"_id":5172,"_type":13,"title":5173,"_source":15,"_file":5174,"_stem":5175,"_extension":18},"/en-us/blog/project-management-using-gitlab-platform",{"title":5160,"description":5161,"ogTitle":5160,"ogDescription":5161,"noIndex":6,"ogImage":2932,"ogUrl":5162,"ogSiteName":670,"ogType":671,"canonicalUrls":5162,"schema":5163},"Can DevOps and project management co-exist? Yes, on the daily at GitLab","Stay agile by using GitLab for DevOps project management","https://about.gitlab.com/blog/project-management-using-gitlab-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Can DevOps and project management co-exist? Yes, on the daily at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vick Kelkar\"}],\n        \"datePublished\": \"2021-05-11\",\n      }",{"title":5160,"description":5161,"authors":5165,"heroImage":2932,"date":5167,"body":5168,"category":849,"tags":5169},[5166],"Vick Kelkar","2021-05-11","\n\nGitLab is best known as an all-in-one DevOps platform, but it is also an effective tool for project management. Non-technical teams at GitLab, such as [the Marketing team](/blog/gitlab-for-project-management-one/), use the GitLab DevOps platform for project management, and recently the Alliances team learned that DevOps and project management work well for our purposes.\n\n## About the IBM partnership\n\n[GitLab recently launched a partnership with IBM](/press/releases/2021-01-14-gitlab-IBM-to-support-acceleration-of-devops-automation.html) to help the organization automate their DevOps platform. Since I work on the Alliances team, I needed an efficient, compatible, and high-performance project management application to manage the many moving parts of the GitLab and IBM partnership as well as other projects related to our partnerships.\n\nMy very first instinct was to test a few of the project management web applications on the market, but this would involve a tedious process of convincing my colleagues to join me on this journey to explore a sprawling new set of tools. Then I thought why not explore our own Gitlab DevOps platform as a project management tool? The beauty of GitLab is that it is a [DevOps platform](https://www.youtube.com/watch?v=wChaqniv3HI) delivered as a single easy-to-use application.\n\nSome of my early questions were:\n\n- Can the GitLab DevOps platform work as a project management tool for the strategic Alliance team?\n- Can GitLab manage and track business activities over a period of time?\n- Can team members collaborate and manage various projects using a single application?\n\nIn the end, the journey to adopting GitLab as a DevOps platform and project management tool was similar to the journey many of our customers experience. In this blog post, I will dive deeper into how the Alliance team uses GitLab for project management, explain how we used GitLab to onboard a new strategic partner, and launched support of [GitLab Ultimate for IBM Cloud Paks](https://www.ibm.com/products/gitlab-ultimate). All the pre- and post-onboarding activities in particular required collaboration and contributions from various teams across the organization.\n\n## Applying DevOps features to project management\n\n### About epics and roadmaps\n\nWhy organize work into a hierarchy? I began the strategic partnership effort by organizing the work into multi-level epics. The [idea behind epics is to aggregate similar work](https://docs.gitlab.com/ee/user/group/epics/#epics) (or issues) into epics and manage delivery of work. In the example below, you'll see the top-level epic was called \"IBM cloud paks\" which contained three child epics.\n\n![An example of a multi-level epics from the IBM cloud paks project](https://about.gitlab.com/images/blogimages/proj-mgmt-epic.png){: .shadow.medium.center}\nWork is divided into three time-bound levels for the IBM cloud paks project: Pre-launch, 0-90 days, and 90-180 days.\n{: .note.text-center}\n\nAnother way to represent the epics is through a [roadmap view](https://docs.gitlab.com/ee/user/group/roadmap/#roadmap). The main advantage of this feature is that it allows the collaborators on epics and issues to monitor project progress using a calendar timeline view.\n\n![An example of a project management timeline for the IBM cloud paks project using the epics roadmap view](https://about.gitlab.com/images/blogimages/proj-mgmt-timeline.png){: .shadow.medium.center}\nThe same IBM cloud paks project epic is depicted using the Roadmap view, which adopts a timeline view.\n{: .note.text-center}\n\n### How issues are used to capture work\n\nClick into any of the epics to find a set of issues that make up the epic. I use [issues as the basic unit of work](https://docs.gitlab.com/ee/user/project/issues/). Contained within the \"IBM cloud paks: Pre-launch\" epic are 33 issues.\n\n![The list view shows inside the \"IBM cloud paks: Pre-launch\" epic are 33 issues](https://about.gitlab.com/images/blogimages/proj-mgmt-issue.png){: .shadow.medium.center}\nInside the \"IBM cloud paks: Pre-launch\" epic are 33 issues\n{: .note.text-center}\n\nOne thing to note is that an issue can have a single assignee or owner, or it can have multiple assignees.\n\n### How to use issue boards\n\nAn [agile board](/blog/gitlab-for-agile-portfolio-planning-project-management/) can help a user visualize work and manage all the open threads in a given epic and/or project. The board can help you move issues efficiently through various phases of work. On the Alliances team, we are always iterating on how to better track the status of issues. [Here is more information about the current status flows for the Alliances team](/handbook/alliances/#status-alliance---status--status).\n\nThe screenshot below shows how an [issue board can be applied as a Kanban board by filtering for the \"IBM\" label](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards). To see transitions between work stages, use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels), which are mutually exclusive and represent transitions between various workflow statuses, such as \"status::1\" and \"status::2\"\n\n![Kanban board showing how labels can be used to organize issues into work stages](https://about.gitlab.com/images/blogimages/proj-mgmt-board.png){: .shadow.medium.center}\nHow we use boards for the IBM cloud paks project.\n{: .note.text-center}\n\n### Milestones help time-box events\n\nWhile an epic is a collection of related issues, [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), and sub-epics and is generally used to scope a long-running initiative or program (e.g., a marketing campaign or a new product category) epics can also contain smaller, more discrete and timeboxed events, such as monthly releases or calendar quarters. These [timeboxes are represented as Milestones](https://docs.gitlab.com/ee/user/project/milestones/), which roll up issues and merge requests in the same way as higher-level epics. Apply the \"Milestone view\" to track progress on the smaller deliverables within an epic.\n\n![Milestone view showing Alliances team projects](https://about.gitlab.com/images/blogimages/proj-mgmt-milestone.png){: .shadow.medium.center}\nHow milestones can be used to track work progress within a specific time frame.\n{: .note.text-center}\n\n### How Milestone burnup and burndown charts chart progress\n\n[Burnup and burndown charts are used by project managers to measure progress](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html). Burndown charts analyze how much work is left in a project before it can be finished successfully. Burnup charts measure the work that has been done against the total work for the project. Both types of charts are available in the GitLab DevOps platform. I relied mostly on epics and milestones to track work progress for the IBM partnership.\n\n![burndown](https://about.gitlab.com/images/blogimages/proj-mgmt-burndown.png){: .shadow.medium.center}\nThe burdown and burnup charts for the IBM cloud paks partnership project.\n{: .note.text-center}\n\n### Inside analytics and insights project management tools\n\nMost project management tools are great at capturing project details, and can help answer questions such as \"where does the project stand on actual vs. planned activities?\" or can help track progress using milestones and due dates. [Project analytics and insights dashboards](https://docs.gitlab.com/ee/user/analytics/#project-level-analytics) are built into the GitLab DevOps platform. There are many built-in analytics dashboards, such as CI/CD, code review, merge requests, and issues. For the IBM partnership project, I used the [issues dashboard analytics](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html) to see how many issues were opened compared to how many issues were closed. This tool helped me manage the team capacity and identify any bottlenecks in the project.\n\n![The insights dashboard shows how many issues were opened and closed](https://about.gitlab.com/images/blogimages/proj-mgmt-insights.png){: .shadow.medium.center}\nThe insights dashboard shows many issues were opened vs. how many issues were closed each month.\n{: .note.text-center}\n\n[Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) is a particularly unique feature of GitLab's analytics suite. Since GitLab is a complete DevOps platform with a single data store, GitLab can automatically generate reports to not only identify high-level metrics and blockers, but also drill down into those blockers and improve value flow with just a few clicks.\n\n![Showing recent project activity: 32 new issues and 19 commits](https://about.gitlab.com/images/blogimages/proj-mgmt-analysis.png){: .shadow.medium.center}\nAnalytics showing recent project activity.\n{: .note.text-center}\n\nThe Value Stream Analytics provides a high-level view into common stages of the SDLC out-of-the-box, making it easier to monitor the overall workflow from discussion to code changes, through review and collaboration, and out to production – with no additional work required. And since the code changes and collaboration are happening within GitLab, just one click on an item will take you to the blocked issue or merge request, so you can comment, reassign, or contribute to move things along.\n\nSince all the necessary data is already in GitLab's system, customizing Value Stream Analytics can be completed in just a few clicks: Hiding and reordering stages and even creating your own with simple drop-down menus.\n\n![The customized value stream shows the average amount of time spent in the selected stage for each item](https://about.gitlab.com/images/blogimages/proj-mgmt-valuestream.png){: .shadow.medium.center}\nThe custom value stream above shows the number of days to completion.\n{: .note.text-center}\n\n## DevOps platform and project management in one\n\nThere are many project management tools in the marketplace and solutions for managing the SDLC of a project. The GitLab DevOps platform and project management tool satisfied my need to track partnership-related activities while also managing the technical demos and workshops developed for the IBM partnership. I look forward to continuing to explore the constantly-evolving GitLab platform to grow and manage our strategic partnerships on the Alliances team.\n\nCover image by [Martin Sanchez](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/MD6E2Sv__iA)\n{: .note.text-center}\n",[1164,829,9,998,894],{"slug":5171,"featured":6,"template":683},"project-management-using-gitlab-platform","content:en-us:blog:project-management-using-gitlab-platform.yml","Project Management Using Gitlab Platform","en-us/blog/project-management-using-gitlab-platform.yml","en-us/blog/project-management-using-gitlab-platform",{"_path":5177,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5178,"content":5184,"config":5190,"_id":5192,"_type":13,"title":5193,"_source":15,"_file":5194,"_stem":5195,"_extension":18},"/en-us/blog/protecting-manual-jobs",{"title":5179,"description":5180,"ogTitle":5179,"ogDescription":5180,"noIndex":6,"ogImage":5181,"ogUrl":5182,"ogSiteName":670,"ogType":671,"canonicalUrls":5182,"schema":5183},"How to limit access to manual pipeline gates and deployments using GitLab","Let's look at how to use protected environments to set up access controls for production deployments and manual gates.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681105/Blog/Hero%20Images/protect_manual_jobs.jpg","https://about.gitlab.com/blog/protecting-manual-jobs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to limit access to manual pipeline gates and deployments using GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Thao Yeager\"}],\n        \"datePublished\": \"2020-02-20\",\n      }",{"title":5179,"description":5180,"authors":5185,"heroImage":5181,"date":5187,"body":5188,"category":849,"tags":5189},[5186],"Thao Yeager","2020-02-20","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-02-21.\n{: .alert .alert-info .note}\n\nIn our world of automation, why would anyone want to do something manually? Manual has become almost synonymous with inefficient. But, when it comes to CI/CD pipelines, a properly configured **manual** job can be a powerful way to control deployments and satisfy compliance requirements. Let’s take a look at how manual jobs can be defined to serve two important use cases: Controlling who can deploy, and setting up manual gates.\n\n## Limit access to deploy to an environment\n\nDeploying to production is a mission-critical occurence that should be protected. Projects with a Kubernetes cluster could benefit from moving to a continuous deployment (CD) model in which a [branch or merge request, once merged, is auto-deployed to production](https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-deploy), and the absence of human intervention avoids mishaps. But for projects not yet configured for CD, let's consider this use case: Imagine a pipeline with a manual job to deploy to prod, which can be triggered by any user with access to push code. The risk of a unplanned, unintended production deployment is very real.\n\nFortunately, it’s possible to use [protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments/) to prevent just anyone from deploying to production. When [configuring a protected environment](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments), you can define the roles, groups, or users to whom deploy access is granted. The protected environment can then be defined in a manual job to deploy which limits who can run it. The configuration could look something like this:\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  environment:\n    name: production\n    url: https://example.com\n  when: manual\n  only:\n    - master\n```\n\nIn the example above, the keyword `environment` is used to reference a protected environment (as [configured in project settings](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environment)) with a list of users who can run the job, in this case deploy to the named environment. Users without access see a disabled **play** button and are unable to execute the job.\n\n## Add an approval step\n\nCompliance rules may specify that approval is required for certain activities in a workflow, even if they aren't technically a deployment step themselves. In this use case, an approval step can also be added in the pipeline that prompts an authorized user to take action to continue. This can be achieved by structuring your pipeline with an \"approve\" stage containing a special manual job – for example, the YAML to insert an approval stage before deployment could look like this:\n\n```yaml\nstages:\n  - build\n  - approve\n  - deploy\n\nbuild:\n  stage: build\n  script:\n    - echo Hello!\n\napprove:\n  stage: approve\n  script:\n    - echo Hello!\n  environment:\n    name: production\n    url: https://example.com\n  when: manual\n  allow_failure: false\n  only:\n    - master\n\ndeploy:\n  stage: deploy\n  script:\n    - echo Hello!\n  environment:\n    name: production\n    url: https://example.com\n  only:\n    - master\n```\n\nIn the YAML above, `allow_failure: false` [defines the manual job as \"blocking\"](https://docs.gitlab.com/ee/ci/yaml/#whenmanual), which will cause the pipeline to pause until an authorized user gives \"approval\" by clicking on the **play** button to resume. Only the users part of that environment list will be able to perform this action. In this scenario, the UI view of the pipeline in the example CI configuration above would look like this:\n\n![Pipeline view of approval stage manual job](https://about.gitlab.com/images/blogimages/manual_job_approve_stage_ui.png){: .shadow}\n\n## Summary\n\nAs illustrated in the YAML examples and image above, manual jobs defined with protected environments and blocking attributes are effective tools for handling compliance needs as well as for ensuring there are proper controls over production deployments.\n\nTell us how using protected environments with manual jobs has secured your deployments or whether blocking manual jobs helps you meet compliance and auditing. [Create an issue in the GitLab project issue tracker](https://gitlab.com/gitlab-org/gitlab/issues/new) to share your feedback with us.\n\nCover image by [Diane Walton](https://unsplash.com/photos/BNnzmBmnPg4) on [Unsplash](https://unsplash.com)\n{: .note}\n",[108,976,894,9,851],{"slug":5191,"featured":6,"template":683},"protecting-manual-jobs","content:en-us:blog:protecting-manual-jobs.yml","Protecting Manual Jobs","en-us/blog/protecting-manual-jobs.yml","en-us/blog/protecting-manual-jobs",{"_path":5197,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5198,"content":5204,"config":5208,"_id":5210,"_type":13,"title":5211,"_source":15,"_file":5212,"_stem":5213,"_extension":18},"/en-us/blog/publishing-a11y-reports-in-gitlab-pages",{"title":5199,"description":5200,"ogTitle":5199,"ogDescription":5200,"noIndex":6,"ogImage":5201,"ogUrl":5202,"ogSiteName":670,"ogType":671,"canonicalUrls":5202,"schema":5203},"Publishing Accessibility Reports in GitLab Pages","How to setup the Automated Accessibility Scanning feature in GitLab and publish the report to GitLab Pages.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681293/Blog/Hero%20Images/a11y-report-html.jpg","https://about.gitlab.com/blog/publishing-a11y-reports-in-gitlab-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Publishing Accessibility Reports in GitLab Pages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"James Heimbuck\"}],\n        \"datePublished\": \"2020-05-11\",\n      }",{"title":5199,"description":5200,"authors":5205,"heroImage":5201,"date":4147,"body":5206,"category":1353,"tags":5207},[4107],"\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAt GitLab, we believe [everyone can contribute](/company/strategy/#contribute-with-gitlab) and we build software that reinforces this concept and helps others live up to that value. We also believe that bringing test data to developers as quickly as possible following a commit is one of the best ways to shorten cycle times and deliver features to customers more efficiently. The Automated Accessibility testing in GitLab is one area of that testing.\n\nBut how can we share the results of these accessibility scans with others in our organization outside of the context of the Merge Request? Taking inspiration from another [blog post](https://about.gitlab.com/blog/publish-code-coverage-report-with-gitlab-pages/) and making use of [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) I set out to do just that.\n\n## What is accessibility testing? \n\nI talked about accessibility testing, why it's important, and our vision for this category in a [previous post](https://about.gitlab.com/blog/introducing-accessibility-testing-in-gitlab/). It's worth your time to take a few minutes and read that first if you haven't already.\n\nIf you read the blog, welcome back! Now, let's get to HOW you can use this new feature. After some initial testing, I wanted to record a video showing how to use this new feature. I ran into some problems though, some of my own making and some unexpected. I thought a blog would be great follow-up to that [video](https://www.youtube.com/watch?v=LsW5D5HhuyE) and help explain some of what I ran into. Let's get to it!\n\n## Setting up accessibility testing in GitLab\n\nIntroduced as part of the [Minimum Viable Change](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) to make testing accessibility easier, we created a template that can be included into your project's .gitlab-ci.yml file and adds the accessibility testing job to your pipeline. You can do this at any point throughout your pipeline but, ultimately, we want to decrease that cycle time between when a change is made and when an accessibility issue is found for the developer. To accomplish this, we will run the job AFTER our change is deployed to a review application.\n\nI created a walkthrough for the GitLab Unfiltered YouTube channel to walk through the process of setting this up. After some trial and error I got this working. The relevant portion of the resulting .gitlab-ci.yml entry is below.\n\n```yml\n\nstages:\n - build\n - test\n - deploy review\n - deploy staging\n - accessibility\n - deploy production\n - production tests\n - cache\n\ncache:\n  key: ${CI_COMMIT_REF_SLUG}\n  policy: pull\n  paths:\n    - node_modules/\n\ninclude:\n  - template: \"Verify/Accessibility.gitlab-ci.yml\"\n\nvariables:\n  STAGING_DOMAIN: nimblealizer-staging.surge.sh\n  PRODUCTION_DOMAIN: nimblealizer.surge.sh\n  a11y_urls: \"http://nimblealizer-staging.surge.sh\"\n\n```\n\nTo summarize what changed to add the accessibility job:\n\n1. Add the stage for accessibility. It is important to note that this happens AFTER the deploy to staging, which is the site I want to scan.\n2. Include the template that runs the test.\n3. Add the ally_urls variable so the template knows what to scan. In this case I added the staging site URL to scan.\n\n## What happens now?\n\nAfter committing this change, a pipeline will kickoff that builds the website, runs some tests, deploys to staging, and then runs the accessibility scan.\n\nThe result of this scan is shown on the Merge Request page just by including the template because it is using the `artifacs:expose_as` keyword. This is great news for the developer since the report is now easy to view. The Pa11y engine also produces a  an easy to read report that explains where issues are in the code and provide links to information about how how to resolve them.\n\n![Accessibility report as a build artifact](https://about.gitlab.com/images/blogimages/publish_a11y_reports/a11y-merge-request-build-artifact.png){: .shadow}\nThe resulting build artifact on the Merge Request Pages\n{: .note.text-center}\n\nBut what if we wanted to share this report across the organization, or even better link to it from other places like group dashboards? Then we have an issue. The job value will always be changing and we don't want to force other things to update to reflect our change. What if instead we could publish this report to the same place every time, so that the latest version was always at the same URL?\n\n## GitLab pages to the rescue!\n\nIn my 6 months as the Product Manager for the Testing categories, I had probably already sent the link to this [excellent blog](https://about.gitlab.com/blog/publish-code-coverage-report-with-gitlab-pages/) from Grzegorz a dozen or more times to customers, prospects or coworkers explaining how to publish a coverage report through Pages. I had a strong suspicion that we could do the same thing with the HTML report that came out of the accessibility scan. I followed along with the blog post and after some trial and error, I was able to get the deploy job running and the accessibility report published! All I had to do was navigate to where pages publishes by default and . . . well dang it.\n\n![404 page](https://about.gitlab.com/images/blogimages/publish_a11y_reports/a11y-404.png){: .shadow}\nThat didn't go according to plan\n{: .note.text-center}\n\nAfter I ended the video I realized my mistake and made some changes to the .gitlab-ci.yml in order to publish the report in a cleaner fashion. Now after moving the generated file to the public directory it is renamed index.html. You can see this in the example project's [.gitlab-ci.yml file](https://gitlab.com/jheimbuck_gl/my-static-website/-/blob/master/.gitlab-ci.yml). You can see the latest report [here](https://jheimbuck_gl.gitlab.io/my-static-website/).\n\n## Summary\n\nSo I spent an hour and a half of wall clock time I got it all working which wasn't great but overall not bad since I hadn't tried it before. As I said in the video I thought a blog would help explain some of the issues I ran into and help you get this setup done quicker. I hope this post has inspired you to add an accessibility job to your existing Gitlab pipeline and maybe even post that report to a Pages site so it is available for more of your team to use.\n",[108,9],{"slug":5209,"featured":6,"template":683},"publishing-a11y-reports-in-gitlab-pages","content:en-us:blog:publishing-a11y-reports-in-gitlab-pages.yml","Publishing A11y Reports In Gitlab Pages","en-us/blog/publishing-a11y-reports-in-gitlab-pages.yml","en-us/blog/publishing-a11y-reports-in-gitlab-pages",{"_path":5215,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5216,"content":5222,"config":5227,"_id":5229,"_type":13,"title":5230,"_source":15,"_file":5231,"_stem":5232,"_extension":18},"/en-us/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai",{"title":5217,"description":5218,"ogTitle":5217,"ogDescription":5218,"noIndex":6,"ogImage":5219,"ogUrl":5220,"ogSiteName":670,"ogType":671,"canonicalUrls":5220,"schema":5221},"Quick vulnerability remediation with GitLab Advanced SAST + Duo AI ","Shorten your mean time to remediation by pairing Advanced SAST and artificial intelligence. This detailed demo shows you how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098458/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945_24mPf16vAPHORs3d9y62q_1750098458538.png","https://about.gitlab.com/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Quick vulnerability remediation with GitLab Advanced SAST + Duo AI \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-10-22\",\n      }",{"title":5217,"description":5218,"authors":5223,"heroImage":5219,"date":5224,"body":5225,"category":806,"tags":5226},[2234],"2024-10-22","With GitLab 17.4, we’ve made [GitLab Advanced SAST generally available](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/). [GitLab Advanced SAST](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html) is a static application security testing scanner designed to discover vulnerabilities by performing cross-function and cross-file taint analysis. By following the paths user inputs take, the analyzer identifies potential points where untrusted data can influence the execution of your application in unsafe ways, ensuring the vulnerabilities are detected even when they span multiple functions and files.\n\nGitLab Advanced SAST can be used together with [GitLab Duo Vulnerability Explanation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability) in order to reduce the mean time to remediation (MTTR). GitLab Duo can provide practical, AI-powered examples of how threat actors can exploit vulnerabilities and offer light-weight remediation guidance, which can be used with cross-file analysis to enhance application security (AppSec) efficiency.\n\nThis tutorial will show you how to:\n* enable GitLab Advanced SAST\n* read results from the scanner\n* review the code flow of a vulnerability\n* use GitLab AI to quickly remediate the vulnerability\n\n## Enable GitLab Advanced SAST\n\nFollow the instructions below to enable GitLab Advanced SAST. You can also view this video to get started:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xDa1MHOcyn8?si=5SYuKgP-BdBryqcU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Run GitLab Advanced SAST on each code commit\n\nBefore using Advanced SAST, the following prerequisites must be met:\n\n- GitLab Ultimate Subscription ([free 30-day trial](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F))\n- GitLab SaaS or GitLab Self-managed (running Version 17.4)\n\nTo enable the GitLab Advanced SAST scanner:\n\n- On the left sidebar, select **Search** or **Go to** and find your project.\n- Add or edit the `.gitlab-ci.yml` to include the following:\n    - Test stage\n    - `Jobs/SAST.gitlab-ci.yml` template\n    - `GITLAB_ADVANCED_SAST_ENABLED` variable set to true\n- Apply the change.\n\nYour newly merged `.gitlab-ci.yml` should contain the following:\n\n```yaml\nstages:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n  GITLAB_ADVANCED_SAST_ENABLED: 'true'\n```\n\nThis will now run the `gitlab-advances-sast` job within the test stage of your application along with all the other jobs you have defined. Advanced SAST will replace the semgrep SAST scanner for the [supported programming languages](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html#supported-languages).\n\n![Running `gitlab-advances-sast` job within the test stage of your application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098466/Blog/Content%20Images/Blog/Content%20Images/1_aHR0cHM6_1750098466629.png)\n\n\u003Ccenter>\u003Ci>GitLab Advanced SAST job in pipeline\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\n**Note:** You can fully configure the job as you would any job in GitLab. For more information, see the [CI/CD YAML syntax documentation](https://docs.gitlab.com/ee/ci/yaml/).\n\n## Remediate vulnerabilities in merge request (pre-production)\n\nJust like our previous SAST scanner, Advanced SAST allows you to scan source code in the diff of a feature branch. This allows us to address any incoming vulnerabilities before they make it into production. Here we can see the scanner results for the diff within a merge request:\n\n![Advanced SAST scanner results for the diff within a merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/2_aHR0cHM6_1750098466630.png)\n\nWhen selecting a newly detected vulnerability, we get the following details to assist with remediation:\n\n- **Status:** The status of the vulnerability (Needs triage, Confirmed, Dismissed, Resolved)\n- **Description:** Detailed information on the detected vulnerability\n- **Detection time:** Time vulnerability was detected\n- **Location:** Line of code where vulnerability is detected\n- **Severity:** Severity of vulnerability from CVE database\n- **Training:** Gamified training from our partners\n- **Solutions:** Information on how to remediate or resolve a vulnerability\n- **Identifiers:** Relevant links showcasing detailed description, exploitation, and remediation\n\n![Merge request with vulnerability insights](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/MR_with_vulnerability_insights_aHR0cHM6_1750098466632.png)\n\n\u003Ccenter>\u003Ci>Merge request with vulnerability insights\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br> \nVulnerabilities detected within an MR are actionable, meaning they can be dismissed or an issue can be created and populated with relevant vulnerability information.\n\nDismissing an issue saves AppSec teams time, because they can see relevant developer information when reviewing an MR. Creating a confidential issue allows developers and AppSec teams to further collaborate on resolving a vulnerability where a fix is not straightforward. Confidential issues have limited permissions and can be used with confidential merge requests to prevent possible malicious actors from exploiting.\n\nTo further support separation of duties and prevent vulnerable code from making it into production, you can require approval from certain people (for example, the security team) in order to merge vulnerable code.\n\n![GitLab security policies in action](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/security_policies_in_action_aHR0cHM6_1750098466634.png)\n\n\u003Ccenter>\u003Ci>Security policies in action\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\n**Note:** Learn more about Security Policies and how to implement them in the [Security Policy documentation](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n## Manage vulnerabilities in production\n\nWhile preventing vulnerabilities from making it into production is crucial for application security, it is equally as important to manage vulnerabilities in production. When security scanners are run on a default or production-level branch, a [vulnerability report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) will be populated with the latest vulnerability data which can be used to triage and manage vulnerabilities.\n\n![GitLab Vulnerability Report sorted by Advanced SAST](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/5_aHR0cHM6_1750098466636.png)\n\n\u003Ccenter>\u003Ci>GitLab Vulnerability Report sorted by Advanced SAST\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nWhen selecting a vulnerability you get similar vulnerability details as seen in a merge request, making for a single source of truth for developers and AppSec teams.\n\n![Vulnerability page with vulnerability insights](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/Vuln_page_with_vulnerability_insights_aHR0cHM6_1750098466637.png)\n\n\u003Ccenter>\u003Ci>Vulnerability page with vulnerability insights\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nAppSec teams can triage a vulnerability by changing its status and adding relevant details on the status change. Issues can be created to track the progress of a fix. From here, a developer can be assigned.\n\n## Examine vulnerable code flow\n\nFor vulnerabilities detected with Advanced SAST, we can see a \"Code flow\" tab on the Vulnerability page.\n\n![Advanced SAST - image 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/7_aHR0cHM6_1750098466638.png)\n\n\u003Ccenter>\u003Ci>GitLab Advanced SAST code flow\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nIn this example, you can see that a vulnerability is traced across multiple functions, giving deeper insight into the best practices we should put in place to not only resolve the vulnerability, but prevent similar vulnerabilities in the future.\n\n## Use GitLab Duo Vulnerability Explanation\n\nGitLab Duo can help you mitigate or remediate a vulnerability by using a large language model to:\n\n- Summarize the vulnerability\n- Help developers and security analysts understand the vulnerability\n- Show how the vulnerability can be exploited\n- Provide a suggested remediation or mitigation\n\nTo use Vulnerability Explanation, the following is required:\n\n- GitLab Ultimate subscription\n- GitLab Duo Enterprise seat\n- GitLab Duo must be enabled for your group or instance\n\nFrom the vulnerability report, you can select a SAST vulnerability and go to its Vulnerability page. From the Vulnerability page, you can do any of the following to explain the vulnerability:\n\n- Select the text below the vulnerability description\n- You can use AI by asking GitLab Duo Chat to explain this vulnerability and offer a suggested fix.\n- In the upper right, from the \"Resolve with merge request\" dropdown list, select **Explain Vulnerability**, then select **Explain vulnerability**.\n- Open GitLab Duo Chat and use the explain a vulnerability command: `/vulnerability_explain`.\n\nThen the vulnerable code will be processed by Anthropic’s Claude 3 Haiku model and provide the following data:\n\n![GitLab Duo Vulnerability Explanation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098467/Blog/Content%20Images/Blog/Content%20Images/vuln_explain_2_aHR0cHM6_1750098466640.png)\n\n## Putting it all together\n\nNow, let's put it all together with a concrete example. I will use the [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/) as my demo application and run GitLab Advanced SAST to detect a vulnerability in production. Then I will use the vulnerability code flow and GitLab Duo to investigate vulnerability exploitation, and remediation. You can [follow along with this demo](https://gitlab.com/gitlab-da/tutorials/security-and-governance/owasp/juice-shop) and see this workflow in action by watching:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/H1S43oM44k0?si=2LYorTjByOHbCAko\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThe detection and remediation workflow is as follows:\n\n- Enable GitLab Advanced SAST and run it on the project’s default branch.\n- Open the Vulnerability Report and sort by **Tool:GitLab Advanced SAST**.\n- Select the **Improper neutralization of special elements in data query logic** vulnerability found in `Basket.ts`.\n- Use the vulnerability code flow to understand the vulnerable paths.\n- Run **Explain this vulnerability** to see exploit information.\n- Run the application locally to attempt exploitation.\n- Change vulnerability status to \"Confirmed\" and provide relevant info.\n- Determine remediation path using all relevant data:\n    - Vulnerability page insights, Code Flow, Vulnerability Explanation results\n- Create a new branch and apply remediation.\n- Run the remediated application locally and try to exploit again.\n- Create a merge request with the fix.\n- Code change will be tested using CI to assure we don’t break the application.\n- Validate and merge MR.\n- Test exploit in deployed environment.\n- Change vulnerability status to \"Resolved\" on the Vulnerability page.\n\n**Note:** There are many ways to triage and remediate vulnerabilities, make sure to follow best practices set by your organization.\n\n# Useful links\n\nTo learn more about GitLab and how you can get started with enhancing your organization’s application security posture, check out the following resources.\n\n* [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) \n* [GitLab Duo](https://about.gitlab.com/gitlab-duo/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab Software Supply Chain Security Solutions](https://about.gitlab.com/solutions/supply-chain/)  \n* [GitLab Continuous Software Compliance](https://about.gitlab.com/solutions/continuous-software-compliance/)  \n* [JuiceShop Demo Application](https://gitlab.com/gitlab-da/tutorials/security-and-governance/owasp/juice-shop)  \n* [GitLab AppSec documentation](https://docs.gitlab.com/ee/user/application_security/)  \n* [Advanced SAST  documentation](https://docs.gitlab.com/ee/user/application_security/sast/gitlab_advanced_sast.html)  \n* [Explain this Vulnerability documentation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability)  \n* [Code Flow documentation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-code-flow)  \n* [Security Policy documentation](https://docs.gitlab.com/ee/user/application_security/policies/) \n* [OWASP Juice Shop documentation](https://owasp.org/www-project-juice-shop/)\n",[786,704,746,9,478],{"slug":5228,"featured":90,"template":683},"quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai","content:en-us:blog:quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai.yml","Quick Vulnerability Remediation With Gitlab Advanced Sast Duo Ai","en-us/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai.yml","en-us/blog/quick-vulnerability-remediation-with-gitlab-advanced-sast-duo-ai",{"_path":5234,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5235,"content":5241,"config":5245,"_id":5247,"_type":13,"title":5248,"_source":15,"_file":5249,"_stem":5250,"_extension":18},"/en-us/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"title":5236,"description":5237,"ogTitle":5236,"ogDescription":5237,"noIndex":6,"ogImage":5238,"ogUrl":5239,"ogSiteName":670,"ogType":671,"canonicalUrls":5239,"schema":5240},"Quickly resolve broken CI/CD pipelines with AI","When your CI/CD pipeline fails, it leads to delays, decreased productivity, and stress. AI-powered Root Cause Analysis makes problem-solving faster and smarter.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097355/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097355230.png","https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Quickly resolve broken CI/CD pipelines with AI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":5236,"description":5237,"authors":5242,"heroImage":5238,"date":3681,"body":5243,"category":806,"tags":5244},[1769],"CI/CD pipelines are the backbone of efficiency in software development. They help teams test, build, and deploy code quickly. But when these pipelines break, everything slows down — deadlines get missed, and developers are left frustrated as they work to fix things and keep projects on track.\n\n![CI/CD pipeline with multiple failed jobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097362/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097362772.png)\n\n\u003Ccenter>\u003Ci>CI/CD pipeline with multiple failed jobs\u003C/i>\u003C/center>\u003Cbr>\u003C/br>\n\n**So, why do pipelines break in the first place?** Let’s break it down.\n\n## Reasons for pipeline failures\n\nA pipeline failure occurs when the automated workflow in your [CI/CD pipeline](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/) — a series of steps that can include building, testing, and deploying code — does not execute as expected and ends with an error message. This failure can prevent code from being properly built, tested, or deployed, causing delays in software delivery and requiring troubleshooting to resolve. \n\nPipeline failures can happen for a variety of reasons. Some common causes include:\n- Syntax errors: A small mistake in the code, like a missing semicolon or incorrect variable name, can cause the pipeline to fail.\n- Failed tests: Unit or integration tests might fail due to broken code, incorrect configurations, or mismatched dependencies.\n- Misconfigurations: Incorrect pipeline settings or environment configurations can lead to failed builds or deployments.\n\nThere are also more complex issues that add to the challenge:\n- Infrastructure-as-Code ([IaC](https://about.gitlab.com/topics/gitops/infrastructure-as-code/)) issues: Problems in provisioning cloud infrastructure, such as errors in Terraform scripts or CloudFormation templates, can prevent a successful deployment.\n- Kubernetes and GitOps challenges: Misconfigurations in [Kubernetes clusters](https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution/) or issues with [GitOps](https://about.gitlab.com/topics/gitops/) workflows (e.g., syncing Kubernetes states with Git repositories) can cause pipeline failures that are difficult to diagnose.\n- Long, messy stack traces: When an error occurs deep in the system, stack traces can become long and hard to decipher, especially when they span multiple components or services.\n\nThese challenges make troubleshooting more difficult and time-consuming, as finding the root cause often involves sifting through complex logs, reviewing configuration files, and testing different solutions.\n\n## The real impact of failed pipelines\n\nWhen a pipeline fails, it doesn’t just delay your deployment — it brings stress and frustration. Developers are forced to pause their work and dive into troubleshooting, which often leads to a chain reaction of disruptions. This makes it harder to meet deadlines and increases the pressure on the entire team. But why is manual troubleshooting so stressful?\n\n### Manual troubleshooting \n\nThe time it takes to fix a broken pipeline varies. It depends on things like:\n- How well the developer knows the project\n- How experienced they are with similar issues\n- Their overall problem-solving skills\n\nManually digging through logs to figure out what went wrong is a tough and tedious process. Logs can come from all over the place, including application errors and system messages, and they’re often messy and hard to interpret. And on top of that, fixing the pipeline usually requires a lot of jumping back and forth between tasks, adding more time to the process.\n\nThis is where [GitLab Duo](https://about.gitlab.com/gitlab-duo/) comes in. GitLab Duo can sift through all that messy data and spot issues much faster, simplifying the process so you don’t need to be an expert to figure out what went wrong. With AI, fixing your pipelines becomes faster, easier, and much less stressful.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176104/Blog/zxvvu7p9vc3qpmwl32ya.png\" alt=\"broken pipeline\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176108/Blog/bpx6dqilfhltzboyp8k8.png\" alt=\"fix suggestions for broken pipelines\">\n\n## GitLab Duo Root Cause Analysis with generative AI\n\nWhen your CI/CD pipeline breaks, you don’t have to spend hours manually troubleshooting. Enter [GitLab Duo’s Root Cause Analysis (RCA)](https://docs.gitlab.com/ee/user/gitlab_duo/#root-cause-analysis). This AI-powered tool quickly identifies the exact cause of the failure and suggests fixes — right within the DevSecOps platform. No matter how long or complicated your stack traces are, RCA analyzes all the data, breaks it down, and gives you clear, actionable insights.\n\n**It tells you exactly what caused the error, provides steps to fix it, and even pinpoints the specific files and lines of code that need attention.** And, to make it even easier, it suggests code fixes to get everything back on track. This makes troubleshooting a lot faster and more straightforward.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176111/Blog/nmagby9hoksskogve53m.png\" alt=\"root cause of failure\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176115/Blog/dndis1cedwbmbnj33q3v.png\" alt=\"example fix\">\n\n## Keep the conversation going with follow-up questions\n\nWith GitLab Duo RCA, you don’t just get answers — you can ask follow-up questions to dig deeper. Want to explore alternative solutions? No problem. You can add [more context](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html#the-context-chat-is-aware-of) by referencing other files, issues, or epics in your repo. For example, you could open your `.gitlab-ci.yml` file in the IDE and ask the chat, “Based on this file, and the analyzed CI/CD pipeline, how would you propose to optimize the pipeline?” \n\n## Privacy first – everything stays in GitLab\nOne of the key benefits of GitLab Duo RCA is that it works right out of the box within GitLab. You won’t have to switch tools or go hunting for external help. Plus, your [logs and sensitive data stay secure](https://about.gitlab.com/privacy/) - there’s no need to send them off to external AI solutions. RCA is seamlessly integrated within GitLab, offering valuable insights without ever compromising privacy.\n\n![broken pipelines - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097362773.png)\n\n## Get started today\n\nWant to see how AI can supercharge your development process, making it smoother and faster? Dive into our GitLab Duo Enterprise product tour below and discover how GitLab Duo’s AI-powered insights can transform every stage of your development journey — from planning and coding to troubleshooting and deployment. Click the image below to start the tour!\n\n[![GitLab Duo Enterprise tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-12-02_at_12.41.10_PM_aHR0cHM6_1750097362774.png)](https://gitlab.navattic.com/duo-enterprise)\n\n> [Start a free, 60-day trial of GitLab Duo today!](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/)",[786,478,746,9],{"slug":5246,"featured":6,"template":683},"quickly-resolve-broken-ci-cd-pipelines-with-ai","content:en-us:blog:quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","Quickly Resolve Broken Ci Cd Pipelines With Ai","en-us/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","en-us/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"_path":5252,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5253,"content":5258,"config":5263,"_id":5265,"_type":13,"title":5266,"_source":15,"_file":5267,"_stem":5268,"_extension":18},"/en-us/blog/rate-limitation-for-unauthorized-users-projects-list-api",{"title":5254,"description":5255,"ogTitle":5254,"ogDescription":5255,"noIndex":6,"ogImage":1387,"ogUrl":5256,"ogSiteName":670,"ogType":671,"canonicalUrls":5256,"schema":5257},"Rate limitations for unauthorized users of the Projects List API","Learn details about upcoming changes for unauthenticated users of the Projects List API.","https://about.gitlab.com/blog/rate-limitation-for-unauthorized-users-projects-list-api","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Rate limitations for unauthorized users of the Projects List API\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Lohr\"}],\n        \"datePublished\": \"2023-04-10\",\n      }",{"title":5254,"description":5255,"authors":5259,"heroImage":1387,"date":5260,"body":5261,"category":298,"tags":5262},[4127],"2023-04-10","\n\nStarting on May 22 for self-managed GitLab, and May 8 for GitLab.com, unauthenticated users will be subject to rate limitations when using the Projects List API. This change has been made to ensure the stability and reliability of our platform for all users.\n\n**Note:** Authorized users are not affected by this change.\n\n## What is the the Projects List API?\n\nThe Projects List API provides information about GitLab projects, including name, description, and other metadata. This API is widely used by our community, including researchers, developers, and integrators, to retrieve and analyze information about GitLab projects. We value this usage and aim to support it as much as possible.\n\n## Rate limitation details\n\nIn recent months, we have observed that the frequency and intensity of requests made by unauthenticated, also known as anonymous, users to the Projects List API have increased significantly. This has resulted in an increased load on our servers, which has impacted the performance and stability of our platform for all users. To address this issue, we have decided to introduce rate limitations for unauthenticated users.\n\nAs a consequence of this change, unauthenticated users of the Projects List API will be limited to 400 requests per 10 minutes per unique IP address on GitLab.com. If an unauthenticated user exceeds this limit, the user will receive a \"429 Too Many Requests\" response. On GitLab.com, this limit cannot be changed. Users of self-managed GitLab instances have the same rate limitation set by default, but [admins can change the rate limits](https://docs.gitlab.com/ee/administration/settings/rate_limit_on_projects_api.html#rate-limit-on-projects-api) as they see fit via the UI or the application settings API. They can also set the rate limit to zero, which acts as if there is no rate limitation at all.\n\nWe understand that this change may impact some of our users who rely on the Projects List API, and we apologize for any inconvenience this may cause. We encourage users who need to make more than 400 requests per 10 minutes to the Projects List API to [sign up for a GitLab account](/pricing/), which provides higher rate limits and other benefits, such as access to additional APIs and integrations.\n\nIf you have any questions or concerns about this change, please do not hesitate to [leave feedback in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/404611).\n",[701,9,678],{"slug":5264,"featured":6,"template":683},"rate-limitation-for-unauthorized-users-projects-list-api","content:en-us:blog:rate-limitation-for-unauthorized-users-projects-list-api.yml","Rate Limitation For Unauthorized Users Projects List Api","en-us/blog/rate-limitation-for-unauthorized-users-projects-list-api.yml","en-us/blog/rate-limitation-for-unauthorized-users-projects-list-api",{"_path":5270,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5271,"content":5277,"config":5282,"_id":5284,"_type":13,"title":5285,"_source":15,"_file":5286,"_stem":5287,"_extension":18},"/en-us/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization",{"title":5272,"description":5273,"ogTitle":5272,"ogDescription":5273,"noIndex":6,"ogImage":5274,"ogUrl":5275,"ogSiteName":670,"ogType":671,"canonicalUrls":5275,"schema":5276},"Reduce supply chain risk with smarter vulnerability prioritization","New software composition analysis features use risk-based intelligence so developers and security teams can prioritize critical vulnerabilities for targeted remediation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674528/Blog/Hero%20Images/blog-image-template-1800x945__5_.png","https://about.gitlab.com/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Reduce supply chain risk with smarter vulnerability prioritization\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Salman Ladha\"}],\n        \"datePublished\": \"2025-01-07\",\n      }",{"title":5272,"description":5273,"authors":5278,"heroImage":5274,"date":5279,"body":5280,"category":704,"tags":5281},[698],"2025-01-07","Application Security teams face a constant uphill battle in risk reduction due to the ever-growing number of vulnerabilities. This year alone, [36,000 Common Vulnerabilities and Exposures (CVEs)](https://www.cvedetails.com/) have been reported — a 25% increase from last year. The sharp rise intensifies the challenge of prioritization in vulnerability management, especially for lean AppSec teams. \n\nTo help, we’ve introduced several new enhancements to our Software Composition Analysis (SCA) solution. These improvements are available for all GitLab Ultimate customers:  \n\n* **Static Reachability Analysis** identifies the *exploitable* vulnerabilities from open source components in your applications.   \n* **Known Exploited Vulnerabilities** (KEV) **Indicator** highlights known, actively exploited vulnerabilities.   \n* **Exploit Prediction Scoring System** (EPSS) predicts the likelihood of a vulnerability being exploited.\n\nBy prioritizing exploitable vulnerabilities, AppSec teams can reduce triage times, accelerate remediation cycles, and improve collaboration with their development counterparts. Powered by our recent acquisitions of [Oxeye](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/) and [Rezilion's intellectual property](https://ir.gitlab.com/news/news-details/2024/GitLab-Reports-First-Quarter-Fiscal-Year-2025-Financial-Results/default.aspx), these new capabilities align with our vision of providing best-in-class application security solutions, natively built into developer workflows. \n\n### What is SCA and why does it matter? \n\nSoftware Composition Analysis helps organizations identify and manage open source components within their applications. By scanning the codebase, SCA provides insights into the component versions, licenses, and importantly, known vulnerabilities. With [90% of Fortune 500](https://www.nber.org/be/20241/open-source-software-creators-its-not-just-about-money) companies dependent on open source components for their applications, SCA provides much-needed visibility to mitigate software supply chain risk. \n\nHigh-profile breaches like [SolarWinds](https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/) and [Log4Shell](https://www.ncsc.gov.uk/information/log4j-vulnerability-what-everyone-needs-to-know) highlight how vulnerabilities in third-party components can compromise countless downstream applications. SCA tools act as proactive measures, enabling teams to identify vulnerabilities and enforce compliance early in the software development lifecycle, ensuring software security while maintaining development velocity. \n\n### Filter out the noise for targeted remediation \n\nWith our latest SCA enhancements, GitLab helps you cut through the noise to prioritize real risks, reduce backlogs, and remediate faster – all within your existing workflows. \n\n**Focus on vulnerabilities that pose the greatest risk** \n\n* Static Reachability Analysis leverages the proprietary detection engine of our [Advanced SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/) solution to surface vulnerabilities from dependencies that can *actually* be exploited in your application. \n\n**Reduce triage times** \n\n* With KEV indicators and EPSS scoring, GitLab gives security teams actionable insights into vulnerabilities that are actively being exploited or likely to be targeted. Incorporating risk-based scoring helps teams effectively triage their vulnerability backlog. \n\n**Faster remediation to mitigate supply chain risk** \n\n* Our SCA enhancements are built into developer workflows, providing contextual remediation guidance while maintaining developer productivity. \n\n### What’s next for SCA \n\nWe’re continuing to integrate Rezilion’s technology into our platform to help teams secure their software supply chains more effectively. Rezilion will be key to powering future innovations, including:\n\n* **Supporting faster remediation** workflows by automatically opening merge requests with fixes for detected vulnerabilities   \n* **Enriching package metadata** using [OpenSSF scorecard ratings](https://openssf.org/projects/scorecard/) to provide security teams with more information on dependencies such as authors and end-of-life status   \n* **Improving open-source software license detection** to ensure compliance and reduce legal risks \n\n### Get started with SCA \n\nIf you’re an existing GitLab Ultimate customer and would like to learn more about how Software Composition Analysis can enhance your application security program, visit our [documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/). There, you’ll find details on implementation requirements, use cases, and more. Or if you’re not yet a GitLab Ultimate customer, get started with a [free trial](https://about.gitlab.com/free-trial/) today to explore how GitLab enhances your ability to write secure software, achieve compliance goals, and improve development velocity. \n\n##### ***Disclaimer**: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.*",[704,9,478,701],{"slug":5283,"featured":90,"template":683},"reduce-supply-chain-risk-with-smarter-vulnerability-prioritization","content:en-us:blog:reduce-supply-chain-risk-with-smarter-vulnerability-prioritization.yml","Reduce Supply Chain Risk With Smarter Vulnerability Prioritization","en-us/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization.yml","en-us/blog/reduce-supply-chain-risk-with-smarter-vulnerability-prioritization",{"_path":5289,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5290,"content":5295,"config":5300,"_id":5302,"_type":13,"title":5303,"_source":15,"_file":5304,"_stem":5305,"_extension":18},"/en-us/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow",{"title":5291,"description":5292,"ogTitle":5291,"ogDescription":5292,"noIndex":6,"ogImage":2894,"ogUrl":5293,"ogSiteName":670,"ogType":671,"canonicalUrls":5293,"schema":5294},"Refactoring JavaScript to TypeScript with GitLab Duo Workflow","Learn how we used our autonomous AI agent, which sits in your development environment, to convert a real-world JavaScript application to TypeScript.","https://about.gitlab.com/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Refactoring JavaScript to TypeScript with GitLab Duo Workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Frédéric Caplette\"}],\n        \"datePublished\": \"2025-05-22\",\n      }",{"title":5291,"description":5292,"authors":5296,"heroImage":2894,"date":4205,"body":5298,"category":806,"tags":5299},[5297],"Frédéric Caplette","TypeScript adoption continues to grow, with over 88% of developers reporting they either use or want to use it. Yet, migrating existing JavaScript codebases to TypeScript is often a time-consuming process. Enter [GitLab Duo Workflow](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/): secure, agentic AI that sits right inside your development environment, helping transform high-level tasks into executable workflows. In this article, you'll learn how we used Duo Workflow to update Duo Workflow, converting a real-world JavaScript application to TypeScript. We'll also review the technical process and broader implications for development workflows.\n\nThis video walks through visually what you'll read below:\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1085078036?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Refactor JavaScript to TypeScript with GitLab Duo Workflow\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## The challenge: Refactor JS to TS\n\nWe decided to migrate Duo Workflow client-related logic to TypeScript for better type safety and auto-complete. A JavaScript-to-TypeScript migration involves more than just changing file extensions. It requires:\n\n1. Analyzing existing code patterns to determine appropriate types  \n2. Handling edge cases where type inference is ambiguous  \n3. Ensuring consistency across the codebase  \n4. Managing dependencies and third-party libraries  \n5. Validating that runtime behavior remains unchanged\n\nDoing all of this work manually can be very time consuming and not much fun. Thankfully, managing your projects is easier and more efficient with Duo Workflow – even when the project is Duo Workflow.\n\n## How it works\n\nIf you've used AI coding assistants before, you're likely familiar with their chat-based interfaces (like [GitLab Duo Chat](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/)). These chats can provide code snippets, suggested directory structures, and more. GitLab Duo Workflow fundamentally differs from these in several key ways:\n\n1. It's contextually aware of your entire codebase, not just open files or highlighted text. You can also add context from relevant GitLab issues or merge requests.  \n2. It develops and executes a multi-stage plan, allowing for more complete solutions.  \n3. It keeps a human in the loop, ensuring you understand and approve of what is happening at each step of the way.  \n4. It stages changes to your repository, giving you control over what to accept.\n\nDuo Workflow uses an agentic AI approach, powered by Claude 3.5 Sonnet, to understand code semantics while maintaining a deep integration with GitLab's DevOps platform.\n\nLet's walk through a real-world example of refactoring a JavaScript file using GitLab Duo Workflow. In our case, we started with the prompt:\n\n```unset\nI need to refactor a JavaScript file packages/webview_duo_workflow/src/app/stores/workflow.js to TypeScript. Please analyze the code, identify any issues, and convert it to TypeScript with appropriate type definitions.\n```\n\n### Analysis\n\nAfter prompting, Duo Workflow first analyzed the codebase structure:\n\n* Identified that `workflow.js` is a Pinia store implementation  \n* Noted it uses imports from various modules including `constants.ts` (which was already in TypeScript)  \n* Recognized GraphQL queries import exists but the file wasn't accessible\n\nBased on this analysis, Duo Workflow identified specific typing needs:\n\n**Type definitions needed for:**\n\n* Store State interface with precise types:  \n  * `areWorkflowsLoading`: boolean  \n  * `isLoadingWorkflow`: boolean  \n  * `isLoadingRecentWorkflows`: boolean  \n  * `recentWorkflows`: array  \n  * `workflows`: array  \n  * `workflowsPageInfo`: object  \n  * `initialState`: object  \n  * `activeWorkflow`: object with specific shape\n\n**Interface definitions required:**\n\n* Workflow interface with properties:  \n  * `id`: string  \n  * `goal`: string  \n  * `status`: string  \n  * `checkpoint`: object  \n  * `type`: string\n\n**Parameter types needed for:**\n\n* GraphQL response types for workflows data  \n* Event handler parameter types  \n* Function parameter types for actions like `getWorkflowById`, `runWorkflow`, etc.\n\nDuo Workflow identified several complex patterns requiring special handling:\n\n* Uses optional chaining extensively  \n* Has nested object destructuring  \n* Contains GraphQL integration  \n* Uses Pinia store patterns with state, getters, and actions  \n* Implements an events mapping system\n\nThe system recognized external type dependencies:\n\n* Pinia store types  \n* GraphQL query response types  \n* Functions from an internal Bridge module were also properly recognized (for `sendRequest`, `sendGraphqlRequest`)\n\nThe final analysis concluded: \"The file will need to be renamed from .js to .ts and appropriate type definitions added while maintaining the existing functionality.\"\n\n### Planning\n\nBased on this thorough analysis, Duo Workflow created a structured plan consisting of specific tasks:\n\n1. **Create a new TypeScript file** `workflow.ts` in the same directory as the original JS file.\n\n2. **Create TypeScript interfaces** for the store state and workflow types at the top of the new file, including:\n\n   * WorkflowState interface for store state  \n   * Workflow interface for workflow object structure  \n   * WorkflowPageInfo interface for pagination info  \n   * WorkflowCheckpoint interface for checkpoint data\n\n3. **Copy and add type annotations** to the store implementation from `workflow.js`, including:\n\n   * State return type  \n   * Getter return types  \n   * Action parameter types  \n   * Action return types\n\n4. **Update all imports** in `workflow.ts` to:\n\n   * Add type imports from Pinia  \n   * Update local imports to use .ts extensions where applicable  \n   * Import any required type definitions\n\n### Execution\n\nAfter the plan is complete, we were prompted to  “Approve plan.” Before clicking approve, we reviewed each step and ensured we were comfortable with the plan. After approval, Duo Workflow showed its progress through each step with visual indicators and explanations of what API operations were supporting each task (like \"Supported by: create_file_with_contents\" or \"Supported by: edit\\_file\"). When the work was done, we reviewed the changes before committing. \n\n## What we learned\n\nThis JavaScript-to-TypeScript migration example showcases a significant evolution in AI-assisted development. What makes GitLab Duo Workflow particularly interesting is its approach to:\n\n### Task-oriented programming vs. suggestion-only assistance\n\nUnlike many AI assistants that simply offer code snippets or suggestions, Duo Workflow understands and executes complete tasks. The difference is significant — rather than saying \"here's some TypeScript code you might use,\" it says \"I'll convert this file for you, here's my plan, and here are the changes I'm making.\"\n\n### Contextual understanding of the entire codebase\n\nThe tool demonstrates awareness of project structure, related files (like constants.ts and GraphQL queries), and the relationships between components. This contextual understanding allows for more sophisticated conversions than localized transformations.\n\n### Step-by-step execution with visibility\n\nThe plan-based approach, with clear steps and progress indicators, provides transparency into what would otherwise be a black-box process. This allows developers to understand what the AI is doing and how it's approaching the problem.\n\n> GitLab Duo Workflow is currently available in private beta for GitLab Ultimate customers. [Sign up for the waitlist today!](https://about.gitlab.com/gitlab-duo/workflow/)\n\n## Learn more\n\n- [Agentic AI guides and resources](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)  \n- [GitLab Duo Workflow](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)  \n- [What is agentic AI?](https://about.gitlab.com/topics/agentic-ai/)",[786,746,478,9],{"slug":5301,"featured":90,"template":683},"refactoring-javascript-to-typescript-with-gitlab-duo-workflow","content:en-us:blog:refactoring-javascript-to-typescript-with-gitlab-duo-workflow.yml","Refactoring Javascript To Typescript With Gitlab Duo Workflow","en-us/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow.yml","en-us/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow",{"_path":5307,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5308,"content":5314,"config":5320,"_id":5322,"_type":13,"title":5323,"_source":15,"_file":5324,"_stem":5325,"_extension":18},"/en-us/blog/registration-features-program-expands-by-16-free-features",{"title":5309,"description":5310,"ogTitle":5309,"ogDescription":5310,"noIndex":6,"ogImage":5311,"ogUrl":5312,"ogSiteName":670,"ogType":671,"canonicalUrls":5312,"schema":5313},"Registration Features program expands by 16 free features","More features now available at no cost to free self-managed Enterprise Edition DevSecOps platform customers who register and turn on their Service Ping.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","https://about.gitlab.com/blog/registration-features-program-expands-by-16-free-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Registration Features program expands by 16 free features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Pedowitz\"}],\n        \"datePublished\": \"2024-01-18\",\n      }",{"title":5309,"description":5310,"authors":5315,"heroImage":5311,"date":5317,"body":5318,"category":701,"tags":5319},[5316],"Ian Pedowitz","2024-01-18","In GitLab 16.0 we [expanded](https://about.gitlab.com/blog/expanded-registration-features-program/) the [Registration Features program](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#registration-features-program), which offers free self-managed users running [GitLab Enterprise Edition](https://about.gitlab.com/enterprise/) free use of [paid features](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#available-features) by registering with GitLab and sending us activity data via Service Ping. In GitLab 16.5, 16.6, and 16.7 we’ve broadened the program to include the following 16 features:\n\n1. [Group wikis](https://docs.gitlab.com/ee/user/project/wiki/group.html): If you use GitLab groups to manage multiple projects, some of your documentation might span multiple groups. You can create group wikis, instead of [project wikis](https://docs.gitlab.com/ee/user/project/wiki/index.html), to ensure all group members have the correct access permissions to contribute.\n1. [Issue analytics](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html): Issue analytics is a bar graph that illustrates the number of issues created each month. The default time span is 13 months, which includes the current month, and the 12 months prior. Issue analytics is available for projects and groups.\n1. [Custom text in emails](https://docs.gitlab.com/ee/administration/settings/email.html#custom-additional-text): You can add additional text at the bottom of any email that GitLab sends. This additional text can be used for legal, auditing, or compliance reasons.\n1. [Contribution analytics](https://docs.gitlab.com/ee/user/group/contribution_analytics/index.html): Contribution analytics provide an overview of the [contribution events](https://docs.gitlab.com/ee/user/profile/contributions_calendar.html#user-contribution-events) made by your group’s members.\n1. [Group file templates](https://docs.gitlab.com/ee/user/group/manage.html#group-file-templates): Use group file templates to share a set of templates for common file types with every project in a group. It is analogous to the [instance template repository](https://docs.gitlab.com/ee/administration/settings/instance_template_repository.html).\n1. [Group webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#group-webhooks): You can configure a group webhook, which is triggered by events that occur across all projects in the group and its subgroups.\n1. [Service Level Agreement countdown timer](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#service-level-agreement-countdown-timer): You can enable the SLA timer on incidents to track the SLAs you hold with your customers.\n1. [Lock project membership to group](https://docs.gitlab.com/ee/user/group/access_and_permissions.html#prevent-members-from-being-added-to-projects-in-a-group): As a group Owner, you can prevent any new project membership for all projects in a group, allowing tighter control over project membership.\n1. [Users and permissions report](https://docs.gitlab.com/ee/administration/admin_area.html#user-permission-export): An administrator can export user permissions for all users in the GitLab instance from the Admin Area's Users page.\n1. [Advanced search](https://docs.gitlab.com/ee/user/search/advanced_search.html): You can use advanced search for faster, more efficient search across the entire GitLab instance.\n1. [Group DevOps Adoption](https://docs.gitlab.com/ee/user/group/devops_adoption/index.html): DevOps Adoption shows you how groups in your organization adopt and use the most essential features of GitLab.\n1. [Сross-project pipelines with artifacts dependencies](https://docs.gitlab.com/ee/ci/yaml/index.html#needsproject): Use `needs:project` to download artifacts from up to five jobs in other pipelines.\n1. [Feature flag related issues](https://docs.gitlab.com/ee/operations/feature_flags.html#feature-flag-related-issues): You can link related issues to a feature flag.\n1. [Merged results pipelines](https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipelines.html): A merged results pipeline is a type of [merge request pipeline](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html). It is a pipeline that runs against the results of the source and target branches merged together.\n1. [GitLab CI/CD for external repositories](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html): GitLab CI/CD can be used with [GitHub](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html), [Bitbucket Cloud](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/bitbucket_integration.html), or any other Git server, though there are some [limitations](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html#limitations).\n1. [Using GitLab CI/CD with a GitHub repository](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html): GitLab CI/CD can be used with GitHub.com and GitHub Enterprise by creating a [CI/CD project](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/index.html) to connect your GitHub repository to GitLab.\n\nThe above 16 features join the eight features already available to the registration tier in GitLab 16.0 and [prior releases](https://about.gitlab.com/blog/expanded-registration-features-program/).\n\n## How to to participate in the Registration Features program\n\nIf you are interested in participating as a free self-managed user running GitLab Enterprise Edition, you can learn how from our documentation [how to turn on Service Ping](https://docs.gitlab.com/ee/administration/settings/usage_statistics.html#enable-or-disable-usage-statistics).",[108,9,701,678],{"slug":5321,"featured":6,"template":683},"registration-features-program-expands-by-16-free-features","content:en-us:blog:registration-features-program-expands-by-16-free-features.yml","Registration Features Program Expands By 16 Free Features","en-us/blog/registration-features-program-expands-by-16-free-features.yml","en-us/blog/registration-features-program-expands-by-16-free-features",{"_path":5327,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5328,"content":5334,"config":5339,"_id":5341,"_type":13,"title":5342,"_source":15,"_file":5343,"_stem":5344,"_extension":18},"/en-us/blog/safe-without-silos-in-gitlab",{"title":5329,"description":5330,"ogTitle":5329,"ogDescription":5330,"noIndex":6,"ogImage":5331,"ogUrl":5332,"ogSiteName":670,"ogType":671,"canonicalUrls":5332,"schema":5333},"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.","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","https://about.gitlab.com/blog/safe-without-silos-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SAFe without silos in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-04-08\",\n      }",{"title":5329,"description":5330,"authors":5335,"heroImage":5331,"date":5336,"body":5337,"category":1228,"tags":5338},[1225],"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",[1164,478,9,701,746],{"slug":5340,"featured":90,"template":683},"safe-without-silos-in-gitlab","content:en-us:blog:safe-without-silos-in-gitlab.yml","Safe Without Silos In Gitlab","en-us/blog/safe-without-silos-in-gitlab.yml","en-us/blog/safe-without-silos-in-gitlab",{"_path":5346,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5347,"content":5353,"config":5359,"_id":5361,"_type":13,"title":5362,"_source":15,"_file":5363,"_stem":5364,"_extension":18},"/en-us/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"title":5348,"description":5349,"ogTitle":5348,"ogDescription":5349,"noIndex":6,"ogImage":5350,"ogUrl":5351,"ogSiteName":670,"ogType":671,"canonicalUrls":5351,"schema":5352},"Seamlessly migrate from Jira to GitLab with Jira2Lab at scale","Discover how Jira2GitLab simplifies large-scale Jira-to-GitLab migrations by handling complex data transfers, improving scalability, and ensuring efficient integration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Seamlessly migrate from Jira to GitLab with Jira2Lab at scale\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }",{"title":5348,"description":5349,"authors":5354,"heroImage":5350,"date":5356,"body":5357,"category":1228,"tags":5358},[5355],"Maximilien Belinga","2024-10-10","[Atlassian Server reached end of life in February](https://about.gitlab.com/move-to-gitlab-from-atlassian/), prompting many customers to explore alternatives like Atlassian Cloud or Data Center. However, enterprises using Atlassian Server are increasingly seeking Agile planning solutions that offer more flexibility, cost-efficiency, and robust DevSecOps integration. They also need to tackle challenges related to data volume, customization, user mapping, performance, and data integrity during migration. This is where [GitLab’s Jira2Lab](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/jira2lab) comes into play, offering a seamless solution for large-scale Jira migrations to GitLab, while providing full CI/CD integration.\n\n## The problem with large-scale Jira migrations\n\nMigrating from Jira to GitLab can be a significant hurdle, especially for enterprises with complex workflows and thousands of issues to move. Here are the most common challenges faced during such migrations:\n\n- **Massive data migration:** As the number of issues, attachments, comments, and projects increases, so does the complexity of migrating them without performance issues or data loss.\n\n- **Custom fields and workflows:** Jira instances often contain custom workflows, fields, and issue types that do not have a one-to-one mapping in GitLab. This gap creates friction during migration, as existing tools often require manual intervention to translate these elements.\n\n- **Lack of full DevSecOps integration:** While many migration tools handle project management data, they do not integrate GitLab’s full DevSecOps capabilities. As a result, teams are left to manually configure their [CI/CD](https://about.gitlab.com/topics/ci-cd/) pipelines and source control management systems after the migration.\n\n## Introducing Jira2Lab\n\nJira2Lab was designed from the ground up to solve the specific challenges of migrating from Jira to GitLab at scale. It’s not just about moving data; it’s about enabling teams to seamlessly transition into GitLab’s powerful DevSecOps environment without downtime or data loss.\n\n### Key features of Jira2Lab\n\n1. Efficient data handling at scale\u003Cbr> \nJira2Lab is optimized to handle thousands of issues, attachments, comments, and custom fields across multiple projects without sacrificing performance. It scales effortlessly to accommodate even the largest enterprise migrations.\n\n2. Custom workflow and field mapping\u003Cbr>\nOne of the standout features of Jira2Lab is its ability to automatically map custom workflows and fields from Jira to GitLab. The tool provides a flexible mapping configuration that eliminates the need for manual intervention during the migration process, making sure everything moves smoothly from Jira to GitLab.\n\n3. CI/CD pipeline integration\u003Cbr>\nJira2Lab doesn’t just migrate your issues and projects — it integrates GitLab’s full CI/CD pipeline into the migration process. This ensures that development teams can start using GitLab’s DevSecOps features, such as automated testing and deployment pipelines, immediately after migration.\n\n4. Pilot migrations\u003Cbr>\nOur tool supports pilot migrations to allow teams to test their configurations and workflows before scaling up. This ensures that any issues can be caught early, preventing disruptions during the full migration.\n\n5. Real-time monitoring\u003Cbr>\nThe tool provides real-time monitoring and logs during migration, giving complete transparency to ensure every step is performed correctly and without errors.\n\n6. Customizable and flexible\u003Cbr>\nEven if your Jira instance has unique configurations or workflows, Jira2Lab offers the flexibility to customize the migration according to your specific requirements, ensuring nothing is lost in translation.\n\n### Feature comparison: Jira vs. GitLab\n\nMigrating from Jira to GitLab helps consolidate workflows and unlock advanced features native to GitLab. Here’s a quick comparison of the core features of both platforms:\n\n| **Feature**             | **Jira**                        | **GitLab**                    |\n|-------------------------|----------------------------------|-------------------------------|\n| **Issue Tracking**       | Yes (Highly customizable)       | Yes (Integrated with DevSecOps)   |\n| **Agile Boards**         | Yes (Kanban, Scrum)             | Yes (Issue Boards, Milestones) |\n| **CI/CD**                | No (Requires external tools)    | Yes (Built-in CI/CD)           |\n| **Source Control**       | No (Requires GitHub/Bitbucket)  | Yes (Native Git support)       |\n| **DevSecOps Tools**         | Limited integrations            | Full DevSecOps lifecycle          |\n\nWith Jira2Lab, we ensure that all critical aspects, from issue tracking to CI/CD pipelines, are transitioned smoothly, taking full advantage of GitLab’s integrated approach to development and operations.\n\n## The migration methodology\n\nJira2Lab follows a structured, five-phase migration methodology, ensuring seamless transition with minimal disruption:\n\n### 1. Discovery and planning\n\nWe start by thoroughly understanding the customer’s Jira setup, identifying all necessary custom workflows, fields, and projects that need to be migrated. This phase also involves a gap analysis to compare Jira and GitLab features and map out the migration process.\n\n### 2. Setup\nIn this phase, we configure the migration tool and set up the necessary environments for both Jira and GitLab. This includes verifying all permissions and setting up a backup of Jira data before the migration begins.\n\n### 3. Pilot migrations\nBefore migrating the entire dataset, we run pilot migrations on selected projects to test the migration process, workflows, and data integrity. This allows us to identify and resolve any issues early in the process.\n\n### 4. Scaled migrations\nAfter validating the pilot migration, we scale the migration across all projects, ensuring minimal downtime and smooth transitions for development teams.\n\n### 5. Wrap-up and post-migration support\nOnce the migration is complete, we provide ongoing support, ensuring all teams are fully operational in GitLab. This phase also includes user training and the decommissioning of the Jira instance, if required.\n\n## Case study: Tackling scale with Jira2Lab\n\nIn a recent migration, a large enterprise faced the challenge of migrating over 20,000 issues across 50 projects from Jira to GitLab. The project had highly customized workflows and thousands of comments and attachments that needed to be transferred.\n\nWith Jira2Lab, we were able to:\n\n- Migrate all data, including custom fields, without any data loss.\n- Set up CI/CD pipelines within GitLab so that teams could immediately continue their work post-migration.\n- Conduct a pilot migration of two projects, which allowed us to identify and fix minor workflow discrepancies before scaling up to the entire organization.\n\nThe result was a seamless transition to GitLab, with the entire process completed within the planned timeline and no significant downtime.\n\n## Get started with Jira2Lab today\n\nJira2Lab stands out in the market by addressing the limitations that other migration tools cannot handle. It is designed specifically for large-scale migrations and can integrate with GitLab’s full DevSecOps lifecycle, unlike most tools that only handle project management data. The tool’s ability to map custom workflows and integrate CI/CD pipelines makes it the perfect solution for enterprises looking to enhance their development workflows while migrating to GitLab.\n\n> Ready to scale your development processes with GitLab? Explore our [Professional Services catalog](https://about.gitlab.com/services/catalog/) to learn how we can help your team migrate efficiently and effectively. Contact us through the form at the end for a personalized demo of GitLab's Jira2Lab.\n",[1164,108,703,9,701],{"slug":5360,"featured":90,"template":683},"seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","content:en-us:blog:seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","Seamlessly Migrate From Jira To Gitlab With Jira2lab At Scale","en-us/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","en-us/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"_path":5366,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5367,"content":5373,"config":5377,"_id":5379,"_type":13,"title":5380,"_source":15,"_file":5381,"_stem":5382,"_extension":18},"/en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration",{"title":5368,"description":5369,"ogTitle":5368,"ogDescription":5369,"noIndex":6,"ogImage":5370,"ogUrl":5371,"ogSiteName":670,"ogType":671,"canonicalUrls":5371,"schema":5372},"Secure and publish Python packages: A guide to CI integration","Learn how to implement a secure CI/CD pipeline across five stages with the GitLab DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662080/Blog/Hero%20Images/AdobeStock_1097303277.jpg","https://about.gitlab.com/blog/secure-and-publish-python-packages-a-guide-to-ci-integration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure and publish Python packages: A guide to CI integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-01-21\",\n      }",{"title":5368,"description":5369,"authors":5374,"heroImage":5370,"date":4243,"body":5375,"category":704,"tags":5376},[1040],"Supply chain security is a critical concern in software development. Organizations need to verify the authenticity and integrity of their software packages. This guide will show you how to implement a secure CI/CD pipeline for Python packages using GitLab CI, incorporating package signing and attestation using Sigstore's Cosign.\n\nYou'll learn:\n\n- [Why sign and attest your Python packages?](#why-sign-and-attest-your-python-packages%3F)\n- [Pipeline overview](#pipeline-overview)\n- [Complete pipeline implementation: Setting up the environment](#complete-pipeline-implementation-setting-up-the-environment)\n   * [Environment configuration](#environment-configuration)\n   * [Configuration breakdown](#configuration-breakdown)\n-  The 6 stages\n\n    1. [Building](#building-crafting-the-package)\n    2. [Signing](#signing-the-digital-notarization)\n    3. [Verification](#verification-the-security-checkpoint)\n    4. [Publishing](#publishing-the-controlled-release)\n    5. [Publishing signatures](#publishing-signatures-making-verification-possible)\n    6. [Consumer verification](#consumer-verification-testing-the-user-experience)\n\n## Why sign and attest your Python packages?\n\nHere are four reasons to sign and attest your Python packages:\n\n* **Supply chain security:** Package signing ensures that the code hasn't been tampered with between build and deployment, protecting against supply chain attacks.\n* **Compliance requirements:** Many organizations, especially in regulated industries, require cryptographic signatures and provenance information for all deployed software.\n* **Traceability:** Attestations provide a verifiable record of build conditions, including who built the package and under what circumstances.\n* **Trust verification:** Consumers of your package can cryptographically verify its authenticity before installation.\n\n## Pipeline overview\n\nEnsuring your code's integrity and authenticity is necessary. Imagine a pipeline that doesn't just compile your code but creates a cryptographically verifiable narrative of how, when, and by whom your package was created. Each stage acts as a guardian, checking and documenting the package's provenance.\n\nHere are six stages of a GitLab pipeline that ensure your package is secure and trustworthy:\n\n* Build: Creates a clean, standard package that can be easily shared and installed.\n* Signing: Adds a digital signature that proves the package hasn't been tampered with since it was created.\n* Verification: Double-checks that the signature is valid and the package meets all our security requirements.\n* Publishing: Uploads the verified package to GitLab's package registry, making it available for others to use.\n* Publishing Signatures: Makes signatures available for verification.\n* Consumer Verification: Simulates how end users can verify package authenticity.\n\n## Complete pipeline implementation: Setting up the environment\n\nBefore we build our package, we need to set up a consistent and secure build environment. This configuration ensures every package is created with the same tools, settings, and security checks.\n\n### Environment configuration\n\nOur pipeline requires specific tools and settings to work correctly.\n\nPrimary configurations:\n\n* Python 3.10 for consistent builds\n* Cosign 2.2.3 for package signing\n* GitLab package registry integration\n* Hardcoded package version for reproducibility\n\n**Note about versioning:** We've chosen to use a hardcoded version (`\"1.0.0\"`) in this example rather than deriving it from git tags or commits. This approach ensures complete reproducibility and makes the pipeline behavior more predictable. In a production environment, you might want to use semantic versioning based on git tags or another versioning strategy that fits your release process.\n\nTool requirements:\n\n* Basic utilities: `curl`, `wget`\n* Cosign for cryptographic signing\n* Python packaging tools: `build`, `twine`, `setuptools`, `wheel`\n\n### Configuration breakdown\n\n```yaml\nvariables:\n  PYTHON_VERSION: '3.10'\n  PACKAGE_NAME: ${CI_PROJECT_NAME}\n  PACKAGE_VERSION: \"1.0.0\"\n  FULCIO_URL: 'https://fulcio.sigstore.dev'\n  REKOR_URL: 'https://rekor.sigstore.dev'\n  CERTIFICATE_IDENTITY: 'https://gitlab.com/${CI_PROJECT_PATH}//.gitlab-ci.yml@refs/heads/${CI_DEFAULT_BRANCH}'\n  CERTIFICATE_OIDC_ISSUER: 'https://gitlab.com'\n  PIP_CACHE_DIR: \"$CI_PROJECT_DIR/.pip-cache\"\n  COSIGN_YES: \"true\"\n  GENERIC_PACKAGE_BASE_URL: \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${PACKAGE_NAME}/${PACKAGE_VERSION}\"\n```\n\nWe use caching to speed up subsequent builds:\n\n```yaml\ncache:\n  paths:\n    - ${PIP_CACHE_DIR}\n```\n\n## Building: Crafting the package\n\nEvery software journey begins with creation. In our pipeline, the build stage is where raw code transforms into a distributable package, ready to travel across different Python environments.\n\nThe build process creates two standardized formats:\n\n* a wheel package (.whl) for quick, efficient installation\n* a source distribution (.tar.gz) that carries the complete code\n\nHere's the build stage implementation:\n\n```yaml\nbuild:\n  extends: .python-job\n  stage: build\n  script:\n    - git init\n    - git config --global init.defaultBranch main\n    - git config --global user.email \"ci@example.com\"\n    - git config --global user.name \"CI\"\n    - git add .\n    - git commit -m \"Initial commit\"\n    - export NORMALIZED_NAME=$(echo \"${CI_PROJECT_NAME}\" | tr '-' '_')\n    - sed -i \"s/name = \\\".*\\\"/name = \\\"${NORMALIZED_NAME}\\\"/\" pyproject.toml\n    - sed -i \"s|\\\"Homepage\\\" = \\\".*\\\"|\\\"Homepage\\\" = \\\"https://gitlab.com/${CI_PROJECT_PATH}\\\"|\" pyproject.toml\n    - python -m build\n  artifacts:\n    paths:\n      - dist/\n      - pyproject.toml\n```\n\nLet's break down what this build stage does:\n\n1. Initializes a Git repository (`git init`) and configures it with basic settings\n2. Normalizes the package name by converting hyphens to underscores, which is required for Python packaging\n3. Updates the package metadata in `pyproject.toml` to match our project settings\n4. Builds both wheel and source distribution packages using `python -m build`\n5. Preserves the built packages and configuration as artifacts for subsequent stages\n\n## Signing: The digital notarization\n\nIf attestation is the package's biography, signing is its cryptographic seal of authenticity. This is where we transform our package from a mere collection of files into a verified, tamper-evident artifact.\n\nThe signing stage uses Cosign to apply a digital signature as an unbreakable seal. This isn't just a stamp — it's a complex cryptographic handshake that proves the package's integrity and origin.\n\n```yaml\nsign:\n  extends: .python+cosign-job\n  stage: sign\n  id_tokens:\n    SIGSTORE_ID_TOKEN:\n      aud: sigstore\n  script:\n    - |\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          cosign sign-blob --yes \\\n            --fulcio-url=${FULCIO_URL} \\\n            --rekor-url=${REKOR_URL} \\\n            --oidc-issuer $CI_SERVER_URL \\\n            --identity-token $SIGSTORE_ID_TOKEN \\\n            --output-signature \"dist/${filename}.sig\" \\\n            --output-certificate \"dist/${filename}.crt\" \\\n            \"$file\"\n        fi\n      done\n  artifacts:\n    paths:\n      - dist/\n```\n\nThis signing stage performs several crucial operations:\n\n1. Obtains an OIDC token from GitLab for authentication with Sigstore services\n2. Processes each built package (both wheel and source distribution)\n3. Uses Cosign to create a cryptographic signature (`.sig`) for each package\n4. Generates a certificate (`.crt`) that proves the signature's authenticity\n5. Stores both signatures and certificates alongside the packages as artifacts\n\n## Verification: The security checkpoint\n\nVerification is our final quality control gate. It's not just a check — it's a security interrogation where every aspect of the package is scrutinized.\n\n```yaml\nverify:\n  extends: .python+cosign-job\n  stage: verify\n  script:\n    - |\n      failed=0\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          if ! cosign verify-blob \\\n            --signature \"dist/${filename}.sig\" \\\n            --certificate \"dist/${filename}.crt\" \\\n            --certificate-identity \"${CERTIFICATE_IDENTITY}\" \\\n            --certificate-oidc-issuer \"${CERTIFICATE_OIDC_ISSUER}\" \\\n            \"$file\"; then\n            failed=1\n          fi\n        fi\n      done\n      if [ $failed -eq 1 ]; then\n        exit 1\n      fi\n```\n\nThe verification stage implements several security checks:\n\n1. Examines each package file in the `dist` directory\n2. Uses Cosign to verify the signature matches the package content\n3. Confirms the certificate's identity matches our expected GitLab pipeline identity\n4. Validates our trusted OIDC provider issued the certificate\n5. Fails the entire pipeline if any verification check fails, ensuring only verified packages proceed\n\n## Publishing: The controlled release\n\nPublishing is where we make our verified packages available through GitLab's package registry. It's a carefully choreographed release that ensures only verified, authenticated packages reach their destination.\n\n```yaml\npublish:\n  extends: .python-job\n  stage: publish\n  script:\n    - |\n      cat \u003C\u003C EOF > ~/.pypirc\n      [distutils]\n      index-servers = gitlab\n      [gitlab]\n      repository = ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi\n      username = gitlab-ci-token\n      password = ${CI_JOB_TOKEN}\n      EOF\n      TWINE_PASSWORD=${CI_JOB_TOKEN} TWINE_USERNAME=gitlab-ci-token \\\n        twine upload --repository-url ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi \\\n        dist/*.whl dist/*.tar.gz\n```\n\nThe publishing stage handles several important tasks:\n\n1. Creates a `.pypirc` configuration file with GitLab package registry credentials\n2. Uses the GitLab CI job token for secure authentication\n3. Uploads both wheel and source distribution packages to the GitLab PyPI registry\n4. Makes the packages available for installation via pip\n\n## Publishing signatures: Making verification possible\n\nAfter publishing the packages, we must make their signatures and certificates available for verification. We store these in GitLab's generic package registry, making them easily accessible to users who want to verify package authenticity.\n\n```yaml\npublish_signatures:\n  extends: .python+cosign-job\n  stage: publish_signatures\n  script:\n    - |\n      for file in dist/*.whl dist/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          curl --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --fail \\\n               --upload-file \"dist/${filename}.sig\" \\\n               \"${GENERIC_PACKAGE_BASE_URL}/${filename}.sig\"\n\n          curl --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --fail \\\n               --upload-file \"dist/${filename}.crt\" \\\n               \"${GENERIC_PACKAGE_BASE_URL}/${filename}.crt\"\n        fi\n      done\n```\n\nThe signature publishing stage performs these key operations:\n\n1. Processes each built package to find its corresponding signature files\n2. Uses the GitLab API to upload the signature (`.sig`) file to the generic package registry\n3. Uploads the corresponding certificate (`.crt`) file\n4. Makes these verification artifacts available for downstream package consumers\n5. Uses the same version and package name to maintain the connection between packages and signatures\n\n## Consumer verification: Testing the user experience\n\nThe final stage simulates how end users will verify your package's authenticity. This stage acts as a final check and a practical example of the verification process.\n\n```yaml\nconsumer_verification:\n  extends: .python+cosign-job\n  stage: consumer_verification\n  script:\n    - |\n      git init\n      git config --global init.defaultBranch main\n      mkdir -p pkg signatures\n\n      pip download --index-url \"https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi/simple\" \\\n          \"${NORMALIZED_NAME}==${PACKAGE_VERSION}\" --no-deps -d ./pkg\n\n      pip download --no-binary :all: \\\n          --index-url \"https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/api/v4/projects/${CI_PROJECT_ID}/packages/pypi/simple\" \\\n          \"${NORMALIZED_NAME}==${PACKAGE_VERSION}\" --no-deps -d ./pkg\n\n      failed=0\n      for file in pkg/*.whl pkg/*.tar.gz; do\n        if [ -f \"$file\" ]; then\n          filename=$(basename \"$file\")\n          sig_url=\"${GENERIC_PACKAGE_BASE_URL}/${filename}.sig\"\n          cert_url=\"${GENERIC_PACKAGE_BASE_URL}/${filename}.crt\"\n\n          curl --fail --silent --show-error \\\n               --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --output \"signatures/${filename}.sig\" \\\n               \"$sig_url\"\n\n          curl --fail --silent --show-error \\\n               --header \"JOB-TOKEN: ${CI_JOB_TOKEN}\" \\\n               --output \"signatures/${filename}.crt\" \\\n               \"$cert_url\"\n\n          if ! cosign verify-blob \\\n            --signature \"signatures/${filename}.sig\" \\\n            --certificate \"signatures/${filename}.crt\" \\\n            --certificate-identity \"${CERTIFICATE_IDENTITY}\" \\\n            --certificate-oidc-issuer \"${CERTIFICATE_OIDC_ISSUER}\" \\\n            \"$file\"; then\n            failed=1\n          fi\n        fi\n      done\n\n      if [ $failed -eq 1 ]; then\n        exit 1\n      fi\n```\n\nThis consumer verification stage simulates the end-user experience by:\n\n1. Creating a clean environment to test package installation\n2. Downloading the published packages from the GitLab PyPI registry\n3. Retrieving the corresponding signatures and certificates from the generic package registry\n4. Performing the same verification steps that end users would perform\n5. Ensuring the entire process works from a consumer's perspective\n6. Failing the pipeline if any verification step fails, providing an early warning of any issues\n\n## Summary\n\nThis comprehensive pipeline provides a secure and reliable way to build, sign, and publish Python packages to GitLab's package registry. By following these practices and implementing the suggested security measures, you can ensure your packages are appropriately verified and safely distributed to your users.\n\nThe pipeline combines modern security practices with efficient automation to create a robust software supply chain. Using Sigstore's Cosign for signing and attestation, along with GitLab's built-in security features, you can provide users with trustworthy cryptographically verified packages.\n\n> #### Get started on your security journey today with a [free 60-day trial of GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com).\n\n## Learn more\n- [Documentation: Use Sigstore for keyless signing and verification](https://docs.gitlab.com/ee/ci/yaml/signing_examples.html)\n- [Streamline security with keyless signing and verification in GitLab](https://about.gitlab.com/blog/keyless-signing-with-cosign/)\n- [Annotate container images with build provenance using Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd/)",[704,230,281,9,1396,108,478,746,1813],{"slug":5378,"featured":90,"template":683},"secure-and-publish-python-packages-a-guide-to-ci-integration","content:en-us:blog:secure-and-publish-python-packages-a-guide-to-ci-integration.yml","Secure And Publish Python Packages A Guide To Ci Integration","en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration.yml","en-us/blog/secure-and-publish-python-packages-a-guide-to-ci-integration",{"_path":5384,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5385,"content":5391,"config":5396,"_id":5398,"_type":13,"title":5399,"_source":15,"_file":5400,"_stem":5401,"_extension":18},"/en-us/blog/secure-and-safe-login-and-commits-with-gitlab-yubico",{"title":5386,"description":5387,"ogTitle":5386,"ogDescription":5387,"noIndex":6,"ogImage":5388,"ogUrl":5389,"ogSiteName":670,"ogType":671,"canonicalUrls":5389,"schema":5390},"Secure and safe login and commits with GitLab + Yubico","Learn how GitLab and Yubico have partnered to strengthen software development security through robust authentication measures.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663259/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images__3_.png","https://about.gitlab.com/blog/secure-and-safe-login-and-commits-with-gitlab-yubico","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure and safe login and commits with GitLab + Yubico\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-02\",\n      }",{"title":5386,"description":5387,"authors":5392,"heroImage":5388,"date":5393,"body":5394,"category":704,"tags":5395},[2234],"2025-04-02","We live in a time where data breaches and phishing attacks make daily headlines. These breaches can cause harm to an organization, such as regulatory fines, business downtime, or even worse, reputational damage. In terms of authentication, passwords have been the backbone of online security for decades, however, they're increasingly proving inadequate against sophisticated cyber threats.\n\nGitLab and [Yubico](https://www.yubico.com/) have partnered to strengthen software development security through robust authentication measures. Yubico is the inventor of the YubiKey, a hardware security key that delivers phishing-resistant multi-factor authentication (MFA). By implementing FIDO Universal 2nd Factor (U2F) and YubiKey hardware protection, GitLab offers developers a powerful defense against phishing attacks and other cyber threats, ensuring their code and projects remain secure. This collaboration expands enterprise-grade authentication in the GitLab platform, allowing programmers to focus on creating software while maintaining confidence in their account's integrity.\n\nThis article explains how to configure GitLab to use YubiKeys to protect developers from online threats. You’ll also learn how to further prevent tampering with GitLab verified commits.\n\n## How YubiKeys work\n\nAt their core, YubiKeys function as cryptographic hardware tokens that generate and store private keys in a secure element. These keys implement FIDO2/WebAuthn authentication protocols, which can be used as an additional factor to login to GitLab.\n\nHere's how it works when logging in:\n\n1. You enter your username and password.  \n2. GitLab sends a cryptographic challenge to your browser.  \n3. Your browser requests the YubiKey to sign this challenge.  \n4. You physically touch the YubiKey to approve.\n5. The YubiKey creates a unique cryptographic signature for that specific service and challenge.  \n6. GitLab verifies the signature using your public key stored during setup.\n\nMost major security breaches involve compromised passwords. Adding a YubiKey secures your account from a remote breach, even if your password is stolen, so you can rest assured that your GitLab account is secure. Additional key security benefits of using YubiKey for authentication with GitLab include:\n\n* **Phishing protection:** Fake sites won't have the correct cryptographic keys to verify the response. \n* **No secrets to steal:** The private key never leaves the YubiKey.  \n* **Physical security:** Physical presence is required to use it (you must touch the YubiKey).\n\n## Setting up YubiKey multifactor authentication in GitLab\n\nNow let’s go over how to set up a Yubikey for multifactor authentication in GitLab. Make sure you're using a [supported browser and operating system](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F) as they have better WebAuthn support for hardware security keys.\n\n1. First, log in to your GitLab account and go to your user settings (click your avatar in the top left corner and select **Preferences**). \n2. In the left sidebar, click on **Account** and navigate to the **Two-factor Authentication** section.\n3. If you haven't already enabled 2FA, you'll need to do that first.\n\n    a. Click **Enable two-factor authentication**.\n\n    b. Scan the QR code with your authenticator app.\n\n    c. Enter the code from your authenticator app.\n\n    d. Enter your GitLab password. If you ever need to access your GitLab account without using Google authentication, you may need to:\n    * Use the **Forgot password** option on the GitLab login page to set up a separate GitLab password.\n    * Contact your GitLab administrator to help you set up alternative login methods.\n\n   e. Save your recovery codes in a safe place.\n\n4. Once 2FA is enabled, go back to the previous screen by pressing **Manage two-factor authentication** and scroll down to the **Register hardware token** section.  \n5. Press the **Set up new device** button.  \n    a. A popup from your browser should appear. **Note:** This image may look different depending on your browser. You may also get popups from password managers feel free to ignore them. \n\n![Browser (Brave) Auth Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674606/Blog/Content%20Images/browser_auth_request.png)\n\n    b. Select **Use a phone, tablet, or security key**.\n\n6. A new popup will appear.\n\n![browser security key request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/browser_security_key_request.png)\n\n    a. Insert your YubiKey into your computer's USB port.\n\n    b. Touch the metal contact/button on your YubiKey when prompted. The field will automatically fill with a one-time code.\n\n7. Enter your GitLab Password and provide a name for your Hardware Key.  \n8. Click **Register** to add the YubiKey to your account.\n\nCongratulations, your YubiKey is now registered and can be used as a second factor when logging into GitLab! You can register multiple YubiKeys to your account for backup purposes. **Note:** The process may vary slightly among browsers.\n\n![yubikey registered](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/yubikey_registered.png)\n\n\u003Ccenter>\u003Ci>YubiKey registered successfully\u003C/i>\u003C/center>\n\n## Signing in with a YubiKey\n\nNow that we have our YubiKey configured, we can log in as follows:\n\n1. Go to GitLab.com.\n\n![GitLab login](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/gitlab_login.png)\n\n2. Provide your username and password and then press the **Sign in** button.\n3. You will be sent to the following screen.\n\n![GitLab 2fa login](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674606/Blog/Content%20Images/2fa_login.png)\n\n    a. A popup, like the one below, should come up. **Note:** This image may look different depending on your browser. You may also get popups from password managers; feel free to ignore them.\n\n![Browser security key request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/browser_security_key_request.png)\n\n    b. Insert your YubiKey into your computer's USB port.\n\n    c. Touch the metal contact/button on your YubiKey when prompted. The field will automatically fill with a one-time code.\n\nNow, you should be logged in and taken to your GitLab page. **Note:** The process may vary slightly among browsers.\n\n## What happens if I lose my YubiKey?\n\nYubico recommends that you use and keep a backup YubiKey. When considering your home, car, or office, you wouldn’t think twice about having a backup key to keep in a safe place. Your digital self should get the same level of consideration. A backup YubiKey kept in a safe place provides a quick and safe backup if your primary YubiKey is lost. Keeping a backup will also easily enable you to deactivate the lost YubiKey and add a new primary or secondary YubiKey.\n\nIf you do not have an additional YubiKey added, it is recommended to have another form of 2FA added to your accounts. In either case, you should be able to get access to your account and remove the lost key from the account. Please note that if a spare key or another authentication method hasn’t been added, you will need to contact the service/website for help with recovering your account.\n\n## GitLab verified commits\n\nTo further prevent tampering, you can also configure verified commits. Verified commits in GitLab use GPG (GNU Privacy Guard) signatures to prove that a commit actually came from you. This adds another layer of security on top of authentication by ensuring that not only is your account secure, but every code change can be cryptographically verified as coming from you.\n\nYour YubiKey can store GPG keys:\n\n* The private key is stored securely on the YubiKey.  \n* The public key is shared with GitLab.\n* The key pair is used to sign your commits.\n\nOnce the GPG keys have been set up:\n\n* When you make a commit, Git uses your private key to create a signature.  \n* The GPG key is accessed from the attached YubiKey.  \n* The signature is stored with the commit metadata.  \n* GitLab verifies the signature using your public key.\n\n## Setting up verified commits\n\nLet’s go over how to configure verified commits. In this example, the GPG key will live inside your YubiKey, providing an extra layer of security.\n\n1. Install required software.\n\n```bash\n# On macOS\nbrew install --cask yubico-yubikey-manager\nbrew install gnupg gpg yubikey-manager\n\n# On Ubuntu/Debian\nsudo apt install gnupg gpg yubikey-personalization\n\n# On Windows\n# Download and install Gpg4win from https://gpg4win.org\n```\n\n2. Check YubiKey GPG status.\n\n```bash\ngpg --card-status\n```\n3. Generate GPG keys directly on YubiKey (more secure).\n\n```bash\n# Start GPG edit mode\ngpg --card-edit\n\n# Enter admin mode\nadmin\n\n# Generate key directly on card\n# PIN = '123456' | Admin PIN = '12345678'\ngenerate\n\n# Follow prompts\n# See documentation for more info \n# https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP\n```\n\n4. Export your public key.\n\n```bash\n# Get your key ID\ngpg --list-secret-keys --keyid-format LONG\n\n# Export the public key\ngpg --armor --export YOUR_KEY_ID\n```\n\n5. Add the public key to GitLab.\n\n    a. Click on your GitLab Avatar and select **Preferences**.\n\n    b. On the side tab select **GPG Keys**.\n\n    c. Click **Add new key**.\n\n    d. Paste your public key.\n\n    e. Click **Add key**.\n\n6. Configure Git.\n\n```bash\n# Set signing key\ngit config --global user.signingkey YOUR_KEY_ID\n\n# Enable automatic signing\ngit config --global commit.gpgsign true\n\n# Tell GPG which key to use\necho \"default-key YOUR_KEY_ID\" >> ~/.gnupg/gpg.conf\n```\n\n7. Now let’s test the configuration by creating a test commit in a project:\n\n```bash\n# Make a change in the project\n# Add changes\ngit add .\n\n# Make a test commit\ngit commit -S -m \"Test signed commit\"\n\n# Verify signature\ngit verify-commit HEAD\n\n# Push the change\ngit push\n```\n\nThe `git verify-commit HEAD` command should show the GPG key used:\n\n```bash\ngpg: Signature made Wed Feb 26 11:45:00 2025 CST\ngpg:                using RSA key YOUR_KEY_ID\ngpg: Good signature from “NAME (DESCRIPTION) \u003CEMAIL>\" [ultimate]\n```\n\nThen, when viewing the commit in GitLab, you should now see that the commit is verified as follows:\n\n![Commit is verified](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674607/Blog/Content%20Images/verified.png)\n\n\u003Ccenter>\u003Ci>Commit verified with GPG key\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nYou can also use the [commits API](https://docs.gitlab.com/api/commits/#get-signature-of-a-commit) to check a commit’s signature allowing you to further operationalize the verification workflow.\n\n## Learn more\n\nTo learn more about GitLab, Yubico, and the solutions each provides, check out these resources:\n\n* [Why GitLab](https://about.gitlab.com/why-gitlab/)  \n* [Why Yubico](https://www.yubico.com/why-yubico/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab listing in the \"Works with YubiKey\" catalog](https://www.yubico.com/works-with-yubikey/catalog/gitlab/)  \n* [Verified Commits - GitLab documentation](https://docs.gitlab.com/ee/user/project/repository/signed_commits/)  \n* [Push Rules in GitLab](https://docs.gitlab.com/user/project/repository/push_rules/)  \n* [Sign Commit with GPG Keys documentation](https://docs.gitlab.com/user/project/repository/signed_commits/gpg/)\n",[230,704,746,478,701,9],{"slug":5397,"featured":90,"template":683},"secure-and-safe-login-and-commits-with-gitlab-yubico","content:en-us:blog:secure-and-safe-login-and-commits-with-gitlab-yubico.yml","Secure And Safe Login And Commits With Gitlab Yubico","en-us/blog/secure-and-safe-login-and-commits-with-gitlab-yubico.yml","en-us/blog/secure-and-safe-login-and-commits-with-gitlab-yubico",{"_path":5403,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5404,"content":5410,"config":5415,"_id":5417,"_type":13,"title":5418,"_source":15,"_file":5419,"_stem":5420,"_extension":18},"/en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features",{"title":5405,"description":5406,"ogTitle":5405,"ogDescription":5406,"noIndex":6,"ogImage":5407,"ogUrl":5408,"ogSiteName":670,"ogType":671,"canonicalUrls":5408,"schema":5409},"Secure, compliant, and AI-powered: Get to know 3 new GitLab features","Enhance security, leverage new AI capabilities, and protect sensitive data with our latest platform improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","https://about.gitlab.com/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Secure, compliant, and AI-powered: Get to know 3 new GitLab features\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jessica Hurwitz\"}],\n        \"datePublished\": \"2025-01-27\",\n      }",{"title":5405,"description":5406,"authors":5411,"heroImage":5407,"date":5412,"body":5413,"category":701,"tags":5414},[951],"2025-01-27","AI capabilities are rapidly reshaping how teams build, secure, and deploy applications. As part of our ongoing commitment to helping you navigate the evolving marketplace, GitLab has introduced more than 440 improvements in the past three releases. We're excited to spotlight three standout features making an immediate impact on how teams approach AI-powered DevSecOps. In addition, we announced we are partnering with AWS to launch [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai/), combining our strengths to transform software development. We're creating an experience, together, that makes AI-powered development feel seamless and upholds the security, compliance, and reliability that enterprises require.\n\n> Learn how GitLab can [deliver 483% ROI over the next three years](https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years/), according to Forrester Consulting.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://player.vimeo.com/video/1056012314?badge=0\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" title=\"GitLab 17.6-17.8 Quarterly Release Overview\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 1. Vulnerability Resolution: Streamline security remediation\n\nGitLab’s 2024 [Global DevSecOps Report](https://about.gitlab.com/developer-survey/) found that 66% of companies are releasing software twice as fast — or faster — than in previous years, as businesses strive to deliver more value to their customers than competitors. However, speed introduces risk. With security teams [outnumbered by dev teams 80:1](https://www.opentext.com/assets/documents/en-US/pdf/developer-driven-appsec-security-at-the-speed-of-devops-pp-en.pdf), threat actors are able to exploit applications at a record pace. Last year alone, [80% of the top data breaches](https://www.crowdstrike.com/2024-state-of-application-security-report/) stemmed from attacks at the application layer.\n\n[GitLab Duo Vulnerability Resolution](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution) addresses this challenge head-on. When vulnerabilities are detected in your code, you can now access detailed information right from the vulnerability report and invoke GitLab Duo to automatically create a merge request that updates your code and mitigates the risk. While developers must review these auto-generated merge requests before merging to verify the changes, this automation significantly streamlines the remediation process. Vulnerability Resolution pairs with [Vulnerability Explanation](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/), which also recently became generally available. Vulnerability Explanation gives developers a detailed description of the vulnerability infecting their code, real-world examples of how attackers can exploit the vulnerable code, and practical suggestions for remediation.\n\nBy expediting the vulnerability remediation process, your teams can focus on delivering software faster while maintaining strong security practices. With less time spent researching and remediating vulnerabilities, developers can concentrate on building features that drive business value.\n\n_GitLab Duo Vulnerability Resolution is available as a [GitLab Duo Enterprise add-on](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"\nhttps://www.youtube.com/embed/VJmsw_C125E?si=W7n1ESS63xkPyH4H\" frameborder=\"0\" title=\"GitLab Vulnerability Resolution\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 2. Model Registry: Breaking down silos between Data Science and Development teams\n\nFor organizations building AI-powered applications, bridging the gap between data science and software development teams has been a persistent challenge. Data scientists and developers often work in disconnected tools and workflows, leading to friction, delays, and potential errors when deploying models to production.\n\n[GitLab Model Registry](https://docs.gitlab.com/ee/user/project/ml/model_registry/) directly addresses this challenge by providing a centralized hub where data science and development teams can collaborate seamlessly within their existing GitLab workflow. Built with [MLflow](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/mlflow_client.html#model-registry) native integration, the registry allows data scientists to continue using their preferred tools while making models and artifacts instantly accessible to the broader development team.\nThis unified approach transforms team collaboration. Data scientists can version models, store artifacts, and document model behavior through comprehensive model cards, while developers can easily integrate these models into their applications using GitLab CI/CD pipelines for automated testing and deployment.\n\nAdditionally, the Model Registry's semantic versioning and GitLab API integration enables teams to implement robust governance and automate production deployments, creating a streamlined environment where data scientists and developers can work together effectively to deliver AI-powered innovation.\n\n_Model Registry is available across all tiers for SaaS and self-managed customers. See the [release blog for 17.6](https://about.gitlab.com/releases/2024/11/21/gitlab-17-6-released/#model-registry-now-generally-available) and [documentation](https://docs.gitlab.com/ee/user/project/ml/model_registry/) for more._\n\n## 3. Secret Push Protection: Shift security left with proactive secret detection\n\nTeams often face a critical security challenge: Developers may hardcode sensitive information like API keys, tokens, and credentials as plain text in source code repositories, sometimes without even realizing it. This creates an easy target for threat actors and puts your organization at risk.\n\n[Secret Push Protection](https://about.gitlab.com/blog/prevent-secret-leaks-in-source-code-with-gitlab-secret-push-protection/) directly addresses this problem by blocking developers from pushing code that contains secrets, significantly reducing the likelihood of a breach. It works by leveraging customizable rules to identify high-confidence secrets before they ever reach your repository.\n\nWhat makes this solution particularly powerful is its integration with our pipeline secret detection, creating a comprehensive defense strategy.\n\n_Secret Push Protection is now generally available for all [GitLab Ultimate tier](https://about.gitlab.com/pricing/ultimate/) and [GitLab Dedicated](https://about.gitlab.com/dedicated/) customers._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"\nhttps://www.youtube.com/embed/SFVuKx3hwNI?si=aV_3Lazs2AiDH3Jf\" title=\"Introduction to Secret Push Protection\" frameborder=\"0\" title=\"GitLab Vulnerability Resolution\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Put these features to work today\n\nAt GitLab, we’re committed to making it easier for teams to build software, faster. Capabilities like GitLab Duo Vulnerability Resolution, Model Registry, and Secret Push Protection are just a few of the recent innovations we’ve delivered to help developers and security teams level up their DevSecOps workflows. To learn more, check out our [releases page](https://about.gitlab.com/releases/categories/releases/).\n\n> Get started with these new features today with [a free, 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/).\n",[703,478,9,701,704],{"slug":5416,"featured":90,"template":683},"secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features","content:en-us:blog:secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features.yml","Secure Compliant And Ai Powered Get To Know 3 New Gitlab Features","en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features.yml","en-us/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features",{"_path":5422,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5423,"content":5428,"config":5433,"_id":5435,"_type":13,"title":5436,"_source":15,"_file":5437,"_stem":5438,"_extension":18},"/en-us/blog/secure-composition-analysis-bug-not-updating-database",{"title":5424,"description":5425,"ogTitle":5424,"ogDescription":5425,"noIndex":6,"ogImage":1055,"ogUrl":5426,"ogSiteName":670,"ogType":671,"canonicalUrls":5426,"schema":5427},"Bug found and resolved in Dependency Scanning","Some customers will need to take specific action to manually update their Dependency Scanning image to receive a bug fix.","https://about.gitlab.com/blog/secure-composition-analysis-bug-not-updating-database","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bug found and resolved in Dependency Scanning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n        \"datePublished\": \"2021-02-19\",\n      }",{"title":5424,"description":5425,"authors":5429,"heroImage":1055,"date":5430,"body":5431,"category":1353,"tags":5432},[1589],"2021-02-19","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nDependency Scanning relies on the GitLab [Vulnerability Database](https://about.gitlab.com/direction/secure/vulnerability-research/advisory-database/) (called [gemnasium-db](https://gitlab.com/gitlab-org/security-products/gemnasium-db)) to provide it with the latest advisory data (i.e. CVEs). Dependency Scanning docker images are built and released with the latest version of the database and in addition, the analyzers update this database to the latest version at the time of a scan. \n\nHowever, starting with version 2.8.1 of the Dependency Scanning analyzer called gemnasium, the vulnerability database was [not updating itself at scan time](https://gitlab.com/gitlab-org/gitlab/-/issues/294296). Versions between v2.8.1 (released 2020-03-30) and v2.28.0 (released 2021-02-03) are affected by this bug. As a result, since the introduction of the bug, scan results would only be able to identify advisories published on or before the analyzer image release date. In some cases this meant that the advisories' Dependency Scanning analyzers were outdated by several weeks (relying only on the database checked out at image build time).\n\nWe are concerned that this bug made it out to customers and are performing a [root cause analysis](https://gitlab.com/gitlab-org/gitlab/-/issues/321315).\n\nMost customers will receive the bug fix automatically and will have the latest advisory database the next time their Dependency Scanning jobs run. But customers with their own copy of the GitLab container registry or dedicated runners with a docker pull-policy other than always, must take the manual action to pull or update your pin to the latest image (or at least one that is not impacted by this bug). Users that must take this manual action are:\n\n- Customers with an edited Dependency Scanning template that pins their analyzers to a non-major-only tag (for example gemnasium:2.27.0 rather than gemnasium:2)\n- Customers running in an [Offline Environment](https://docs.gitlab.com/ee/user/application_security/offline_deployments/) with their own container registry mirroring GitLab's\n- Self-managed customers or customers with their own docker runners using a pull policy other than `always`\n\nThe three analyzer types that are affected are the gemnasium analyzer, the gemnasium-python and gemnasium-maven analyzer. The affected versions of each are:\n\n- gemnasium v2.8.1 to v2.28.0: update to v2.28.1 or above\n- gemnasium-python v2.11.0 to v2.17.2: update to v2.17.3 or above\n- gemnasium-maven v2.13.0 to v2.20.3: update to v2.20.4 or above\n\nTL;DR - If you are using Dependency Scanning analyzers and are not always pulling their docker images from GitLab's docker container registry, please update your analyzers' docker images promptly in order to sync the analyzers with the latest available advisories.\n\n{: .note}\n",[9,704,872],{"slug":5434,"featured":6,"template":683},"secure-composition-analysis-bug-not-updating-database","content:en-us:blog:secure-composition-analysis-bug-not-updating-database.yml","Secure Composition Analysis Bug Not Updating Database","en-us/blog/secure-composition-analysis-bug-not-updating-database.yml","en-us/blog/secure-composition-analysis-bug-not-updating-database",{"_path":5440,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5441,"content":5447,"config":5451,"_id":5453,"_type":13,"title":5454,"_source":15,"_file":5455,"_stem":5456,"_extension":18},"/en-us/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation",{"title":5442,"description":5443,"ogTitle":5442,"ogDescription":5443,"noIndex":6,"ogImage":5444,"ogUrl":5445,"ogSiteName":670,"ogType":671,"canonicalUrls":5445,"schema":5446},"SecureFlag integrated with GitLab for rapid vulnerability remediation","Empower developers with hands-on security training within the DevSecOps platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679321/Blog/Hero%20Images/cover_image_secureflag.png","https://about.gitlab.com/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SecureFlag integrated with GitLab for rapid vulnerability remediation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2023-06-29\",\n      }",{"title":5442,"description":5443,"authors":5448,"heroImage":5444,"date":3312,"body":5449,"category":704,"tags":5450},[2114],"\n\nAs part of our commitment to developer-led security, GitLab has integrated SecureFlag's vulnerability remediation training for developers into the DevSecOps platform. [SecureFlag’s training](https://www.secureflag.com/solutions?utm_source=blog&utm_medium=organic&utm_campaign=GitLab+blog) is unique as it offers labs where developers can learn to remediate vulnerabilities in a live environment. \n\nOften, organizations attempt to address vulnerabilities by referring to incomplete or misleading advice. This not only hinders the remediation process, but might lead to additional insecure applications and increased risk. With the SecureFlag integration with GitLab, organizations can continue to shift security left in the software development lifecycle, gaining more insight, oversight, and control of their assets, processes, and overall security posture. Real-time access to vulnerability information ensures consistent, up-to-date, and trustworthy guidance and documentation for tackling the remediation of security findings.\n\nWhen developers receive GitLab vulnerability scan results on the DevSecOps platform, SecureFlag provides a clear understanding of the identified vulnerabilities, indicates the best way to remediate them, and presents hands-on labs for practice.\n\n## How the SecureFlag-GitLab integration works\nGitLab's security scanners detect vulnerabilities when merging to a default branch. These vulnerabilities surface in the merge request and pipeline or in the Vulnerability Report. Once a vulnerability is identified, SecureFlag integration steps in to streamline the vulnerability remediation process. Using the information provided in the vulnerability details, SecureFlag generates a link to a training resource for the developer, which provides guidance throughout the remediation of that specific security problem.\n\n![Developer Workflow](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/developer-workflow.png){: .shadow}\n\n\nBy clicking on the link, developers are led to a knowledge base article that illustrates, with code examples, how to address a vulnerability in the specific programming language. Moreover, they can start a hands-on lab in a few seconds and practice their remediation skills before diving into the actual work. This level of preparedness has enabled organizations to significantly decrease the number of security retests, as developers now know exactly what to do and are often able to fix the issue on their first attempt.\n\n![SecureFlag SQL Injection Page](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/secureflag-knowledge-base.png){: .shadow}\n\n\n## SecureFlag's hands-on labs\nSecureFlag’s hands-on labs stand out as a powerful learning tool for developers. Labs comprise a complete virtualized desktop computer with a real development environment unique to the programming language in question. Labs are spun up in seconds and are designed to facilitate effective and engaging training experiences with the goal of maximizing retention.\n\n![SecureFlag Lab](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/secureflag-lab.gif){: .shadow}\n\n\nSecureFlag labs feature:\n- support for over 45+ technologies\n- multiple difficulty levels and scenarios for each vulnerability\n- gamified learning with points, trophies, and certifications\n- adaptive training based on previous results\n\n## How to install and configure SecureFlag training on GitLab\nSecureFlag training is available to all GitLab Ultimate customers and can be enabled for any project. Additional details can be found [here](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#enable-security-training-for-vulnerabilities).\n![Security Training Settings](https://about.gitlab.com/images/blogimages/2023-06-15-empowering-developers-via-GitLab-integrating-SecureFlag-for-rapid-vulnerability-remediation/security-training-settings.png){: .shadow}\n\n\nOnce installed, you can view the results from a GitLab security scan (including GitLab’s integration partners) in a merge request, the pipeline security tab, or a vulnerability details page. When you open a vulnerability record, you will see a direct link to the training. GitLab then pulls a training module from SecureFlag that best matches the specific security issue and the appropriate language or framework in which it was detected.\n\nThe integration of SecureFlag within GitLab enhances the robustness of an organization's security strategy by enabling a proactive, developer-led security approach. The training material and hands-on labs ensure that developers are well-equipped to handle any identified vulnerabilities, thus reducing remediation time and increasing your overall project security.\n",[704,703,701,9],{"slug":5452,"featured":6,"template":683},"secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation","content:en-us:blog:secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation.yml","Secureflag Integrated With Gitlab For Rapid Vulnerability Remediation","en-us/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation.yml","en-us/blog/secureflag-integrated-with-gitlab-for-rapid-vulnerability-remediation",{"_path":5458,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5459,"content":5465,"config":5471,"_id":5473,"_type":13,"title":5474,"_source":15,"_file":5475,"_stem":5476,"_extension":18},"/en-us/blog/security-culture-devsecops",{"title":5460,"description":5461,"ogTitle":5460,"ogDescription":5461,"noIndex":6,"ogImage":5462,"ogUrl":5463,"ogSiteName":670,"ogType":671,"canonicalUrls":5463,"schema":5464},"DevSecOps basics: how to build a security culture in 6 steps","How to build a DevSecOps culture in your workplace. Get there faster by creating a strong security culture.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663608/Blog/Hero%20Images/security-culture-devsecops.jpg","https://about.gitlab.com/blog/security-culture-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOps basics: how to build a security culture in 6 steps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n        \"datePublished\": \"2020-07-15\",\n      }",{"title":5460,"description":5461,"authors":5466,"heroImage":5462,"date":5468,"body":5469,"category":1249,"tags":5470},[5467],"Vanessa Wegner","2020-07-15","\n_This is the fourth in our five-part series on [DevSecOps](/topics/devsecops/) basics. Part one offers nine tips to truly [shift left](/blog/efficient-devsecops-nine-tips-shift-left/). Part two outlines the steps needed to create [silo-free collaboration](/blog/achieve-devsecops-collaboration/). And part three looks at the importance of [automated security testing](/blog/devsecops-security-automation/)._\n\n## Are you responsible for security?\n\nEven if it’s not in your title or job description, the answer is yes. Every employee is responsible for the security of their work. Unfortunately, many organizations don’t make this clear and don’t enforce it as policy. As vulnerabilities pile up on the desks of security engineers, developers wonder what’s taking so long – how many times does code have to be fixed before it’s deemed secure? [DevSecOps](/solutions/security-compliance/) flips traditional security on its head, but needs a strong security culture for sustainable success.\n\n## What is security culture?\n\nA security culture means that everyone – from board members to interns – must care about security and take actions to maintain it. Security should be considered in every piece of work and at every decision. \n\nThis may seem counterintuitive and not the efficiency promised by [DevSecOps](https://about.gitlab.com/solutions/security-compliance/). But by embedding security into every employee’s actions, the security team’s workload is streamlined and the end product is more secure. This is what companies mean when they talk about shifting security left: Bringing security forward in the software development life cycle to improve planning, test more code, and build accountability among non-security team members. \n\n## How to make security culture your default state\n\nUnless you’ve included security in every employee’s onboarding, creating a widespread security culture mindset will be challenging. Employees will need to think differently, behave differently, and eventually turn those changes into habits so that security becomes a natural part of their day-to-day work. \n\n### Step 1: Culture change starts at the top\n\nIf your organization has left security to \"the team,\" moving to a security culture will require board members and executives to be very involved in this change. Once execs are on board, work with thought leaders across the company to develop a security awareness and training program. Set the tone by making security a company-wide initiative, letting everyone know that security is top priority regardless of job function or organization. \n\n### Step 2: Awareness, education, and mutual understanding\n\nGive employees training on how they should incorporate security practices into everything they do. Transparency is key to building trust, so it’s important that employees understand why security is necessary and how they can contribute to the overall goal. On the other side, educate security practitioners about the demands placed on the business and [DevOps practices](/topics/devops/). This will help them help you create policies that move security and development forward together. \n\n### Step 3: Appoint security champions in dev \n\nSome employees will adopt security enthusiastically. Recruit those people to champion awareness and adoption among their peers. It may be helpful to provide your security champions extra resources and educational opportunities to boost their knowledge and make them an accessible resource for those around them. \n\n### Step 4: Encourage cross-functional collaboration\n\nTeam members should feel comfortable reaching out across functions, asking questions, and sharing (non-sensitive) information. DevSecOps breaks down silos to create a more efficient process, but it also does this to improve communication and build camaraderie between teams. If security is made into a multi-team effort, employees will feel encouraged to jump on the secure work bandwagon. \n\n### Step 5: Give developers the tools they need\n\nSecurity behaviors will be more readily adopted if they fit seamlessly into the developer’s workflow. [Security as code](/blog/how-to-security-as-code/) plays a big role here: Developers can produce more secure work when policies, tests, and scans are integrated into the pipeline and code itself. Excessive tool-switching will negate the benefits of shifting left, so it’s best to maintain efficiency by keeping your tech stack as simple as possible.\n\n### Step 6: Automate when appropriate\n\nAutomation is crucial for scaling security and will make adoption even easier for non-security employees. Within the developer’s workflow, static [application security](/topics/devsecops/) tests can be run against every code commit. Those scans can automatically produce a work ticket or [populate a security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/). \n\n## Culture change: Worth the challenge\n\nSecurity isn’t an option: It’s a requirement. Security culture will always be worth the effort. Making security a top priority for the people in your organization will fortify your tech defenses and help you innovate in ways that will (hopefully) withstand the ever-changing threat landscape. \n\n_How efficient are your DevSecOps practices? [Take our DevSecOps Maturity Assessment to find out.](https://about.gitlab.com/resources/devsecops-methodology-assessment/)_\n\n**Learn more about DevSecOps:**\n* [How to harden your GitLab instance](/blog/gitlab-instance-security-best-practices/)\n\n* [Why DevSecOps must start with automated security testing](/blog/devsecops-security-automation/)\n\n* [How to capitalize on GitLab Security tools with external CI](https://docs.gitlab.com/ee/integration/jenkins.html)\n\nCover image by [Lindsay Henwood](https://unsplash.com/@lindsayhenwood) on [Unsplash](https://unsplash.com/photos/7_kRuX1hSXM)\n{: .note}\n",[851,704,9],{"slug":5472,"featured":6,"template":683},"security-culture-devsecops","content:en-us:blog:security-culture-devsecops.yml","Security Culture Devsecops","en-us/blog/security-culture-devsecops.yml","en-us/blog/security-culture-devsecops",{"_path":5478,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5479,"content":5485,"config":5490,"_id":5492,"_type":13,"title":5493,"_source":15,"_file":5494,"_stem":5495,"_extension":18},"/en-us/blog/security-features-in-ultimate",{"title":5480,"description":5481,"ogTitle":5480,"ogDescription":5481,"noIndex":6,"ogImage":5482,"ogUrl":5483,"ogSiteName":670,"ogType":671,"canonicalUrls":5483,"schema":5484},"Tired of afterthought security? Take a fresh look at GitLab Ultimate","Security may not be the first thing that comes to mind when thinking of our DevOps platform, but we’re going to make the case it should be. Here’s a look at some of the too-often-overlooked security features in GitLab Ultimate.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667202/Blog/Hero%20Images/gitlabultimatesecurity.jpg","https://about.gitlab.com/blog/security-features-in-ultimate","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tired of afterthought security? Take a fresh look at GitLab Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cindy Blake\"}],\n        \"datePublished\": \"2020-12-08\",\n      }",{"title":5480,"description":5481,"authors":5486,"heroImage":5482,"date":5487,"body":5488,"category":704,"tags":5489},[3370],"2020-12-08","At GitLab, we have worked hard to make [application security testing](/topics/devsecops/) a natural by-product of software development. We started with the developer, bringing scan results into their native workflow, then we added a dashboard for the security pro. We acquired Gemnasium and most recently [Peach Tech and Fuzzit](/blog/fuzz-testing/). We have a board goal to be a world-class security product and have allocated just under 25% of our R&D budget to these capabilities. \n\nWe know our SAST, dependency, container, and other scanners are great but we’d also bought into the idea that people choose to use our [DevOps platform](/solutions/devops-platform/) largely because of CI or SCM and our security is just an added bonus. \n\nBut it seems we are our own worst critic, especially on how we determine product maturity. Data points include:\n\n* The technology review site G2 shows [GitLab’s static application security testing (SAST) is top rated](https://www.g2.com/categories/static-application-security-testing-sast#grid). \n* As of Dec. 4, 2020, GitLab has an Overall Rating of 4.6 out of 5 in the Application Security Testing market on [Gartner Peer Insights](https://www.gartner.com/reviews/market/application-security-testing/vendor/gitlab/product/gitlab), based on 32 reviews.\n  * _Gartner Peer Insights reviews constitute the subjective opinions of individual end users based on their own experiences and do not represent the views of Gartner or its affiliates._\n* Dev-Insider 2020 Platinum award for [best code and composition analysis](https://www.storage-insider.de/die-leser-haben-entschieden-die-gewinner-der-it-awards-2020-a-973498/).\n\nAnd customers are noticing too:\n\n* “GitLab Secure replaced Veracode, Checkmarx, and Fortify in my DevOps toolchain. GitLab scans faster, is more accurate, and doesn’t require my developers to learn new tools.” \t\n\n* “GitLab Secure enables us to ship faster. Our other scanner tools could take up to a day to finish scanning whereas GitLab scans finish in as little a few minutes.” \n\nHere’s a look at other built-in security features in Ultimate for self hosted and Gold for SaaS.\n\n## Vulnerability scans (no assembly required)\n\nIf there are two truths in security, it’s these: The more you scan, the less risk you will have, and it’s cheaper to find and fix vulnerabilities in development than later in the lifecycle. Developers need access to that data in their workflow. GitLab Ultimate/Gold offers comprehensive scanning, out of the box with no integration required: [dynamic](https://docs.gitlab.com/ee/user/application_security/dast/) and [static](https://docs.gitlab.com/ee/user/application_security/sast/) (now including mobile apps), [container scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/), [dependency scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), [API scanning](https://docs.gitlab.com/ee/user/application_security/dast/#api-scan), and [fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/), along with scanning for [secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/) and [license compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/). All of these scans are built into the workflow with results presented in the MR pipeline – meaning busy developers don’t have to go hunting for results. \n\nThe scans are also easy to apply for security pros. With one click, you can choose what to do via AutoDevOps, or add in third-party scanners via the `ci.yml`. Just start with a [CI job definition](https://docs.gitlab.com/ee/development/integrations/secure.html#job-definition). We’ve even added a handy UX so non-developers can modify the `ci.yml` without coding (add link). By using CI templates you can easily set and apply [security policies](https://docs.gitlab.com/ee/user/application_security/configuration/) for merge approvals and more. You can also [limit security scanning to running offline](https://docs.gitlab.com/ee/user/application_security/offline_deployments/) for highly sensitive environments. \n\n## Comprehensive dashboards\n\nWhile this developer-first perspective will reduce vulnerabilities, they can’t all be fixed on the spot. So our [security dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) capability (included with GitLab Ultimate/Gold) helps security pros manage remaining vulnerabilities. It provides a single source of truth, eliminating translation and friction between development and security, and makes it simple for anyone to see the status of remediation work, who changed what, where and when, and even who approved merge requests across the entire software development lifecycle.\n\nAnd because we know compliance also plays a key role in security, we have a dedicated [compliance dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html) that gathers key data to ensure quick and accurate reporting. \n\n## Container monitoring\n\nDevOps teams taking advantage of the modularity of containers also need a way to keep all the moving parts safe. Gitlab Ultimate offers [container threat monitoring](https://docs.gitlab.com/ee/user/application_security/) in addition to container scanning.\n\n## Integrated fuzz testing\n\nThanks to our acquisition of Peach and FuzzIt, GitLab Ultimate now offers integrated [coverage-guided fuzzing and continuous fuzzing](/topics/devsecops/what-is-fuzz-testing/), adding new types of testing previously unavailable.\n\nCover image by [Zhen Hu](https://unsplash.com/@zhenhu2424) on [Unsplash](https://unsplash.com)\n{: .note}\n",[704,851,9,230],{"slug":5491,"featured":6,"template":683},"security-features-in-ultimate","content:en-us:blog:security-features-in-ultimate.yml","Security Features In Ultimate","en-us/blog/security-features-in-ultimate.yml","en-us/blog/security-features-in-ultimate",{"_path":5497,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5498,"content":5503,"config":5509,"_id":5511,"_type":13,"title":5512,"_source":15,"_file":5513,"_stem":5514,"_extension":18},"/en-us/blog/self-managed-support-for-code-suggestions",{"title":5499,"description":5500,"ogTitle":5499,"ogDescription":5500,"noIndex":6,"ogImage":906,"ogUrl":5501,"ogSiteName":670,"ogType":671,"canonicalUrls":5501,"schema":5502},"Self-managed support for Code Suggestions (Beta)","Self-managed support for Code Suggestions (Beta) is coming in GitLab 16.1.","https://about.gitlab.com/blog/self-managed-support-for-code-suggestions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Self-managed support for Code Suggestions (Beta)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Roger Woo\"}],\n        \"datePublished\": \"2023-06-15\",\n      }",{"title":5499,"description":5500,"authors":5504,"heroImage":906,"date":5506,"body":5507,"category":806,"tags":5508},[5505],"Roger Woo","2023-06-15","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nGitLab [Code Suggestions (Beta)](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html) uses generative AI to suggest code while you’re developing. Since introduction in GitLab SaaS with 15.9, we've heard self-managed customers have wanted to use the feature. We're now bringing Code Suggestions to self-managed instances beginning with GitLab 16.1 (expected to be released June 22). Self-managed users working with VS Code or GitLab’s WebIDE can now receive code suggestions to help accelerate your development efforts while you type.\n\n## How does Code Suggestions work?\nA self-managed instance administrator must enable Code Suggestions on behalf of an organization's entire instance. Once enabled, users of that self-managed instance can authenticate their IDE to GitLab.com infrastructure using a secure handshake with the user's self-managed instance. As users type in their IDE, a context window containing relevant source code is securely transmitted to GitLab’s infrastructure, which will return an AI-generated code suggestion. GitLab does not have any visibility into a self-managed customer’s code other than what is sent to generate the Code Suggestion. GitLab does not persist any customer code sent in that context window nor train on customer data.\n\nIn this video, Senior Backend Engineer [Nikola Milojevic](https://gitlab.com/nmilojevic1) demonstrates how to set up and configure GitLab’s Code Suggestions for self-managed users on VS Code.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube-nocookie.com/embed/-A4amG3E49Y\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n## How Code Suggestions uses data\nGitLab is mindful of privacy when we design our AI-powered features. With Code Suggestions, we securely transmit the data needed to generate a code suggestion, and we process all personal data in accordance with our [privacy statement](https://about.gitlab.com/privacy/). Our VS Code Workflow extension will securely transmit a minimal amount of data required to generate a code suggestion. GitLab does not receive any information outside of an IDE’s context. Read more about [Code Suggestions data usage](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#data-privacy).\n\n## Try Code Suggestions\nWe will be provisioning access on a customer-by-customer basis for this initial iteration of GitLab Code Suggestions (Beta) on self-managed instances. Please leave a note in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/415393) tagging your Customer Success Manager for help with enabling Code Suggestions once your instance is ready.\n\nCode Suggestions for self-managed instances will require GitLab 16.1. Customers may try Code Suggestions either via GitLab’s WebIDE or VS Code’s GitLab Workflow Extension (version [3.67+](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow&ssr=false#version-history)).\n\n## Iterating on AI/ML features\nThis is just the start of the ways we're infusing GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](https://about.gitlab.com/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":5510,"featured":6,"template":683},"self-managed-support-for-code-suggestions","content:en-us:blog:self-managed-support-for-code-suggestions.yml","Self Managed Support For Code Suggestions","en-us/blog/self-managed-support-for-code-suggestions.yml","en-us/blog/self-managed-support-for-code-suggestions",{"_path":5516,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5517,"content":5523,"config":5529,"_id":5531,"_type":13,"title":5532,"_source":15,"_file":5533,"_stem":5534,"_extension":18},"/en-us/blog/self-managed-support-gitlab-for-jira-app",{"title":5518,"description":5519,"ogTitle":5518,"ogDescription":5519,"noIndex":6,"ogImage":5520,"ogUrl":5521,"ogSiteName":670,"ogType":671,"canonicalUrls":5521,"schema":5522},"Self-managed support extended to GitLab for Jira App","Connect GitLab with the Jira development panel to sync merge requests, commits, and transition Jira issue statuses from GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682573/Blog/Hero%20Images/jason-goodman-Oalh2MojUuk-unsplash.jpg","https://about.gitlab.com/blog/self-managed-support-gitlab-for-jira-app","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Self-managed support extended to GitLab for Jira App\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Grant Hickman\"}],\n        \"datePublished\": \"2023-01-12\",\n      }",{"title":5518,"description":5519,"authors":5524,"heroImage":5520,"date":5526,"body":5527,"category":678,"tags":5528},[5525],"Grant Hickman","2023-01-12","\n\nDeveloping fast feedback loops is a core tenet of DevOps and is critical to the communication required between planning functions and engineering teams. GitLab provides many integrated features for Agile Planning within the DevSecOps Platform, but we understand the importance of supporting tools used within the broader DevOps ecosystem. This is why we’ve partnered with Atlassian to provide additional (and more straightforward) support between GitLab and Atlassian Jira, via the GitLab for Jira app.\n\n## GitLab for Jira app: Proxy for Self-Managed GitLab\n\nFor Jira Cloud, the GitLab for Jira app now officially supports integration with both GitLab SaaS and GitLab Self-Managed, making it easier to identify the ideal integration based on the type of installation mix you may have.\n\nWith the GitLab for Jira app, you can: \n\n- Display merge requests, commits, pipelines, deployments, feature flags, and branches directly in the Jira Development Panel, creating a quick view into progress on feature development.\n- Link commits, commit messages, and issue comments by mentioning the Jira Issue ID.\n- Transition issues from a commit, saving developers time from context switching across tools.\n- Add time tracking or custom comments to an issue with Smart Commits.\n\n## Configuring the GitLab for Jira app with GitLab Self-Managed\n\nHere are the steps to take to configure the GitLab for Jira app with GitLab Self-Managed: \n\n1. Visit the GitLab for Jira App in the Atlassian Marketplace.\n1. Click “Get it now”.\n1. Choose “GitLab (self managed)” Note: this requires a GitLab Admin role.\n1. Configure your [Instance OAuth App in GitLab](https://docs.gitlab.com/ee/integration/jira/connect-app.html#connect-the-gitlabcom-for-jira-cloud-app-for-self-managed-instances).\n1. Provide your instance URL.\n1. Sign in to your GitLab instance.\n1. Link your namespace.\n\n## Limitations and considerations\n\n1. If you have implemented the GitLab for Jira app manually via App Manifest, proceed with caution. This is our first iteration and we’ll be improving the workflow to make it easier to migrate to the official GitLab for Jira app from the App Manifest approach.\n1. Traffic will be routed through GitLab.com for the GitLab for Jira app to configure the integration. \n1. To configure the integration, you will need to be an admin of the Jira project and the GitLab instance to enable the integration.\n\n## Deprecation and removal of Jira Cloud support for DVCS integration\n\nAs the GitLab for Jira app now supports GitLab Self-Managed, this is the recommended path for integration between Jira Cloud and GitLab (for GitLab.com and GitLab Self-Managed). The GitLab DVCS connector will only support Jira Server and Jira Data Center moving forward. Jira Cloud support within the DVCS integration is [deprecated and will be removed in %16.0](https://docs.gitlab.com/ee/update/deprecations.html#jira-github-enterprise-dvcs-integration).\n\nTo simplify how to choose which integrations are a fit for you, see below:\n\n1. Are you using Jira Cloud?\n    1. Use the [GitLab for Jira app](https://marketplace.atlassian.com/apps/1221011?tab=overview&hosting=cloud).\n    2. You can also use the [GitLab Jira Integration](https://docs.gitlab.com/ee/integration/jira/configure.html) with the GitLab for Jira app.\n\n2. Are you using Jira Server or Jira Data Center?\n    1. Use the [Jira DVCS Connector](https://docs.gitlab.com/ee/integration/jira/dvcs.html)\n    2. You can also use the [GitLab Jira Integration](https://docs.gitlab.com/ee/integration/jira/configure.html) with the Jira DVCS Connector.\n\n## Options for using the GitLab for Jira app with GitLab Self-Managed\n\nWith this release, you may now configure the [GitLab for Jira app directly from the Atlassian Marketplace](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?tab=overview&hosting=cloud). This gives you a guided workflow for enabling the app and leverages GitLab.com as a proxy for your self-managed instance, for purposes of enabling the integration.\n\nAlternatively, you may also install the GitLab for Jira app by fetching a manifest file or creating your own Marketplace listing. To explore these approaches, you can [visit our documentation](https://docs.gitlab.com/ee/integration/jira/connect-app.html#install-the-gitlabcom-for-jira-cloud-app-for-self-managed-instances).\n\n### Read more\n\n- [Epic](https://gitlab.com/groups/gitlab-org/-/epics/5650) about the extension of self-managed support to GitLab from Jira app\n- [How to integrate GitLab.com with Jira Cloud](/blog/integrating-gitlab-com-with-atlassian-jira-cloud/)\n- [Documentation](https://docs.gitlab.com/ee/integration/jira/connect-app.html) on GitLab.com for Jira Cloud app\n\n_Cover image by [Jason Goodman](https://unsplash.com/@jasongoodman_youxventures?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://www.unsplash.com)._\n",[9,230,281],{"slug":5530,"featured":6,"template":683},"self-managed-support-gitlab-for-jira-app","content:en-us:blog:self-managed-support-gitlab-for-jira-app.yml","Self Managed Support Gitlab For Jira App","en-us/blog/self-managed-support-gitlab-for-jira-app.yml","en-us/blog/self-managed-support-gitlab-for-jira-app",{"_path":5536,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5537,"content":5543,"config":5549,"_id":5551,"_type":13,"title":5552,"_source":15,"_file":5553,"_stem":5554,"_extension":18},"/en-us/blog/serverless-js-project-template",{"title":5538,"description":5539,"ogTitle":5538,"ogDescription":5539,"noIndex":6,"ogImage":5540,"ogUrl":5541,"ogSiteName":670,"ogType":671,"canonicalUrls":5541,"schema":5542},"Starting a serverless JS project with GitLab","Introduction to the new serverless JS project template at GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680997/Blog/Hero%20Images/clouds-cover.jpg","https://about.gitlab.com/blog/serverless-js-project-template","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Starting a serverless JS project with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Greiling\"}],\n        \"datePublished\": \"2020-01-14\",\n      }",{"title":5538,"description":5539,"authors":5544,"heroImage":5540,"date":5546,"body":5547,"category":1353,"tags":5548},[5545],"Mike Greiling","2020-01-14","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\u003C!-- Content start here -->\n\nIf you've been working in web development these past few years than you've no doubt heard about [serverless](/topics/serverless/) FaaS solutions like AWS Lambda or Knative. The idea boils down to writing code as a set of discrete functions that can be triggered by events. All worries about provisioning server nodes, scaling them, managing your back-end stack, and many other operational tasks are abstracted away. Moreover, it often results in massive cost savings as compute resources are provisioned on-demand. As this paradigm is growing in maturity and popularity, many tools have been created to make the process even easier and there has never been a better time to try it out for yourself.\n\nTo demonstrate how easy it is to get started with FaaS in GitLab, we've now added a project template to get you up and running even faster. If you're interested in wading into the serverless waters without running a single command in your terminal, follow along and try it yourself! All that is needed for this example is a free GitLab account and an AWS account.\n\n### 1. Creating a project\n\nTo start off, let's create a project with our new serverless template. Open up the [new project](https://gitlab.com/projects/new) page and select the \"Create from template\" tab. Then scroll down and select the \"Serverless Framework/JS\" template.\n\n![Step 1](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-1.1.jpg){: .shadow.medium.center}\n\nGive your project a name and select \"Create project\"\n\n### 2. Configuring your AWS credentials\n\nNow that we have our GitLab project complete with a boilerplate serverless application, it's time to give it access credentials to AWS so we can deploy it.\n\nOpen up the AWS console, sign in, and navigate to the [IAM section](https://console.aws.amazon.com/iam/home). Here you can select \"Users\" in the left-hand column, and create a new user using the \"Add user\" button at the top of the list.\n\n![Step 2-1](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-2.1.jpg){: .shadow.medium.center}\n\nGive your user a name like \"gitlab-serverless\" and make sure to select the \"Programatic access\" checkbox before clicking on \"Next\".\n\n![Step 2-2](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-2.2.jpg){: .shadow.medium.center}\n\nNow we need to give this user the appropriate permissions to deploy serverless functions. On the \"Permissions\" page select \"Attach existing policies directly\" and then click the \"Create policy\" button. This will open a new window.\n\n![Step 2-3](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-2.3.jpg){: .shadow.medium.center}\n\nHere you'll need to select the \"JSON\" tab and paste the following policy statement:\n\n```json\n{\n  \"Statement\": [\n    {\n      \"Action\": [\n        \"apigateway:*\",\n        \"cloudformation:CancelUpdateStack\",\n        \"cloudformation:ContinueUpdateRollback\",\n        \"cloudformation:CreateChangeSet\",\n        \"cloudformation:CreateStack\",\n        \"cloudformation:CreateUploadBucket\",\n        \"cloudformation:DeleteStack\",\n        \"cloudformation:Describe*\",\n        \"cloudformation:EstimateTemplateCost\",\n        \"cloudformation:ExecuteChangeSet\",\n        \"cloudformation:Get*\",\n        \"cloudformation:List*\",\n        \"cloudformation:PreviewStackUpdate\",\n        \"cloudformation:UpdateStack\",\n        \"cloudformation:UpdateTerminationProtection\",\n        \"cloudformation:ValidateTemplate\",\n        \"dynamodb:CreateTable\",\n        \"dynamodb:DeleteTable\",\n        \"dynamodb:DescribeTable\",\n        \"ec2:AttachInternetGateway\",\n        \"ec2:AuthorizeSecurityGroupIngress\",\n        \"ec2:CreateInternetGateway\",\n        \"ec2:CreateNetworkAcl\",\n        \"ec2:CreateNetworkAclEntry\",\n        \"ec2:CreateRouteTable\",\n        \"ec2:CreateSecurityGroup\",\n        \"ec2:CreateSubnet\",\n        \"ec2:CreateTags\",\n        \"ec2:CreateVpc\",\n        \"ec2:DeleteInternetGateway\",\n        \"ec2:DeleteNetworkAcl\",\n        \"ec2:DeleteNetworkAclEntry\",\n        \"ec2:DeleteRouteTable\",\n        \"ec2:DeleteSecurityGroup\",\n        \"ec2:DeleteSubnet\",\n        \"ec2:DeleteVpc\",\n        \"ec2:Describe*\",\n        \"ec2:DetachInternetGateway\",\n        \"ec2:ModifyVpcAttribute\",\n        \"events:DeleteRule\",\n        \"events:DescribeRule\",\n        \"events:ListRuleNamesByTarget\",\n        \"events:ListRules\",\n        \"events:ListTargetsByRule\",\n        \"events:PutRule\",\n        \"events:PutTargets\",\n        \"events:RemoveTargets\",\n        \"iam:CreateRole\",\n        \"iam:DeleteRole\",\n        \"iam:DeleteRolePolicy\",\n        \"iam:GetRole\",\n        \"iam:PassRole\",\n        \"iam:PutRolePolicy\",\n        \"iot:CreateTopicRule\",\n        \"iot:DeleteTopicRule\",\n        \"iot:DisableTopicRule\",\n        \"iot:EnableTopicRule\",\n        \"iot:ReplaceTopicRule\",\n        \"kinesis:CreateStream\",\n        \"kinesis:DeleteStream\",\n        \"kinesis:DescribeStream\",\n        \"lambda:*\",\n        \"logs:CreateLogGroup\",\n        \"logs:DeleteLogGroup\",\n        \"logs:DescribeLogGroups\",\n        \"logs:DescribeLogStreams\",\n        \"logs:FilterLogEvents\",\n        \"logs:GetLogEvents\",\n        \"s3:CreateBucket\",\n        \"s3:DeleteBucket\",\n        \"s3:DeleteBucketPolicy\",\n        \"s3:DeleteObject\",\n        \"s3:DeleteObjectVersion\",\n        \"s3:GetObject\",\n        \"s3:GetObjectVersion\",\n        \"s3:ListAllMyBuckets\",\n        \"s3:ListBucket\",\n        \"s3:PutBucketNotification\",\n        \"s3:PutBucketPolicy\",\n        \"s3:PutBucketTagging\",\n        \"s3:PutBucketWebsite\",\n        \"s3:PutEncryptionConfiguration\",\n        \"s3:PutObject\",\n        \"sns:CreateTopic\",\n        \"sns:DeleteTopic\",\n        \"sns:GetSubscriptionAttributes\",\n        \"sns:GetTopicAttributes\",\n        \"sns:ListSubscriptions\",\n        \"sns:ListSubscriptionsByTopic\",\n        \"sns:ListTopics\",\n        \"sns:SetSubscriptionAttributes\",\n        \"sns:SetTopicAttributes\",\n        \"sns:Subscribe\",\n        \"sns:Unsubscribe\",\n        \"states:CreateStateMachine\",\n        \"states:DeleteStateMachine\"\n      ],\n      \"Effect\": \"Allow\",\n      \"Resource\": \"*\"\n    }\n  ],\n  \"Version\": \"2012-10-17\"\n}\n```\n\n> Note: This policy is an example that encompasses pretty much everything the Serverless framework _might_ need on AWS, but much of it not likely to be used. You may wish to restrict this policy to fit your needs and security requirements. At minimum, the serverless credentials will need access to the `cloudformation`, `iam`, `lambda`, `logs`, and `s3` functions specified above.\n\n![Step 2-4](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-2.4.jpg){: .shadow.medium.center}\n\nClick \"Review Policy\" and you'll need to give this policy a name. I've used \"GitLabServerlessPolicy\". Then click \"Create policy\".\n\nAfter this is done, return to your \"Add user\" tab and search for the policy you just created (you may need to hit the \"refresh\" icon on the right). Check the box next to this policy and select the \"Next\" button.\n\n![Step 2-5](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-2.5.jpg){: .shadow.medium.center}\n\nProceed to add tags or skip straight to the review. The final page should resemble the following:\n\n![Step 2-6](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-2.6.jpg){: .shadow.medium.center}\n\nAfter clicking \"Create user\" you should finally be presented with a page that shows you your access credentials for this new AWS user account. Select \"show\" next to the \"secret access key\" and copy both this and the access key ID someplace for safe keeping.\n\n### 3. Entering your AWS credentials\n\nReturning back to GitLab, we'll need to enter these two credentials into our project's [CI/CD settings](/topics/ci-cd/). Select \"Settings -> CI/CD\" in the left-hand menu.\n\n![Step 3-1](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-3.1.jpg){: .shadow.small.center}\n\nOn this page, we need to expand the Variables section and enter our AWS credentials:\n\n![Step 3-2](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-3.2.jpg){: .shadow.medium.center}\n\nUse `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` as the keys for the two values you copied from AWS in the previous step. Don't forget to click \"Save variables\".\n\n### 4. Deploying your first AWS Lambda function.\n\nNow it's time to deploy your serverless project. If you're doing this on gitlab.com you've already got access to a GitLab runner with 2,000 free CI pipeline minutes, if not you'll need to [configure a runner yourself](https://docs.gitlab.com/runner/#install-gitlab-runner).\n\nGo to \"CI/CD -> Pipelines\" in the left-hand menu and click the \"Run Pipeline\" button. For fun, let's enter an environment variable with the key `A_VARIABLE` and give it whatever value you want. This will be usable by our deployed function.\n\n![Step 4-1](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-4.1.jpg){: .shadow.medium.center}\n\nSelect \"Run Pipeline\" and you should see your jobs start running. This project template has tests which will automatically run every time you run a pipeline. Once those are complete, the \"production\" job will deploy your code to AWS Lambda and finally it will produce a landing page on [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/). After just a few minutes this process should complete and you can visit \"Settings -> Pages\" to see a link to the URL where your GitLab project has been deployed. (It may take a few minutes before this URL is accessible the first time you make a deployment).\n\n![Step 4-2](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-4.2.jpg){: .shadow.medium.center}\n\nWhen you visit this page, here's what you'll see:\n\n![Step 4 Result](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-4.3.gif){: .shadow.medium.center}\n\nYou can enter an input value and click \"run function\". This input is sent to your serverless function which then responds and the response is printed under \"Function Output:\". Note that the environment value we provided using the `A_VARIABLE` key is present as well.\n\n### 5. Making Changes\n\nNow that we have a working AWS serverless project, let's try to make our own function. How about a simple calculator?\n\nOpen up the Web IDE and let's make the following changes:\n\nWithin `src/handler.js` add the following function:\n\n```javascript\nmodule.exports.add = async function(event) {\n  const A = Number(event.queryStringParameters.A);\n  const B = Number(event.queryStringParameters.B);\n  const result = A + B;\n\n  return {\n    statusCode: 200,\n    headers: {\n      \"Access-Control-Allow-Origin\": \"*\"\n    },\n    body: result\n  };\n};\n```\n\nThen open `public/index.html` and replace it with:\n\n```html\n\u003C!DOCTYPE html>\n\u003Chtml>\n  \u003Chead>\n    \u003Ctitle>GitLab Serverless Framework example\u003C/title>\n  \u003C/head>\n  \u003Cbody>\n    \u003Ch3>Add two values:\u003C/h3>\n    \u003Clabel>A: \u003Cinput type=\"text\" id=\"inputA\" placeholder=\"0\" name=\"A\"/>\u003C/label>\n    \u003Clabel>B: \u003Cinput type=\"text\" id=\"inputB\" placeholder=\"0\" name=\"B\"/>\u003C/label>\n    \u003Cstrong>=\u003C/strong>\n    \u003Cspan id=\"functionOutput\">?\u003C/span>\n    \u003Cbr />\n    \u003Cbutton>Calculate!\u003C/button>\n\n    \u003Cscript>\n      fetch(\"./stack.json\").then(response => {\n        response.json().then(myJson => {\n          const functionUrl = myJson.ServiceEndpoint + \"/add\";\n          const inputA = document.querySelector(\"#inputA\");\n          const inputB = document.querySelector(\"#inputB\");\n          const output = document.querySelector(\"#functionOutput\");\n\n          document.querySelector(\"button\").addEventListener(\"click\", () => {\n            const A = Number(inputA.value);\n            const B = Number(inputB.value);\n\n            fetch(functionUrl + \"?A=\" + A + \"&B=\" + B)\n              .then(response => response.text())\n              .then(result => (output.textContent = result));\n          });\n        });\n      });\n    \u003C/script>\n  \u003C/body>\n\u003C/html>\n```\n\nLastly, open `serverless.yml` and add an \"add\" function entry below our \"hello\" function like so:\n\n```yml\nfunctions:\n  hello:\n    handler: src/handler.hello\n    events:\n      - http:\n          path: hello\n          method: get\n          cors: true\n  add:\n    handler: src/handler.add\n    events:\n      - http:\n          path: add\n          method: get\n          cors: true\n```\n\nStage and commit these changes directly to the `master` branch. This will have triggered a new pipeline automatically. You can visit \"CI/CD -> Pipelines\" and watch it run.\n\nOnce the deployment is complete, our project page should look like this:\n\n![Step 5 Result](https://about.gitlab.com/images/blogimages/serverless-js-project-template/step-5.1.gif){: .shadow.medium.center}\n\nVoilà, we've just created our own serverless function and deployed it without a single terminal command. There's a lot more you can do from here, but this should be a good place to get started. Happy coding!\n\n\u003C!-- Content ends here -->\n\nCover image by [Kaushik Panchal](https://unsplash.com/@kaushikpanchal) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[230,9,4341],{"slug":5550,"featured":6,"template":683},"serverless-js-project-template","content:en-us:blog:serverless-js-project-template.yml","Serverless Js Project Template","en-us/blog/serverless-js-project-template.yml","en-us/blog/serverless-js-project-template",{"_path":5556,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5557,"content":5563,"config":5568,"_id":5570,"_type":13,"title":5571,"_source":15,"_file":5572,"_stem":5573,"_extension":18},"/en-us/blog/soc2-compliance",{"title":5558,"description":5559,"ogTitle":5558,"ogDescription":5559,"noIndex":6,"ogImage":5560,"ogUrl":5561,"ogSiteName":670,"ogType":671,"canonicalUrls":5561,"schema":5562},"How secure is GitLab?","Learn about GitLab's commitment to security and compliance, our security program maturity and accreditations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669646/Blog/Hero%20Images/blog-soc2-compliance.jpg","https://about.gitlab.com/blog/soc2-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How secure is GitLab?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Saumya Upadhyaya\"},{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-06-24\",\n      }",{"title":5558,"description":5559,"authors":5564,"heroImage":5560,"date":5565,"body":5566,"category":704,"tags":5567},[1570,1454],"2020-06-24","\n\nWhen trying out a new vendor, you want to ensure the company meets your organization’s security policies. Often, we receive questionnaires from our customers to validate our security posture and to understand the maturity of GitLab’s security program.\n\nAs a rapidly growing company, we are in a fortunate position to have a lot of new customers sign up for our solution. We want our customers to have confidence in our offering from a security perspective, and we want to be able to provide that assurance in the most transparent and accessible way possible.\n\nTo demonstrate our commitment to security and compliance and to provide customers with an insight into our security maturity, we have pursued (and continue to pursue) a number of programs and accreditations. We’re excited to share that information with you.\n\n## SOC 2 Report\n\n[SOC 2](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/serviceorganization-smanagement.html) is a security control report developed by the [American Institute of Certified Public Accountants](https://www.aicpa.org/) (AICPA) designed to give a holistic view of the design and effectiveness of a company's security program. A SOC 2 audit report provides an independent opinion about an organization's security and is becoming an industry standard for evaluating vendor security program maturity.\n\nThere are two types of SOC 2 reports:\n\n* **SOC 2 - Type 1** - which evaluates the design of controls\n* **SOC 2 - Type 2** - which evaluates the design and operating effectiveness of controls\n\n#### The SOC2 Report\n\nAs of 2021, GitLab has received a SOC 2 Type 2 attestation. Prior to receiving this attestation, we underwent a SOC 2 Type 1 audit in preparation for our Type 2. We detailed our experience undergoing the SOC 2 Type 1 audit, in this blog post, [The benefits of transparency in a compliance audit](/blog/benefits-of-transparency-in-compliance/).\n\n#### How can current (or prospective) customers get a copy of GitLab's most recent SOC 2 report?\n\nSince this report contains candid information about how our systems operate and proprietary audit specific information, we require certain confidentiality agreements be in place. This is built into our Terms of Service for current customers; for prospective customers we request you to complete an NDA with the help of your sales account leader.\n\nTo request the report and more details on our SOC 2 program please visit our [Security Certifications and Attestations handbook page](/handbook/security/security-assurance/security-compliance/certifications.html#requesting-a-copy-of-the-gitlab-soc2-type-2-report).\n\n## CSA Consensus Assessments Initiative Questionnaire (CAIQ)\n\nThe Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CAIQ) from [CSA STAR](https://cloudsecurityalliance.org/) offers an industry-accepted way to document security controls in SaaS services - thereby helping customers to gauge the security posture of cloud service providers. The CAIQ Questionnaire captures most of the frequently asked security questions such as:\n\n* Do you use industry standards (i.e. OWASP Software Assurance Maturity Model, ISO 27034) to build in security for your Systems/Software Development Lifecycle (SDLC)?\n* Do you verify that all of your software suppliers adhere to industry standards for SDLC security?\n* Do you enforce data access permissions based on the rules of Authentication, Authorization and Accountability (AAA)?\n\n### Where can you get the GitLab CAIQ?\n\nUnlike the SOC 2 Type 1 Report, this questionnaire does not require a non disclosure agreement and is available for download by all users at [GitLab’s CAIQ page at the CSA website](https://cloudsecurityalliance.org/star/registry/gitlab/).\n\n## GitLab Control Framework (GCF)\n\nThe [GitLab Control Framework](/handbook/security/security-assurance/security-compliance/sec-controls.html) is a set of controls that establish security requirements for the organization and GitLab's operating environment. These controls provide assurance to customers that GitLab has a robust security program and that their data within GitLab is appropriately protected.\n\nThe GitLab Control Framework has prioritized security controls needed for PCI, Sarbanes–Oxley (SOX), and SOC 2 Security Criteria spanning across the following topics:\n\n* Asset management\n* Backup management\n* Business continuity\n* Change management\n* Configuration management\n* Data management\n* Identity and access management\n* Incident response\n* Network operations\n* People resources\n* Risk management\n* Security governance\n* Service lifecycle\n* Systems design documentation\n* Systems monitoring\n* Third party management\n* Training and awareness\n* Vulnerability management\n\nYou can read on about how we [chose our framework](/blog/choosing-a-compliance-framework/) and [how we implemented and adapted the Adobe Compliance Framework](/blog/creating-the-gitlab-controls-framework/).\n\n## PCI Compliance\n\nPayment Card Industry's Data Security Standard (PCI-DSS), defined by the [PCI Security Standards Council](https://www.pcisecuritystandards.org/), identifies the requirements for vendors that accept or facilitate credit card payments. Based on the volume of transactions by the vendor, the vendor is classified under one of [four levels](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard#Compliance_levels).\n\nGitLab is currently a Level 4 merchant for PCI which requires us to:\n\n* Complete an annual self-attestation questionnaire (SAQ)\n* Perform a quarterly scan of our PCI systems by an approved scanning vendor. GitLab uses [Tenable.io](https://www.tenable.com/products/tenable-io)\n\nGitLab's Attestation of Compliance (AoC) is available on request, via security@gitlab.com. Learn more about [GitLab PCI compliance](/handbook/security/security-assurance/security-compliance/certifications.html#current).\n\n## What’s next?\n\nSecurity and compliance are ongoing processes and GitLab is committed to continual iteration, maturation, and improvement of our information security program.\n\nOur immediate priorities include:\n\n* Continuous iteration and improvement of our security controls with updated mappings between the GitLab Controls Framework and industry standards like SOC 2, ISO 27001, PCI, FedRAMP, and others\n* The **SOC 2 Type 2 report**, which evaluates operational efficiency in addition to design controls, will commence in 2021\n* The **Standardized Information Gathering (SIG) questionnaire**, a standardized 3rd party risk assessment tool, which along with our CAIQ will provide readily accessible background and transparency into our security program.\n\nHave a question about any of our existing or ongoing compliance efforts? Or maybe feedback about implementing compliance programs in an iterative, highly-transparent environment? We’d love to hear from you. Leave us a comment!\n\n*Read more about our security compliance:*\n\n[Transparency can actually help a security audit. Here's how](/blog/benefits-of-transparency-in-compliance/)\n\n[Can technology outpace security compliance?](/blog/when-technology-outpaces-security-compliance/)\n\n[Choosing between an independent or aggregate compliance framework](/blog/choosing-a-compliance-framework/)\n\nCover image by [Josh Calabrese](https://unsplash.com/photos/qmnpqDwla_E) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[851,9,704],{"slug":5569,"featured":6,"template":683},"soc2-compliance","content:en-us:blog:soc2-compliance.yml","Soc2 Compliance","en-us/blog/soc2-compliance.yml","en-us/blog/soc2-compliance",{"_path":5575,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5576,"content":5581,"config":5585,"_id":5587,"_type":13,"title":5588,"_source":15,"_file":5589,"_stem":5590,"_extension":18},"/en-us/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"title":5577,"description":5578,"ogTitle":5577,"ogDescription":5578,"noIndex":6,"ogImage":2874,"ogUrl":5579,"ogSiteName":670,"ogType":671,"canonicalUrls":5579,"schema":5580},"Speed up code reviews: Let AI handle the feedback implementation","Discover how GitLab Duo with Amazon Q automates the implementation of code review feedback through AI, transforming a time-consuming manual process into a streamlined workflow.","https://about.gitlab.com/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Speed up code reviews: Let AI handle the feedback implementation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-06-10\",\n      }",{"title":5577,"description":5578,"authors":5582,"heroImage":2874,"date":953,"body":5583,"category":806,"tags":5584},[803],"You know that feeling when you've just submitted a merge request and the code review comments start rolling in? One reviewer wants the labels updated, another asks for side-by-side layouts, someone else requests bold formatting, and don't forget about that button color change. Before you know it, you're spending hours implementing feedback that, while important, takes you away from building new features. It's a time-consuming process that every developer faces, yet it feels like there should be a better way.\n\nWhat if you could have an AI assistant that understands code review feedback and automatically implements the changes for you? That's exactly what [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) brings to your development workflow. This seamless integration combines GitLab's comprehensive DevSecOps platform with Amazon Q's advanced AI capabilities, creating an intelligent assistant that can read reviewer comments and converts them directly into code changes. Instead of manually addressing each piece of feedback, you can let AI handle the implementation while you focus on the bigger picture.\n\n## How GitLab Duo with Amazon Q works\n\nWhen you're viewing a merge request with reviewer comments, you'll see feedback scattered throughout your code. Let's take the examples from earlier in this article: maybe you've received a request to update a form label here, a suggestion to display fields side-by-side there, or a note about making certain text bold. Each comment represents a task that normally you'd need to handle manually.\n\n![feedback on an MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/1-show-comment.png)\n\nWith GitLab Duo with Amazon Q, you can simply enter the `/q dev` quick action in a comment. This prompts Amazon Q to analyze all the feedback and start modifying your code automatically. The AI agent understands the context of each comment and implements the requested changes directly in your codebase.\n\n![/q dev function prompting Amazon Q to analyze feedback](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/2-invoke-q-dev.png)\n\nOnce Amazon Q processes the feedback, you can view all the updates in the \"Changes\" tab of your merge request. Every modification is clearly visible, so you can verify that the AI agent correctly interpreted and implemented each piece of feedback. You can then run your updated application to confirm that all the changes work as expected — that form label is updated, the fields are displayed side-by-side, the text is bold, and yes, that button is now blue.\n\nWatch the code review feedback process in action:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/31E9X9BrK5s?si=ThFywR34V3Bfj1Z-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nProcessing code review feedback is a necessary but time-intensive part of software development.  GitLab Duo with Amazon Q evolves this manual process into an automated workflow, dramatically reducing the time between receiving feedback and implementing changes. By letting AI handle these routine modifications, you're free to focus on what really matters — building innovative features and solving complex problems.\n\nWith GitLab Duo with Amazon Q, you can:\n- Eliminate hours of manual feedback implementation\n- Accelerate your code review cycles\n- Maintain consistency in how feedback is addressed\n- Reduce context switching between reviewing comments and writing code\n- Ship features faster with streamlined deployment times\n\n> #### To learn more about GitLab Duo with Amazon Q visit us at an upcoming [AWS Summit in a city near you](https://about.gitlab.com/events/aws-summits/) or [reach out to your GitLab representative](https://about.gitlab.com/partners/technology-partners/aws/#form).\n\n## GitLab Duo with Amazon Q resources\n\n- [GitLab Duo with Amazon Q: Agentic AI optimized for AWS generally available](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n- [GitLab and AWS partner page](https://about.gitlab.com/partners/technology-partners/aws/)\n- [GitLab Duo with Amazon Q documentation](https://docs.gitlab.com/user/duo_amazon_q/)\n- [What is agentic AI?](https://about.gitlab.com/topics/agentic-ai/)\n- [Agentic AI guides and resources](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)",[701,9,478,872,871,746],{"slug":5586,"featured":90,"template":683},"speed-up-code-reviews-let-ai-handle-the-feedback-implementation","content:en-us:blog:speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","Speed Up Code Reviews Let Ai Handle The Feedback Implementation","en-us/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","en-us/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"_path":5592,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5593,"content":5598,"config":5603,"_id":5605,"_type":13,"title":5606,"_source":15,"_file":5607,"_stem":5608,"_extension":18},"/en-us/blog/splitting-database-into-main-and-ci",{"title":5594,"description":5595,"ogTitle":5594,"ogDescription":5595,"noIndex":6,"ogImage":3851,"ogUrl":5596,"ogSiteName":670,"ogType":671,"canonicalUrls":5596,"schema":5597},"We are splitting our database into Main and CI","We are splitting our database into Main and CI to improve the scalability and reliability of GitLab.com.","https://about.gitlab.com/blog/splitting-database-into-main-and-ci","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We are splitting our database into Main and CI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Douglas Alexandre\"}],\n        \"datePublished\": \"2022-06-02\",\n      }",{"title":5594,"description":5595,"authors":5599,"heroImage":3851,"date":5600,"body":5601,"category":298,"tags":5602},[2470,2471],"2022-06-02","\nImproving the performance and reliability of GitLab.com has always been a top priority for GitLab. While we continuously make iterative improvements to GitLab and our production architecture, we anticipate making a larger change to improve the scalability and reliability of GitLab.com: We are splitting our single PostgreSQL database into a `main` and a `ci` database.\n\nWe believe this process, also known as [functional decomposition](/company/team/structure/working-groups/database-scalability/#functional-decomposition-split), will increase GitLab's database capacity by roughly 2x and allows GitLab.com to continue to scale.\n\n## When will the split take place and what does this mean for users of GitLab.com?\n\nThis change is planned to take place between Saturday, 2022-07-02, 05:00am UTC and Saturday, 2022-07-02, 09:00am UTC. The implementation of this change is anticipated to include a **service downtime of up to 120 minutes** between Saturday, 2022-07-02, 06:00am to 08:00am UTC. During this time you will experience complete service disruption of GitLab.com.\n\nWe are taking downtime to ensure that the application works as expected following the split and to minimize the risk of any data integrity issues.\n\n## Background\n\nGitLab.com's [database architecture](/handbook/engineering/infrastructure/production/architecture/#database-architecture) uses a single PostgreSQL database cluster. This single cluster (let's call it `main`), consists of a single primary and multiple read-only replicas and stores the data generated by all GitLab features. Database reads can be scaled horizontally through read-only replicas, but writes cannot because PostgreSQL does not support active-active replication natively.\n\nA large portion of all writes are generated by features related to Continuous Integration (CI). So, to scale GitLab.com's database capacity, we are splitting the single PostgreSQL main cluster into two clusters:\n\n1. A Continuous Integration database cluster for all CI-related features (`ci`).\n1. A database cluster for all other features (`main`).\n\nAt a high level, GitLab.com's database architecture is changing like this:\n\n![Illustration of splitting into Main and CI](https://about.gitlab.com/images/blogimages/decomposition-illustration-blog.png){: .center}\n\nYou can learn more by visiting our public epic: [Decompose GitLab.com's database to improve scalability](https://gitlab.com/groups/gitlab-org/-/epics/6168).\n\n## Impact\n\nSplitting our database into `main` and `ci` initially will only impact GitLab.com. To ensure consistency, we plan to enable [decomposition for self-managed GitLab instances](https://gitlab.com/groups/gitlab-org/-/epics/7509) later. While this split is a significant architectural change that we believe will increase GitLab's database capacity by roughly 2x, there are other benefits as well.  \n\n### Increased performance\n\nBy running two separate database clusters, we believe we will increase the overall count of available database connections. This means we can serve more traffic. It also means that during peak hours there is more buffer, which reduces the likelihood of congestion that may cause performance and UX degradations.\n\nAnother significant advantage is that we anticipate we will be able to tune the `main` and `ci` databases independently, allowing us to optimize these different workloads.\n\n### Increased stability\n\nSplitting the database cluster into `main` and `ci` means that `ci` writes are shifting to the `ci` database cluster. We anticipate this will lead to reduced database saturation, which is a major cause of incidents. Consequently, we believe that the overall stability of GitLab.com may increase following the split.\n\nWe believe increased stability means that development teams can spend more time working on generating value through new features and other improvements and less time guarding against potential issues.\n\n### Shipping as fast as ever\n\nA primary objective of this project was to provide tooling to our development teams so that they can continue to develop features that use multiple databases. All of these tools, for example [loose foreign keys](https://docs.gitlab.com/ee/development/database/loose_foreign_keys.html) or new [data migrations for multiple databases](https://docs.gitlab.com/ee/development/database/migrations_for_multiple_databases.html), are available already and used in production.\n\nWith these tools in place, we expect that teams will be able to ship features as fast as before.\n\n### Tools and dashboards re-use\n\nThis change does introduce additional complexity. After all, we will run another database cluster. Given that the `ci` cluster is almost identical to the existing `main` cluster, our DBREs and SREs are able to re-use almost all tools (for example for backups) and dashboards. This reduces the overall risk introduced by this change.\n\n## How we are preparing for the split\n\nOver the last year, many teams at GitLab have worked to support running GitLab using multiple databases. In total, more than 600 merge requests made it into the product. Because we chose a [phased rollout approach](https://gitlab.com/groups/gitlab-org/-/epics/6160#roll-out-plan), almost all developed capabilities are already running on our production systems.\n\n- We've already provisioned a standby-cluster that [serves CI read-only data](https://gitlab.com/groups/gitlab-org/-/epics/6160#phase-3-serve-ci-reads-from-ci-standby-cluster) but, crucially, **not** writes on GitLab.com. This increases our confidence that this cluster is correctly provisioned and fully functional.\n- We've also split out all [CI write traffic into a separate connection](https://gitlab.com/groups/gitlab-org/-/epics/6160#phase-3-serve-ci-reads-from-ci-standby-cluster). From an application standpoint, it appears as if we are already using a `ci` and a `main` database. This gives us confidence that the application changes are working correctly.\n- Our CI pipelines also fully support running against multiple databases and all tests are passing.\n\nWhat is left is promoting the `ci` standby cluster so that all CI **reads and writes** are accepted on that cluster.\n\n## How we're working to ensure a smooth split\n\nThe [Pods group](/handbook/engineering/development/enablement/data_stores/pods/) is working closely with our SREs, DBREs and Quality to rehearse for the production change. These rehearsals include dry runs, executing the promotion of the `ci` database cluster, and testing our rollback strategies. All of these steps are tracked as part of a CI decomposition change template. This template is continuously improved to ensure that we capture all learnings from the rehearsals. The template is mirrored onto our Ops GitLab instance, which will remain available during the downtime window and forms the basis for executing the change.\n\nThe general process of the split can be described as follows:\n\n1. Running health checks\n1. Stopping all incoming traffic\n1. Promoting the CI database cluster to take reads and writes\n1. Running QA\n1. Allowing incoming traffic\n\nWe have developed and are extensively testing rollback plans.\n\nA [detailed timeline](https://gitlab.com/groups/gitlab-org/-/epics/7791#proposed-timeline) is available and we publish [daily asynchronous technical updates](https://gitlab.com/groups/gitlab-org/-/epics/7791#last-async-update) of our progress.\n",[9,9,893,266],{"slug":5604,"featured":6,"template":683},"splitting-database-into-main-and-ci","content:en-us:blog:splitting-database-into-main-and-ci.yml","Splitting Database Into Main And Ci","en-us/blog/splitting-database-into-main-and-ci.yml","en-us/blog/splitting-database-into-main-and-ci",{"_path":5610,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5611,"content":5617,"config":5622,"_id":5624,"_type":13,"title":5625,"_source":15,"_file":5626,"_stem":5627,"_extension":18},"/en-us/blog/start-using-pages-quickly",{"title":5612,"description":5613,"ogTitle":5612,"ogDescription":5613,"noIndex":6,"ogImage":5614,"ogUrl":5615,"ogSiteName":670,"ogType":671,"canonicalUrls":5615,"schema":5616},"New: How to get up and running quickly using GitLab Pages templates","We're introducing bundled GitLab Pages templates, so let's take a look at how easy it really is now to get up and running with a new site.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679908/Blog/Hero%20Images/pages-templates-cover-image.jpg","https://about.gitlab.com/blog/start-using-pages-quickly","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"New: How to get up and running quickly using GitLab Pages templates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2019-02-20\",\n      }",{"title":5612,"description":5613,"authors":5618,"heroImage":5614,"date":5619,"body":5620,"category":849,"tags":5621},[846],"2019-02-20","\n\nHello everyone, my name is Jason Yavorska and I'm the product manager for the [Release stage](/stages-devops-lifecycle/release/) here at GitLab, which includes GitLab Pages. In our [GitLab 11.8 release (March 2019) we're introducing](https://gitlab.com/gitlab-org/gitlab-ce/issues/47857) a quick way to select from our most popular [Pages templates](https://gitlab.com/pages?sort=stars_desc) directly from the new project setup screen. If you use GitLab.com, you can take advantage of this feature already! It looks a bit like this:\n\n![Pages Templates View](https://about.gitlab.com/images/blogimages/pages-templates-view.png){: .shadow.medium.center}\n\nNow, instead of having to fork an existing template, you can simply select one of the bundled ones and get going right away. If you're interested in one of the other templates, you can still create those in the old way – check out the [existing documentation on how to fork a template](https://docs.gitlab.com/ee/user/project/pages/index.html#fork-a-project-to-get-started-from).\n\nIn this article I'm going to show you just how effortless all of this can be. But first:\n\n## My experience contributing GitLab Pages templates\n\nFirst, though, I'd be remiss if I didn't mention that I contributed this change myself (with the help of a few key supporting players, of course.) Now, you may be wondering: I thought you were a product manager at GitLab? Not a developer? Well, that's absolutely true, but I am a hobbyist programmer on the side. I've contributed a small change here or there on my own time, but this was the largest, most complex thing that I've ever contributed myself.\n\nI always find in these situations that contributing is in some ways easier than you expect, and in some ways more challenging. Getting the code working was actually surprisingly straightforward: I was able to get our GDK ([GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/README.md)) up and running with minimal hassle, and then was able to iterate quickly until I found a working solution. Most of my challenges ended up being around getting the change through our review process and into the release. There's a lot you have to learn there, and I think it just takes some time and practice in order to have it all click. What was truly amazing, though, was all the friendly people who jumped in to help me along the way. I learned so much and am so proud of how everything came together in the end.\n\nIf you're considering making your first contribution, feel free to reach out to me on Twitter ([@j4yav](https://twitter.com/j4yav)) and I'll be happy to help guide you in the right direction. Contributing to open source is a great feeling, big or small, and if you haven't tried it before you should really give it a go.\n\n## Now let's set up a site!\n\nWith that out of the way, let's see this in action to appreciate just how painless it really is to set up a new site in GitLab pages now.\n\nThe video below walks through the steps, with full instructions underneath.\n\n Note that if you're using a private on-premise version of GitLab, be sure to check with your administrator to ensure that Pages is enabled. You may need to adjust some of the URLs in the setup below depending on your site configuration.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://youtube.com/embed/C2E1M-4Jvd0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 1. Create the new project\n\nFor this example, we'll use the [Hugo](https://gohugo.io/) template, our most popular one. Simply go to the GitLab home page, and select \"New Project\" from the top right. Click on \"Create from template,\" click on the Hugo template, and then click on \"Use template.\" Give it a name like `namespace.gitlab.io`, where `namespace` is your `username` or `groupname`.\n\n### 2. Run your first pipeline\n\nWe need to make one quick edit, which will naturally kick off a pipeline and deploy our site for the first time. What we need to do is edit our `config.toml` to have the same URL that we set up in the project name. To do this we will go to Repository → Files, click on the `config.toml` file, and then click on \"Edit\" in the toolbar. All we need to do is change the `baseurl = \"https://pages.gitlab.io/hugo/\"` line to `baseurl = \"https://namespace.gitlab.io/\"` (again, replacing `namespace` with your `username` or `groupname`).\n\nCommit your changes, then head over to CI/CD → Pipelines and look for the new pipeline that's running. You can click on the status to see the build log, or just wait for it to finish – you might be surprised at how fast this is! Once the pipeline passes, we're good to go. It may take a minute or two for everything to work through replication, but once it does, you can see your new site at `https://namespace.gitlab.io/`, beautiful template included, just waiting for you to customize further.\n\n### 3. Where to go next\n\nThere's a lot of basic configuration for your site in the `config.toml`, check that out and see what you might like to modify. The about page is in `/content/page/about.md`, and you can see example posts for your blog in `/content/post` – feel free to delete these when you're done with them. Since these are written in [markdown](https://docs.gitlab.com/ee/user/markdown.html) they are a piece of cake to edit or add new ones. Getting started with Hugo is a bit out of scope for this post, but I assure you it's quite straightforward. You can check out the [Hugo getting started pages](https://gohugo.io/getting-started/) for more ideas on what you can do. Be sure also to check out [Hugo themes](https://gohugo.io/themes/) if you're looking for inspiration.\n\nHopefully this was helpful in getting you started. Good luck with your new site!\n\nCover image by José Alejandro Cuffia(https://unsplash.com/@alecuffia) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[976,9,680,1187],{"slug":5623,"featured":6,"template":683},"start-using-pages-quickly","content:en-us:blog:start-using-pages-quickly.yml","Start Using Pages Quickly","en-us/blog/start-using-pages-quickly.yml","en-us/blog/start-using-pages-quickly",{"_path":5629,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5630,"content":5636,"config":5640,"_id":5642,"_type":13,"title":5643,"_source":15,"_file":5644,"_stem":5645,"_extension":18},"/en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping",{"title":5631,"description":5632,"ogTitle":5631,"ogDescription":5632,"noIndex":6,"ogImage":5633,"ogUrl":5634,"ogSiteName":670,"ogType":671,"canonicalUrls":5634,"schema":5635},"Streamline migrations with user contribution and membership mapping","New GitLab feature enhances project imports, allowing post-import user contribution mapping and greater flexibility and control.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663670/Blog/Hero%20Images/blog-image-template-1800x945__13_.png","https://about.gitlab.com/blog/streamline-migrations-with-user-contribution-and-membership-mapping","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Streamline migrations with user contribution and membership mapping\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n        \"datePublished\": \"2024-11-25\",\n      }",{"title":5631,"description":5632,"authors":5637,"heroImage":5633,"date":4283,"body":5638,"category":701,"tags":5639},[3330],"We are excited to announce a new feature that enhances the group and project import process: improved [user contribution and membership mapping](https://docs.gitlab.com/ee/user/project/import/#user-contribution-and-membership-mapping). This feature represents a significant improvement in the project import process, offering greater flexibility and control for both users managing the import process and users receiving contribution reassignments. The feature is available in [GitLab migration by direct transfer](https://docs.gitlab.com/ee/user/group/import/), [GitHub importer](https://docs.gitlab.com/ee/user/project/import/github.html), [Bitbucket Server importer](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html), and [Gitea importer](https://docs.gitlab.com/ee/user/project/import/gitea.html).\n\n## What's changing?\n\n1. Post-import mapping: Previously unavailable, this feature allows you to assign imported contributions and memberships to users on the destination instance after the import has been completed. Imported memberships and contributions are first mapped to placeholder users. Until they are reassigned, contributions display as associated with placeholders.  \n2. Email-independent mapping: The new process doesn't rely on email addresses, allowing you to map contributions for users who may have different email addresses on source and destination instances.  \n3. User control: Each user on the destination instance who is assigned a contribution mapping has to [accept the assignment](https://docs.gitlab.com/ee/user/project/import/#accept-contribution-reassignment) before any imported contributions are attributed to them. They can also [reject the assignment](https://docs.gitlab.com/ee/user/project/import/#reject-contribution-reassignment).\n\n## Key points for your migration\n\nAs you prepare to migrate your resources, here are some important aspects to familiarize yourself with:\n\n1. Placeholder users: Take some time to understand the concept of [placeholder users](https://docs.gitlab.com/ee/user/project/import/#placeholder-users) in GitLab. Consider how the [placeholder limits](https://docs.gitlab.com/ee/user/project/import/#placeholder-user-limits) apply to your specific use case.\n2. [Reassignment process](https://docs.gitlab.com/ee/user/project/import/#reassign-contributions-and-memberships): Explore the reassignment interface in the UI. It's designed with security in mind, so be sure to [review these security considerations](https://docs.gitlab.com/ee/user/project/import/#security-considerations).  \n3. User involvement: Inform your team about the migration process, particularly how they can [accept contribution reassignment](https://docs.gitlab.com/ee/user/project/import/#accept-contribution-reassignment). This helps provide for a smooth transition for everyone involved.\n\nBy understanding these aspects, you'll be well prepared for a successful migration.\n\n## What’s next\n\nWe are committed to enhancing this feature further. Key upcoming currently planned improvements include:\n\n1. CSV-based contribution reassignment:  \n   * Enable group owners to [reassign contributions via CSV file upload](https://gitlab.com/gitlab-org/gitlab/-/issues/455901)  \n   * Particularly beneficial for large-scale customers managing numerous users  \n2. Enhanced UI [visibility of the placeholder limits and counts](https://gitlab.com/gitlab-org/gitlab/-/issues/486691)\n\nFor a full list of further anticipated improvements, see the [User Contribution Mapping epic](https://gitlab.com/groups/gitlab-org/-/epics/14774).\n\n## Availability\n\n* This feature is available by default for direct transfer migrations on GitLab.com, GitLab Self-managed, and GitLab Dedicated instances from GitLab Version 17.7.\n* This feature is available by default in GitHub, Bitbucket Server, and Gitea importers on GitLab.com from GitLab 17.7 and on GitLab Self-Managed and GitLab Dedicated instances from GitLab Version 17.8.\n\n## Feedback and support\n\nWe value your feedback! If you encounter any issues or have suggestions regarding this change, please add a comment in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/502565).",[478,9,701],{"slug":5641,"featured":6,"template":683},"streamline-migrations-with-user-contribution-and-membership-mapping","content:en-us:blog:streamline-migrations-with-user-contribution-and-membership-mapping.yml","Streamline Migrations With User Contribution And Membership Mapping","en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping.yml","en-us/blog/streamline-migrations-with-user-contribution-and-membership-mapping",{"_path":5647,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5648,"content":5653,"config":5658,"_id":5660,"_type":13,"title":5661,"_source":15,"_file":5662,"_stem":5663,"_extension":18},"/en-us/blog/summarize-issues",{"title":5649,"description":5650,"ogTitle":5649,"ogDescription":5650,"noIndex":6,"ogImage":906,"ogUrl":5651,"ogSiteName":670,"ogType":671,"canonicalUrls":5651,"schema":5652},"ML experiment: Summarizing issue comments","Learn how GitLab is experimenting with ML-powered issue comment summarization in this fifth installment of our ongoing AI/ML in DevSecOps series.","https://about.gitlab.com/blog/summarize-issues","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Summarizing issue comments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Melissa Ushakov\"},{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2023-04-13\",\n      }",{"title":5649,"description":5650,"authors":5654,"heroImage":906,"date":5655,"body":5656,"category":806,"tags":5657},[2410,2333],"2023-04-13","\n\n\u003Ci>This blog post is part of an ongoing series about GitLab's journey to [build and integrate AI/ML into our DevSecOps platform](/blog/ai-ml-in-devsecops-series/). The series starts here: [What the ML is up with DevSecOps and AI?](/blog/what-the-ml-ai/). Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\n[GitLab issues](https://docs.gitlab.com/ee/user/project/issues/) are essential for team collaboration and serve as the source of truth for teams to align on the problem definition and scope of work for ongoing efforts. As teams collaborate on issues to refine them, the volume of comments grows. For issues with many comments, it can be challenging to understand the status of work at a glance. You may need to spend significant time reading comments to get an overview of the decisions made so far and to understand, for example, if there are any blockers. \n\nWith the recent advancements in AI and natural language processing, it's now possible for AI models to summarize text like that found in issue comments. We believe that this technology will help teams use their time more efficiently and help prevent losing track of important information within issue comments.\n\nLarge language models (LLMs) power generative AI solutions by using deep learning algorithms to analyze vast amounts of natural language data. These models are trained on massive datasets to develop an understanding of language patterns and context. Once trained, the models can generate new text that mimics human language.\n\nIn a rapid prototype, our own [Alexandru Croitor](https://gitlab.com/acroitor), Senior Backend Engineer, and [Nicolas Dunlar](https://gitlab.com/nicolasdular), Senior Frontend Engineer for our [Plan stage](/handbook/product/categories/#plan-stage), leverage generative AI LLMs to power comment summarization within [GitLab's issues](https://docs.gitlab.com/ee/user/project/issues/).\n\n![Prototype UX for comment summary](https://about.gitlab.com/images/blogimages/Issue_comment_summary_blog.gif){: .shadow}\n\nAbove, you can see an example of triggering the summarization of issue comments. Watch the full demo below. \n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/GMr3eHwbYAI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nOur experiment takes an individual's natural language comments, inferences them against a generative AI LLM, and through novel prompt engineering (the task of guiding LLM output through instructions), creates a summary of long comment threads. Part of our engineering exploration is examining how to chunk extremely long comment threads into parsable bits an LLM can succinctly and accurately summarize. \n\n## Iterating on AI/ML features\nWhile just an experiment today, we are iterating on how to effectively bring features like this to our customers. We're starting with summarization of issue comments, and are working to optimize prompts to provide more meaningful summaries. We are also investigating bringing this functionality to other objects like epics and merge requests.\n\nThis experiment is just the start of many ways we’re looking to infuse GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI Assisted features. We’ll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our ongoing series, \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\".\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[851,701,9,786],{"slug":5659,"featured":6,"template":683},"summarize-issues","content:en-us:blog:summarize-issues.yml","Summarize Issues","en-us/blog/summarize-issues.yml","en-us/blog/summarize-issues",{"_path":5665,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5666,"content":5671,"config":5676,"_id":5678,"_type":13,"title":5679,"_source":15,"_file":5680,"_stem":5681,"_extension":18},"/en-us/blog/summarize-my-merge-request-review",{"title":5667,"description":5668,"ogTitle":5667,"ogDescription":5668,"noIndex":6,"ogImage":906,"ogUrl":5669,"ogSiteName":670,"ogType":671,"canonicalUrls":5669,"schema":5670},"ML experiment: Summarize my merge request review","Learn how GitLab is experimenting with ML-powered merge request review summaries in this latest installment of our ongoing 'AI/ML in DevSecOps' series.","https://about.gitlab.com/blog/summarize-my-merge-request-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"ML experiment: Summarize my merge request review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kai Armstrong\"}],\n        \"datePublished\": \"2023-05-18\",\n      }",{"title":5667,"description":5668,"authors":5672,"heroImage":906,"date":5673,"body":5674,"category":806,"tags":5675},[2370],"2023-05-18","\n\n\u003Ci>This blog is the latest post in an ongoing series about GitLab’s journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we’ll feature blogs from our product, engineering, and UX teams to showcase how we’re infusing AI/ML into GitLab.\u003C/i>\n\nDuring the course of reviewing a merge request, you may sometimes leave many comments. Those comments may have specific information about things that need to be changed, or context for why you're leaving feedback on the proposed changes. If you've left a lot of comments, it might be hard to remember everything you've said and what the author should look at to resolve your feedback.\n\nIn a rapid prototype, [Stanislav Lashmanov](https://gitlab.com/slashmanov), Senior Frontend Engineeer for our [Code Review Group](/handbook/product/categories/#code-review-group), used AI/ML to summarize your merge request review when [submitting your review](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#submit-a-review). He developed a new AI action that provides a summary, and allows you to edit or revise prior to submitting the review:\n\n![Summarize my merge request review via AI](https://about.gitlab.com/images/blogimages/summarize-my-merge-request-review-ai.gif){: .shadow}\n\nProviding authors with these review summaries allows them to quickly understand the feedback and scope of revisions required without the need to process the entire review. This helps to speed up the cycle time for teams as they work through review rounds in merge requests.\n\n## Iterating on AI/ML features\n\nWhile just an experiment today, we are iterating on how to effectively bring features like this to our customers. We'll continue to refine the type of review feedback we provide, and then look at how we can better integrate these summaries in to the review cycle. You can see some of our [design efforts](https://gitlab.com/gitlab-org/gitlab/-/issues/408307) we've been exploring with the [summarizing merge request changes](/blog/merge-request-changes-summary-ai/) feature to get an idea of our possible direction.\n\nThis experiment is just the start of the ways we're infusing GitLab with AI/ML capabilities to help GitLab users become more efficient and effective at their jobs. We are [looking across the software development lifecycle](/blog/what-the-ml-ai/) for painful and time-consuming tasks that are ideal for AI-assisted features. We'll continue to share these demos throughout this blog series.\n\nInterested in using these AI-generated features? [Join our waitlist](https://forms.gle/9eeUkPJauKsbLaoz5) and share your ideas.\n\nContinue reading our \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[703,701,9,786],{"slug":5677,"featured":6,"template":683},"summarize-my-merge-request-review","content:en-us:blog:summarize-my-merge-request-review.yml","Summarize My Merge Request Review","en-us/blog/summarize-my-merge-request-review.yml","en-us/blog/summarize-my-merge-request-review",{"_path":5683,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5684,"content":5690,"config":5695,"_id":5697,"_type":13,"title":5698,"_source":15,"_file":5699,"_stem":5700,"_extension":18},"/en-us/blog/the-future-of-the-gitlab-web-ide",{"title":5685,"description":5686,"ogTitle":5685,"ogDescription":5686,"noIndex":6,"ogImage":5687,"ogUrl":5688,"ogSiteName":670,"ogType":671,"canonicalUrls":5688,"schema":5689},"The Future of the GitLab Web IDE","There are big changes in store for the Web IDE in the coming milestones.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679284/Blog/Hero%20Images/johannes-plenio-2TQwrtZnl08-unsplash.jpg","https://about.gitlab.com/blog/the-future-of-the-gitlab-web-ide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Future of the GitLab Web IDE\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Schurter\"}],\n        \"datePublished\": \"2022-05-23\",\n      }",{"title":5685,"description":5686,"authors":5691,"heroImage":5687,"date":5692,"body":5693,"category":678,"tags":5694},[2491],"2022-05-23","\nWay back in April 2018, [GitLab 10.7 introduced the Web IDE](/blog/introducing-gitlab-s-integrated-development-environment/) to the world and brought a delightful multi-file editor to the heart of the GitLab experience. Our goal was to make it easier for anyone and everyone to contribute, regardless of their development experience. Since its introduction, tens of millions of commits have been made from the Web IDE, and we've added features like [Live Preview](https://docs.gitlab.com/ee/user/project/web_ide/#live-preview) and [Interactive Web Terminals](https://docs.gitlab.com/ee/user/project/web_ide/index.html#interactive-web-terminals-for-the-web-ide) to enhance the experience. Now, we're excited to share some big changes we have in store for the Web IDE in coming milestones.\n\n## What makes an IDE?\n\nOver the years, we've learned a lot about how you all are using the Web IDE. We've [compared it to our Web Editor](https://about.gitlab.com/blog/a-tale-of-two-editors/) in the repository view. We've spoken to developers, designers, product managers, and technical writers alike. Almost universally, we hear that the Web IDE is great for small changes: a quick change to a config file, an update to a Markdown file, or a typo fix in a merge request. These lightweight changes make up the vast majority of the Web IDE usage. And for those use cases, it's super convenient and intuitive.\n\n![Editing a file in the current Web IDE](https://about.gitlab.com/images/blogimages/web-ide-diff-view.png)\n\nBut to grow, and to really earn the moniker “IDE,” what are we missing? What keeps developers from making more complex changes in the Web IDE? What can we do to elevate the experience? We hear about missing features and functionality like a [collapsible file panel](https://gitlab.com/groups/gitlab-org/-/epics/2585) that supports [contextual actions](https://gitlab.com/gitlab-org/gitlab/-/issues/197775) and drag and drop or [tighter integration with merge requests](https://gitlab.com/groups/gitlab-org/-/epics/2687). We've learned that there's no single feature that's a deal-breaker for most developers; it's the sum total of a lot of little user experience gaps.\n\nThe Web IDE is built on top of the fantastic open source project, [Monaco](https://microsoft.github.io/monaco-editor/). What made Monaco a great choice as the foundation of the Web IDE is also what makes it more difficult to address all these concerns holistically. Monaco is just that: a foundation. We have to implement all these workflows and features ourselves. Meanwhile, another open source project has been laser-focused on delivering a lovable IDE on top of Monaco.\n\n## Enter VS Code\n\nYou may have heard of [Visual Studio Code](https://code.visualstudio.com/), or VS Code. With its [dominant market share](https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-integrated-development-environment), chances are pretty good that you are even using it as your primary code editor. As it happens, [VS Code](https://github.com/microsoft/vscode) core is also open sourced under the MIT license. While the core project isn't a perfect drop-in replacement for the Web IDE, our Staff Frontend Engineer, [Paul Slaughter](/company/team/#pslaughter), wanted to see if we could run it inside GitLab.\n\nTurns out, we can:\n\u003Chttps://www.youtube.com/embed/_9G45TNR7VA>\n\nIn this video Paul Slaughter, Staff FE Engineer, walks Eric Schurter, Senior Product Manager, through the VS Code Web IDE proof of concept. See parts [two](https://www.youtube.com/watch?v=oyEFNOC1_Bo&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=9), [three](https://www.youtube.com/watch?v=1mTkNxrFXec&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=8), and [four](https://www.youtube.com/watch?v=qEiXtiInFIA&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=7) for closer looks at extensions, performance, and customization.\n\nAs you can see in the videos above, Paul was able to build a proof of concept that brings the VS Code editing experience into the GitLab UI, running entirely in the browser. No additional infrastructure needed.\n\nNext, we asked ourselves the question: Do we want to continue to invest in implementing custom features for the Web IDE that ultimately deliver the same value as those already available in VS Code? Or do we embrace VS Code inside GitLab, and invest in extending the experience to more tightly integrate with GitLab and the DevOps workflow?\n\n## Meet the new Web IDE\n\nAs you've probably already guessed, we've decided to [replace the current Web IDE with one built on top of VS Code](https://gitlab.com/groups/gitlab-org/-/epics/7683). In the coming milestones, we will build out custom support for the features not already available in the VS Code core, and validate that the workflows you already depend on in the Web IDE are handled in the new experience. We're working with the team that builds our amazing [GitLab Workflow extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for VS Code to make it available in the browser so we can bundle it in the Web IDE, and bring all those great features along for the ride. That includes [bringing merge request comments into the Web IDE](/blog/mr-reviews-with-vs-code/) for the first time ever!\n\n## Speaking of extensions\n\nYou read that right: extensions. One of the most compelling aspects of VS Code is the massive community and library of extensions available to customize your experience and integrate with other tools. A subset of [these extensions](https://open-vsx.org/) are already compatible with a web-based instance of VS Code, and our goal is to make them available in the Web IDE so you and your teams can work as efficiently and consistently as possible. Bringing extensions into the GitLab experience is not something we're taking lightly, so we'll be evaluating the best approach for ensuring the security and privacy of your data.\n\n## With great power comes great responsibility\n\nThis transition doesn't come without tradeoffs. We know that many of you appreciate the Web IDE for its simplicity, and it's safe to say that the increase in functionality VS Code brings to the table does come with an increase in complexity. The original Web IDE was introduced as a way to ensure that everyone can contribute. In keeping with that spirit, we will invest in improvements to our [core editing component](https://gitlab.com/groups/gitlab-org/-/epics/4861) that powers the [Web Editor](https://docs.gitlab.com/ee/user/project/repository/web_editor.html), Snippets, Pipeline Editor, and code editing elsewhere in GitLab. This core component will be extended to support multi-file editing. Our hope is that it actually serves those workflows that require simple edits even better than the Web IDE ever did.\n\n## I'm ready, when can I have it?\n\nWe're all excited to start using the new Web IDE as soon as possible. We're actively working on the integration and you can expect to see it sometime in the 15.x release cycle. If you would like to provide early feedback and help us fine tune the experience, please fill out this [short survey](https://forms.gle/S1vU5vkaEjE1NPMv9) to be considered for early access.\n\n## But wait, what about the runtime stuff?\n\nRemember at the beginning of this post when I asked what makes an IDE? The critical piece of the puzzle that VS Code is still missing is a runtime environment to compile your code. Without this environment, you can't generate real-time previews, run tests, or take advantage of code completion. We're looking to tackle this problem with the newly-formed [Remote Development category](/direction/create/ide/remote_development/), but that's a topic for a whole other blog post.\n\nUntil then, happy editing!\n\n_This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._\n\nCover image by [Johannes Plenio](https://unsplash.com/@jplenio?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[9,678,1672,680],{"slug":5696,"featured":6,"template":683},"the-future-of-the-gitlab-web-ide","content:en-us:blog:the-future-of-the-gitlab-web-ide.yml","The Future Of The Gitlab Web Ide","en-us/blog/the-future-of-the-gitlab-web-ide.yml","en-us/blog/the-future-of-the-gitlab-web-ide",{"_path":5702,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5703,"content":5708,"config":5714,"_id":5716,"_type":13,"title":5717,"_source":15,"_file":5718,"_stem":5719,"_extension":18},"/en-us/blog/the-gitlab-ai-security-framework-for-security-leaders",{"title":5704,"description":5705,"ogTitle":5704,"ogDescription":5705,"noIndex":6,"ogImage":716,"ogUrl":5706,"ogSiteName":670,"ogType":671,"canonicalUrls":5706,"schema":5707},"The GitLab AI Security Framework for security leaders","Discover how GitLab Duo's security controls, third-party integrations, and retention policies help teams safely implement AI into their development workflow.","https://about.gitlab.com/blog/the-gitlab-ai-security-framework-for-security-leaders","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The GitLab AI Security Framework for security leaders\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kyle Smith\"},{\"@type\":\"Person\",\"name\":\"Ayoub Fandi\"}],\n        \"datePublished\": \"2025-03-04\",\n      }",{"title":5704,"description":5705,"authors":5709,"heroImage":716,"date":4302,"body":5712,"category":806,"tags":5713},[5710,5711],"Kyle Smith","Ayoub Fandi","As companies rapidly adopt AI technologies, CISOs face a new frontier of security challenges. Many security leaders find themselves grappling with unfamiliar questions: How do we evaluate AI vendors differently from traditional software vendors? What security controls matter most? Where does vendor responsibility end and customer responsibility begin? How do we evaluate AI security risks within the context of the service provided? To help answer these questions, we’ve created the [GitLab AI Security Framework](https://trust.gitlab.com/?itemUid=ad3d92c1-889e-49fc-b19c-2434f70071ee&source=click) to show security leaders how GitLab and customers enable secure AI-powered development using GitLab Duo.\n\n## The genesis of AI security challenges\n\nFrom conversations with security leaders across industries a pattern has emerged: Organizations are rapidly embracing AI technologies to improve delivery while their security teams struggle to establish appropriate security controls. \n\nThis disconnect isn't just a matter of resources or expertise – it represents a fundamental shift in how organizations need to approach security in the AI era. Security leaders are witnessing quick and unprecedented adoption of AI across their organizations, from development teams using coding assistants to marketing departments leveraging generative AI. \n\nWhile organizations are integrating AI within their own software, many of their current vendor-provided SaaS applications have added AI capabilities as well. Although this adoption drives innovation and efficiency, it also creates a complex set of security considerations that traditional frameworks weren't designed to address. Below are some of the specific challenges we’ve identified.\n\n## Security challenges in the AI era\n\n**1. Responsibility and control uncertainty**\n\nThe rapid pace of AI adoption has left many organizations without a coherent security governance strategy. Security teams find themselves trying to retrofit existing security frameworks to address AI-specific concerns. Security leaders face challenges in understanding where their responsibilities begin and end when it comes to AI security. The traditional vendor-customer relationship becomes more complex with AI systems, as data flows, model training, and inference processes create new types of interactions and dependencies. \n\n**2. Risk assessment evolution**\n\nTraditional security risk models struggle to capture the unique characteristics of AI systems. Security leaders are finding that standard risk assessment frameworks don't adequately address AI-specific risks. AI security risks will differ based on AI implementation and the context in which it’s used. The challenge is compounded by the need to evaluate AI vendors without necessarily having deep technical AI expertise on the security team.\n\n**3. Data protection complexities**  \nAI systems present unique challenges for data protection. The way these systems process, learn from, and generate data creates new privacy and security considerations that organizations should carefully evaluate. CISOs must ensure their data governance frameworks evolve to address how AI systems use and protect sensitive information. AI implementations with inadequate safeguards might inadvertently reveal protected information via AI generated outputs.\n\n**4. Compliance and standards navigation**  \nThe regulatory landscape for AI security is rapidly evolving, with new standards like ISO 42001 and others emerging alongside existing frameworks. Security leaders must navigate this complex environment while ensuring their AI implementations remain compliant with both current and anticipated regulations. This requires a delicate balance between enabling AI adoption and maintaining robust security controls that satisfy regulatory requirements.\n\n## Addressing these challenges  \nWith the release of [GitLab Duo](https://about.gitlab.com/gitlab-duo/), we recognized these executive-level concerns and developed a comprehensive framework to help organizations navigate AI security in the context of our AI-powered DevSecOps platform. Our AI Security Framework provides details on our privacy-first implementation of AI to enable GitLab Duo, and how we validate the security of our AI vendors. A responsibility matrix is included to help security leaders manage their AI security responsibilities while enabling their organizations to innovate safely. We also compiled a selection of AI-specific security risks to keep in mind and highlighted how GitLab capabilities like [prompt guardrails](https://about.gitlab.com/blog/how-gitlab-uses-prompt-guardrails-to-help-protect-customers/) can help in mitigating them. \n\n> Want a deeper look at our security controls? Check out our [AI Security Framework](https://trust.gitlab.com/?itemUid=ad3d92c1-889e-49fc-b19c-2434f70071ee&source=click).\n\n## Learn more\n- [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)\n- [How GitLab uses prompt guardrails to help protect customers](https://about.gitlab.com/blog/how-gitlab-uses-prompt-guardrails-to-help-protect-customers/)\n- [Improve AI security in GitLab with composite identities](https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/)\n- [Secure, compliant, and AI-powered: Get to know 3 new GitLab features](https://about.gitlab.com/blog/secure-compliant-and-ai-powered-get-to-know-3-new-gitlab-features/)\n- [ICYMI: Key AI and security insights from our developer community](https://about.gitlab.com/blog/icymi-key-ai-and-security-insights-from-our-developer-community/)",[786,9,478,704],{"slug":5715,"featured":90,"template":683},"the-gitlab-ai-security-framework-for-security-leaders","content:en-us:blog:the-gitlab-ai-security-framework-for-security-leaders.yml","The Gitlab Ai Security Framework For Security Leaders","en-us/blog/the-gitlab-ai-security-framework-for-security-leaders.yml","en-us/blog/the-gitlab-ai-security-framework-for-security-leaders",{"_path":5721,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5722,"content":5728,"config":5735,"_id":5737,"_type":13,"title":5738,"_source":15,"_file":5739,"_stem":5740,"_extension":18},"/en-us/blog/the-gitlab-handbook-by-numbers",{"title":5723,"description":5724,"ogTitle":5723,"ogDescription":5724,"noIndex":6,"ogImage":5725,"ogUrl":5726,"ogSiteName":670,"ogType":671,"canonicalUrls":5726,"schema":5727},"The GitLab handbook by numbers","Two GitLab team-members take a fresh look at GitLab's open source team handbook, charting its evolution over the years to the weighty tome it is today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670434/Blog/Hero%20Images/handbook-cover.jpg","https://about.gitlab.com/blog/the-gitlab-handbook-by-numbers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The GitLab handbook by numbers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lukas Eipert\"},{\"@type\":\"Person\",\"name\":\"Lee Matos\"}],\n        \"datePublished\": \"2019-04-24\",\n      }",{"title":5723,"description":5724,"authors":5729,"heroImage":5725,"date":5732,"body":5733,"category":298,"tags":5734},[5730,5731],"Lukas Eipert","Lee Matos","2019-04-24","\nSharing and retrieving information is a crucial part of everyday work life.\nWhere do you get information from, be it about hiring processes, social media guidelines, or reporting expenses?\nAt GitLab, all of that can be found in [the handbook](https://handbook.gitlab.com/) – have a look, it's public!\n[Sid](/company/team/#sytses), our CEO, [wrote about the importance and the open sourcing of our handbook][sid-blog-post] about two and a half years ago.\nBack then we were just shy of 100 employees.\nIn this post we will look at how the handbook has developed over time, how we interact with it,\nand how it still works for over 550 employees.\n\n[sid-blog-post]: /blog/our-handbook-is-open-source-heres-why/\n\n## One book to guide them all\n\nAt the time of writing, the handbook contains about 605,000 words.\nWhile probably a bit less captivating than the tales of Frodo and Middle Earth,\nwe have composed more pages than \"The Lord of the Rings\" and \"The Hobbit\" combined, since the [first commit][first-commit] in 2015.\nIt would take around 50 hours of continuous reading to cover the whole handbook, front to back.\n\n### Is it overwhelming to read through it all?\n\nIt would be, but as the handbook covers a wide range of topics, you probably don't need to read every single word.\nAs the handbook changes over time it is not necessary to memorize it all, but it is more important to remember how to retrieve information.\nSo as long as you know where to find something, you are on the safe side.\n\n> It would take around 50 hours of continuous reading to cover the whole handbook, front to back\n\n[first-commit]: https://gitlab.com/gitlab-com/www-gitlab-com/blob/2d2ced8f79da96fe981a3a6f6cf5918fa2dd992a/source/team-handbook/index.html\n\n## One book to be written by them all\n\n![Graph showing the growth of the handbook over time (May 2015 - April 2019)](https://about.gitlab.com/images/blogimages/evolution_handbook/handbook-history.png){: .shadow.center}\n*\u003Csmall>Graph showing the growth of the handbook, broken down by subcategory, over time (May 2015 – April 2019)\u003C/small>*\n\nCurrently all knowledge in the handbook is spread across 550 unique web pages, with the average page containing around 1,100 words.\nThe most words have been written in the subcategory engineering (138,000 words), with marketing a close second (115,000 words).\nTypically, as teams grow, more of their processes get documented in the handbook, which leads to a natural growth of the respective category.\n\n> The most words have been written in the subcategory engineering (138,000 words)\n\n### Who contributes to the handbook?\n\nYou might think that there is someone special who writes all those pages, but it's important\nto remember that [everyone can contribute](https://handbook.gitlab.com/handbook/company/mission/) to the handbook. It is actually part of our [onboarding process]\nto improve something about the handbook – whether that's clarifying wording or making it easier to find something.\nNothing is exempt from change; even [our core values are adjusted over the course of time][values-history].\n\n### How do you make changes to the handbook?\n\nIf someone at GitLab or from the wider community wants to change something, they follow a simple workflow that is familiar to every GitLab user:\n\n1. Create a merge request which introduces the change.\n2. Discuss the merge request with the stakeholders.\n3. Iterate on the change and come to an agreement.\n4. Let the merge request be merged.\n\nMore important changes (not every typo of course!) are then announced via Slack or our [company call].\nThe handbook also has its own [changelog] which you can check regularly to see what has been changed over time.\n\n[onboarding process]: https://handbook.gitlab.com/handbook/people-group/general-onboarding/\n[values-history]: https://gitlab.com/gitlab-com/www-gitlab-com/commits/master/source/handbook/values/index.html.md\n[company call]: https://handbook.gitlab.com/handbook/communication/\n[changelog]: https://handbook.gitlab.com/handbook/about/changelog/\n\n## One book to be read by them all\n\nIn 2018 we had several hundred thousand page views on pages in the handbook. It is hard to tell which views come from GitLab team-members and which from the wider community.\nAmong the most-read pages are our [Markdown Guide], the pages about [global compensation], our [values], the [hiring process], our [product], [benefits], and how to [communicate].\nThese pages are topics of general interest to people within and outside the company.\nWhat could be a better resource to potential candidates than those pages that show the inner workings of GitLab?\n\n### How do you find anything in the handbook?\n\nThe handbook has a search function; you can use the [index page](https://handbook.gitlab.com/) as an entry point, or just use your favorite search engine to find information.\nWhenever someone asks a question in our Slack, there is a high probability that someone will answer with a link to the handbook.\nIf someone asks a question that has no answer in the handbook, we highly encourage people to add that information to document it and make it easier for future GitLab team-members to find answers.\n\n> Whenever someone asks a question in our Slack, there is a high probability that someone will answer with a link to the handbook\n\n[Markdown Guide]: https://handbook.gitlab.com/handbook/markdown-guide/\n[global compensation]: https://handbook.gitlab.com/handbook/total-rewards/compensation/\n[product]: https://handbook.gitlab.com/handbook/product/\n[communicate]: https://handbook.gitlab.com/handbook/communication/\n[values]: https://handbook.gitlab.com/handbook/values/\n[benefits]: https://handbook.gitlab.com/handbook/total-rewards/benefits/\n[hiring process]: https://handbook.gitlab.com/handbook/hiring/\n\n## One book to be the future\n\nWe hope that this glimpse into the handbook is as interesting for you as it was for us.\nIn an all-remote company it is especially important to write everything down, so that no matter\nwhere you are in the world or what time zone you choose to work in, the information you need is accessible.\nAt the moment we are happy to say that we think that the handbook works as well for us now as it did with 100 employees.\nIt aligns with our [values] more than ever.\n\nFor us it is the most transparent way to collaborate on documentation of company internals.\nWe are able to efficiently iterate on topics, resulting in more in-depth coverage over time.\nPersonally the authors cannot see many reasons why the handbook should not be able to scale even further.\nEventually it will evolve further, from the three tomes we have today, to a digital encyclopedia.\nWe are definitely excited to see what the future holds!\n\nHave you taken inspiration from our handbook? Let us know by tweeting [@gitlab](https://twitter.com/gitlab).\n\nPhoto by [Beatriz Pérez Moya](https://unsplash.com/photos/XN4T2PVUUgk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/books?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[829,9,680,1187],{"slug":5736,"featured":6,"template":683},"the-gitlab-handbook-by-numbers","content:en-us:blog:the-gitlab-handbook-by-numbers.yml","The Gitlab Handbook By Numbers","en-us/blog/the-gitlab-handbook-by-numbers.yml","en-us/blog/the-gitlab-handbook-by-numbers",{"_path":5742,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5743,"content":5749,"config":5755,"_id":5757,"_type":13,"title":5758,"_source":15,"_file":5759,"_stem":5760,"_extension":18},"/en-us/blog/the-gitlab-quarterly-how-our-latest-beta-releases-support-developers",{"title":5744,"description":5745,"ogTitle":5744,"ogDescription":5745,"noIndex":6,"ogImage":5746,"ogUrl":5747,"ogSiteName":670,"ogType":671,"canonicalUrls":5747,"schema":5748},"The GitLab Quarterly: How our latest beta releases support developers","The Value Streams Dashboard and Remote Development provide the capabilities needed to support DevSecOps teams and stay competitive.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668367/Blog/Hero%20Images/innovation-unsplash.jpg","https://about.gitlab.com/blog/the-gitlab-quarterly-how-our-latest-beta-releases-support-developers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The GitLab Quarterly: How our latest beta releases support developers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2023-01-24\",\n      }",{"title":5744,"description":5745,"authors":5750,"heroImage":5746,"date":5752,"body":5753,"category":1513,"tags":5754},[5751],"Dave Steer","2023-01-24","\nIt’s easy to say that 2023 will be the year of innovation, but with the macroeconomic environment requiring an obsessive eye on cost efficiencies, and in some cases, cost-cutting, exactly how are organizations supposed to stay competitive when it comes to software development and delivery? The answer is clear: Stay focused on supporting your developers. Our two new beta releases help you do just that.\n\nThe GitLab Value Streams Dashboard, now available in private beta, ensures that all stakeholders have visibility, early and in real time, into the progress and value delivery metrics associated with software development and delivery. With everyone on the same page, discussions can be had and adjustments made before developers face obstacles or stall out waiting for decision-makers to get up to speed. Developers can also see, at-a-glance, their impact on the idea-to-customer value chain. The goal: Reduce idle time so that developers can spend more time developing and IT leaders can better unlock their transformation results. Keeping the creativity flowing can boost developer happiness and help provide a glide path for software to make its way into the market and add value. \n\nOur other beta release, GitLab Remote Development, can enable organizations to directly support developers by letting them establish an environment that best suits their needs, including where, when, and how they prefer to work. GitLab Remote Development doesn’t require developers to set up and manage local development environments, which keeps workflow distractions to a minimum. Stripping away location, device, and complex toolchain barriers can maximize developer satisfaction, which can lead to increased ingenuity and productivity.\n\nAn overarching aspect of this developer support is that it is available on a single DevSecOps platform so you don’t have to tack on something special to achieve these goals — the tools are all there and ready to be used to create better software faster.\n\nNow, let’s dig deeper into these capabilities and how they will help you support your developers and deliver value to your customers.\n\n## GitLab Value Streams Dashboard\n\nIn many conversations we have with customers, lack of visibility into metrics for software development value streams comes up as a pain point. Value streams – the process from idea to delivering customer value – should be the epicenter for understanding the progress, blockers, timelines, and costs associated with your development projects. Without this insight, innovation with an eye to cost efficiencies is virtually impossible. It is also difficult to properly support developers through fast, informed decision-making if everyone doesn’t have access to the same real-time data. \n\nThe GitLab Value Streams Dashboard gives stakeholders a bird's-eye view of their teams’ software delivery metrics (such as [DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html) and [flow metrics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html)) for continuous improvement. DevSecOps teams can identify and fix inefficiencies and bottlenecks in their software delivery workflows, which can improve the overall productivity and stability of their development environment. \n\n> \"Our team is excited to try out the DORA metrics capabilities available in the private beta for the new Value Streams Dashboard. We look forward to using other widgets as the Value Streams Dashboard matures, which we hope will greatly improve our productivity and efficiency.\"  \n> _**Rob Fulwell, Staff Engineer, Conversica**_\n\nThe first iteration of the GitLab Value Streams Dashboard enables teams to continuously improve software delivery workflows by benchmarking key DevOps metrics to help improve productivity, efficiency, scalability, and performance. Tracking and comparing these metrics over a period of time helps teams catch downward trends early, drill down into individual projects/metrics, take remedial actions to maintain their software delivery performance, and track progress of their innovation investments.\n\nLeadership can support developers by using information from the dashboard to cross-pollinate and promote best practices, add resources to projects based on metrics, and eliminate common bottlenecks across projects. \n\n\n\n### Roadmap for Value Streams Dashboard\n\nWe are just getting started with delivering capabilities in our Value Streams Dashboard. The roadmap includes planned features and functionality that will continue to improve decision-making and operational efficiencies.\n\nHere are some of the capabilities we plan to focus on next:\n\n1. New visualizations such as overview widgets, [top view treemap](https://gitlab.com/gitlab-org/gitlab/-/issues/381306), and [DORA performance score chart](https://gitlab.com/gitlab-org/gitlab/-/issues/386843)\n2. Security and vulnerability benchmarking  to enable executives to better understand an organization’s security exposure \n3. A new [data warehouse](https://gitlab.com/groups/gitlab-org/-/epics/9318?_gl=1*1orel9k*_ga*ODExMTUxMDcwLjE2Njk3MDM3Njk.*_ga_ENFH3X7M5Y*MTY3MjkxMTgxMC43Ny4xLjE2NzI5MTI0MTIuMC4wLjA.) that supports fast analytical queries and deep data analysis\n4. Additional business value metrics such as adoption, OKRs, revenue, costs, CSAT that align technical and business goals\n\n[Learn more on our direction page](/direction/plan/value_stream_management/).\n\n### Join the beta: We welcome your contributions\n\nAs we iterate on this new offering, GitLab Premium and Ultimate customers are invited to [join our private beta](https://about.gitlab.com/value-streams-dashboard).\n\nWe also invite you to learn more about [Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html) and [follow along](https://gitlab.com/groups/gitlab-org/-/epics/9317) on the timeline to General Availability.\n\n## GitLab Remote Development\n\nThe increasing adoption of reproducible, ephemeral, cloud-based development environments has accelerated software development. But for developers, frequent context-switching between different environments, navigating complex and extensive toolchains, and managing a local development environment can create friction. GitLab Remote Development helps organizations better support developers by enabling them to spend less time managing their development environment and more time contributing high-quality code.\n\n> \"While a number of stakeholders are critical to successful DevOps, software developers are key for a successful DevOps implementation. Thus, organizations must adequately support developers. This means providing good developer experiences that are not disruptive or intrusive, but that are nonetheless sanctioned by the company, and that remain secure and compliant through automation and abstraction.\"  \n> _**Jay Lyman, 451 Research, a part of S&P Global Market Intelligence, \"Traditional IT teams, leadership stand out as additional DevOps stakeholders – Highlights from VotE: DevOps,\" January 4, 2023**_ \n\nThe centerpiece of GitLab Remote Development is our newly released Web IDE Beta, now the default web IDE experience on GitLab. The Web IDE makes it possible to securely connect to a remote development environment, run commands in an interactive terminal panel, and get real-time feedback from right inside the Web IDE. Understanding that developer familiarity is important, the Web IDE Beta uses a more powerful VS code interface and is able to handle many of the most frequently performed tasks on the existing Web IDE, including committing changes to multiple files and reviewing merge request diffs.\n\nGitLab Remote Development also creates a more secure development experience by enabling organizations to implement a [zero-trust policy](/blog/why-devops-and-zero-trust-go-together/) that prevents source code and sensitive data from being stored locally across numerous developer devices. In addition, organizations can adhere to compliance requirements by ensuring developers are working with approved environments, libraries, and dependencies. \n\nIt’s interesting to note that we deployed the Web IDE beta turned on as default and currently 99.9% of users have kept it toggled on. I encourage you to learn more about the [new Web IDE functionality](/blog/get-ready-for-new-gitlab-web-ide/) in our recent blog post. \n\n### Roadmap for Remote Development\n\nAs iteration continues on the GitLab remote development experience, the roadmap currently focuses on the following functionality next: \n\n1. Provision instances of remote development environments on demand in the customer’s choice of cloud provider.\n2. Allow teams to share complex, multi-repo environments.\n3. Connect from a variety of IDEs, including VS Code, JetBrains, Vim, or the Web IDE.\n4. Ensure an organization’s remote environments conform to its software supply chain security requirements with advanced security tools, authorization, reports, and audit logs.\n\n[Learn more on our direction page](/direction/create/ide/remote_development/).\n\n## Engage with DevSecOps experts\n\nWant to dig deeper into how to innovate while still keeping an eye on cost efficiencies? Join me for our webcast “[GitLab’s DevSecOps Innovations and Predictions for 2023](https://page.gitlab.com/webcast-gitlab-devsecops-innovations-predictions-2023.html?utm_medium=blog&utm_source=gitlab&utm_campaign=devopsgtm&utm_content=fy23q4release)” on Jan. 31 to get expert advice and insights about this era of DevSecOps transformation and the tools and strategies you’ll need to meet this challenge. \n\n[Register today](https://page.gitlab.com/webcast-gitlab-devsecops-innovations-predictions-2023.html?utm_medium=blog&utm_source=gitlab&utm_campaign=devopsgtm&utm_content=fy23q4release)!\n\n**Disclaimer**: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\n\n\n_Cover image by [Skye Studios](https://unsplash.com/@skyestudios?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)_\n  \n",[851,703,2018,9],{"slug":5756,"featured":6,"template":683},"the-gitlab-quarterly-how-our-latest-beta-releases-support-developers","content:en-us:blog:the-gitlab-quarterly-how-our-latest-beta-releases-support-developers.yml","The Gitlab Quarterly How Our Latest Beta Releases Support Developers","en-us/blog/the-gitlab-quarterly-how-our-latest-beta-releases-support-developers.yml","en-us/blog/the-gitlab-quarterly-how-our-latest-beta-releases-support-developers",{"_path":5762,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5763,"content":5769,"config":5775,"_id":5777,"_type":13,"title":5778,"_source":15,"_file":5779,"_stem":5780,"_extension":18},"/en-us/blog/the-journey-to-a-devops-platform",{"title":5764,"description":5765,"ogTitle":5764,"ogDescription":5765,"noIndex":6,"ogImage":5766,"ogUrl":5767,"ogSiteName":670,"ogType":671,"canonicalUrls":5767,"schema":5768},"The journey to a DevOps Platform","Understand the history of DevOps or be doomed to repeat it. Here's why the journey has been so painful and how a DevOps Platform will help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668107/Blog/Hero%20Images/global-developer-survey.png","https://about.gitlab.com/blog/the-journey-to-a-devops-platform","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The journey to a DevOps Platform\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cormac Foster\"}],\n        \"datePublished\": \"2021-09-02\",\n      }",{"title":5764,"description":5765,"authors":5770,"heroImage":5766,"date":5772,"body":5773,"category":1513,"tags":5774},[5771],"Cormac Foster","2021-09-02","\n\nIn a recent blog post [about the importance of a DevOps Platform](/blog/welcome-to-the-devops-platform-era/), GitLab CEO Sid Sijbrandij outlined four phases through which organizations frequently travel as their practice matures. It’s a painful journey we see again and again when we meet new customers. It spans every industry and every company size, and it’s the most mature DevOps teams with the most at stake who’ve felt the most pain. \n\nHistorically, if you wanted DevOps to work, you had to be prepared to pay for it. Just managing the backbone of DevOps – the toolchain -– has been a grind. Your “Jenkins Team,” your “GitHub Team,” or even, as one of our customers described, your “Duct Tape Team” (designed to hold it all together and patch holes), added no end value beyond keeping everything from falling apart. That’s a lot of investment to keep the lights on.\n\nIt’s a hard commitment to swallow, and the truth of it is that you shouldn’t have had to. A big part of the problems behind many “low-performing DevOps teams” stems from a poor set of tools for the job. Broadly put, on behalf of the DevOps tool industry: It’s not you, it’s us. The industry created many of these problems because we were thinking small and building to match.\n\n\nAs a philosophy, DevOps is pretty new, and it’s evolved very quickly. That rapid evolution has meant tremendous transformational opportunity, but building for the present left many tools, and the processes behind them, obsolete as soon as they hit the market. \n\nDevOps toolmakers have long been focused on solving discrete, easily understood problems (“BYO DevOps” in Sid’s blog), while DevOps has always aimed at solving bigger problems and looked to a more collaborative, productive transformation. You knew that when you tried to calm the chaos by implementing standards (BIC DevOps). You knew that when you tried to Frankenstack those tools into a servant of your larger ambitions with DIY DevOps integrations. But in the end, tools were creating almost as much work as they automated.\n\nIt makes sense when requirements are evolving so quickly. In 2011, when GitLab offered just a repository and issues, we couldn’t have foreseen [Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) or [ML Ops](/handbook/engineering/incubation/mlops/), but ten years later, they’re a key components of a movement toward a DevOps Platform for everyone. And that’s the point of the DevOps Platform Era (Phase 4). We’ve iterated our way to a place where we can replace blockers with enablement, and \\*support\\* your efforts instead of increasing your burden.\n\n**[Stop paying the “DevOps tax” by moving to a DevOps Platform. [Here’s how](/topics/devops/use-devops-platform-to-avoid-devops-tax/)]**\n\nThis isn’t unexpected. Every technology reaches this inflection point as it evolves. In the not-too-distant-past, customer relationship management (CRM) required a portfolio of sales force automation and marketing automation tools, commerce engines, app servers, analytics engines, and huge amounts of data integration to make it work. Now we have SaaS-based CRM solutions with a single monthly fee.\n\nWhile GitLab has always focused on delivering a DevOps Platform as a single application, we're excited to see the industry as a whole shift to a platform mindset. Late last year, Gartner released its vision of the [DevOps Value Stream Delivery Platform](/solutions/value-stream-management/) in a new [Market Guide](https://page.gitlab.com/resources-report-gartner-market-guide-vsdp/), in which we’re happy to be a representative vendor, and we’re excited to watch their coverage grow.\n\n**[Make [the most out of your DevOps platform](/topics/devops/seven-tips-to-get-the-most-out-of-your-devops-platform/)]**\n\nWe’re also excited to hear how a DevOps Platform benefits our customers in concrete ways. In our [2021 DevSecOps Survey](/developer-survey/), respondents told us a DevOps Platform resulted in better DevOps, improved collaboration, easier automation and expanded visibility and traceability. Or, as one survey taker said, a DevOps Platform “gives us reduced mean time to recovery (MTTR), quicker time to market, reduced lead time for fixes, and fewer change failures.”\n\nDevOps hasn’t stopped evolving, and neither have we, but we’ve reached the point where we know how the pieces need to work together, and we’ve built a platform to support it. To see for yourself, [try GitLab Ultimate for free](/free-trial/)!\n\n## Read more about the DevOps Platform:\n\n- [How ten steps over ten years led to the DevOps Platform](/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform/)\n\n- [Making the case for a DevOps platform: What data and customers say](/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say/)\n\n- [Agile planning with a DevOps platform](/blog/agile-planning-with-a-devops-platform/)\n\n- [Welcome to the DevOps Platform era](/blog/welcome-to-the-devops-platform-era/)\n\n- [It's time to build more accessible software. A DevOps platform can help](/blog/how-the-devops-platform-makes-building-accessible-software-easier/)\n\n",[851,1208,9],{"slug":5776,"featured":6,"template":683},"the-journey-to-a-devops-platform","content:en-us:blog:the-journey-to-a-devops-platform.yml","The Journey To A Devops Platform","en-us/blog/the-journey-to-a-devops-platform.yml","en-us/blog/the-journey-to-a-devops-platform",{"_path":5782,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5783,"content":5789,"config":5795,"_id":5797,"_type":13,"title":5798,"_source":15,"_file":5799,"_stem":5800,"_extension":18},"/en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab",{"title":5784,"description":5785,"ogTitle":5784,"ogDescription":5785,"noIndex":6,"ogImage":5786,"ogUrl":5787,"ogSiteName":670,"ogType":671,"canonicalUrls":5787,"schema":5788},"The ultimate guide to least privilege access with GitLab","This tutorial demonstrates how to achieve least privilege access using custom roles, security policies, compliance pipelines, branch protections, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099438/Blog/Hero%20Images/Blog/Hero%20Images/built-in-security_built-in-security.jpeg_1750099438377.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to least privilege access with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-03-06\",\n      }",{"title":5784,"description":5785,"authors":5790,"heroImage":5786,"date":5791,"body":5792,"category":704,"tags":5793},[2234],"2024-03-06","The principle of least privilege ([PoLP](https://csrc.nist.gov/glossary/term/least_privilege)) is a concept in which a user's access rights should be limited to the bare minimum needed for them to complete the tasks required within their respective roles. By implementing PoLP you can enhance your organization's [security posture](https://csrc.nist.gov/glossary/term/security_posture), complementing zero trust, in the following ways:\n\n- **Reduction of attack surface:** If credentials are compromised, the breach will be limited to only the paths where the compromised account has access.\n- **Protection against human error:** Users will not be able to perform actions that are not required for their role.\n- **Adherence to compliance:** Separation of duties and least privilege best practices are required for several compliance mandates such as SOC2 and HIPAA.\n- **Reduced system downtime:** By preventing everyone from accessing critical parts of the software development lifecycle (SDLC), there is less likelihood of downtime.\n\nGitLab provides a variety of different features that allow you to customize the actions a user can perform which assist in the achievement of PoLP. These features include:\n\n- **[Custom roles and granular security permissions](#custom-roles-and-granular-security-permissions):** Allows creation of roles with permissions that are specific to particular functions required by the organization.\n- **[Security policies](#security-policies):** Allows policies to be created that prevent insecure code from being merged into production branches without approval, and run security scanners regardless of your pipeline definition.\n- **[Branch protections and Code Owners](#branch-protections-and-code-owners):** Imposes further restrictions on certain branches to control permissions such as who can merge, push, etc. to defined branches.\n- **[Compliance pipelines and frameworks](#compliance-pipelines-and-frameworks):** Identifies that your project has certain compliance requirements or needs additional oversight, enforcing a pipeline configuration to the projects on which it is applied.\n\nIn this blog post, you'll learn each of the features mentioned, how they improve your organization's security posture, as well as how to implement them.\n\nWatch my video, which introduces you to achieving PoLP with GitLab:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jvZ3eqWMeSY?si=DedSYiBNy2kTLJKo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Custom roles and granular security permissions\n\nGitLab allows you to create [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html), which apply additional permissions to base roles to meet the security needs of your organization. The available [base roles](https://docs.gitlab.com/ee/user/permissions.html#roles) are as follows:\n\n- Guest\n- Reporter\n- Developer\n- Maintainer\n- Owner\n\nEach base role applies a particular set of permissions to a user. Base roles apply different permissions for [group members](https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions), [project members](https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions), and in [project features](https://docs.gitlab.com/ee/user/permissions.html#project-features-permissions). For example, the table below shows which roles can view the project [dependency list](https://docs.gitlab.com/ee/user/application_security/dependency_list/):\n\n| Base role    | Can view project dependency list     |\n| ---------- | ---------- |\n| Guest      | ❌       |\n| Reporter      | ❌       |\n| Developer      | ✅       |\n| Maintainer      | ✅       |\n| Owner       | ✅     |\n\n\u003Cbr>\u003C/br>\nThe dependency list also known as a software bill of materials ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)), displays your project's dependencies\nand key details about those dependencies. It makes sense that only those actively working on a project should\nbe able to see what dependencies are present to limit any exploitation of your application using its dependencies.\n\nHowever, there are cases in which a Guest may need to see the SBOM to assist the organization in\n[achieving compliance](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/). By using custom roles, a new role can be created with all the limited permissions of the Guest role, and additionally, the ability to view the project dependency list can be added. Therefore, we have a Guest assisting us with compliance with the least privileged access required for their job.\n\nWatch my video on custom roles and granular security permissions with GitLab:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/WyrhkpO5WkI?si=4B4mNYNK9UyNrru8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Granular permissions\n\nAs of the GitLab 16.8 release, the following granular permissions can be added to any base role:\n\n- Viewing project code\n- Viewing vulnerability reports\n- Changing the status of vulnerabilities\n- Viewing SBOMs\n- Approving merge requests\n- Managing project/group access tokens\n- Adding/removing group members\n- Archiving/unarchiving/removing projects\n- Admin Terraform state\n\nWe will continue to add [more granular permissions](https://docs.gitlab.com/ee/user/custom_roles/abilities.html) with each GitLab release. You can learn more about our roadmap for this feature by referring to the [Granular Security Permissions Epic](https://gitlab.com/groups/gitlab-org/-/epics/10684) and provide feedback in the [customer feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/391760). You also have the ability to contribute to GitLab and [develop your own granular permissions](https://docs.gitlab.com/ee/development/permissions/custom_roles.html).\n\n### Implementation prerequisites\nThe requirements for implementing custom roles are as follows: \n- Owner role in the top-level group in which you are creating the custom role\n- Administrator for the self-managed instance in which you are creating the custom role\n- GitLab Ultimate tier in the top-level group\n- A [personal access token with the API scope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)\n\nTo see custom roles in action requires:\n- a private project within the top-level group or its subgroups\n- a guest user within the private project\n\nWhen you enable a custom role for a user with the Guest role, that user has access to elevated permissions, and therefore:\n- is considered a billable user on self-managed GitLab\n- uses a seat on GitLab.com\n\n### Creating the custom role with granular permissions\n\nNow that you know the benefits of implementing custom roles with granular permissions, let's implement them within our GitLab instance:\n\n1. On the left sidebar, select **Search or go to**.\n    - In GitLab SaaS find and select the top-level group in which you want to create a custom role.\n    - In GitLab Self-Managed find and select **Admin Area**.\n2. Select **Settings > Roles and Permissions**.\n    - In GitLab Self-Managed use the top dropdown list to find and select the top-level group in which you want to create a custom role.\n3. Select **Add new role**.\n4. Under Base role to use as a template, select **Guest** for this tutorial.\n5. Under Role name, enter the custom role’s title.\n6. Under Permissions for the custom role, select **Read Vulnerability** for this tutorial.\n7. Select **Create a new role**.\n\n![Create new role screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099455072.png)\n\n\u003Ccenter>\u003Ci>Interface for creating a custom role\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nAfter creating the role you should be able to see the new custom role along with its ID, Base role, and Permissions. Be sure to save the ID as it will be used when we assign the custom role to a guest user.\n\n![Custom role screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099455073.png)\n\n\u003Ccenter>\u003Ci>Security Auditor role created\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nNow we must assign the custom role to a group or project member. This can be done as follows:\n1. Invite a user as a direct member with the Guest role to your top-level group where the custom role was created.\n2. You can invite them to a sub-group or private project within the top-level group as well.\n* The guest user should not be able to see any code within the project they have been assigned to.\n* Open your terminal.\n3. Export the required environment variables:\n* Your [personal access token with API scope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)\n\n```\n$ export TOKEN=glpat-XXXXXXXXXXXX\n$ echo $TOKEN\nglpat-XXXXXXXXXXXX\n\n```\n\n* The ID of the user we will be granting a custom role to. You can obtain the user id by providing the username to the [User API](https://docs.gitlab.com/ee/api/users.html#list-users). For more information on using the GitLab API, see the [REST API documentation](https://docs.gitlab.com/ee/api/rest/).\n\n```\n$ curl \"https://gitlab.example.com/api/v4/users?username=fjdiaz\"\n[{\"id\":4710074,\"username\":\"fjdiaz\",\"name\":\"Fern\",\"state\":\"active\",\"locked\":false,\"avatar_url\":\"https://gitlab.com/uploads/-/system/user/avatar/4710074/avatar.png\",\"web_url\":\"https://gitlab.com/fjdiaz\"}]\n\n$ export USER_ID=4710074\n$ echo $USER_ID\n4710074\n```\n\n* The ID of the custom role. You can obtain the custom role ID from the ID column in the [custom roles UI](https://docs.gitlab.com/ee/user/custom_roles.html#gitlab-saas) or the [member roles API](https://docs.gitlab.com/ee/api/member_roles.html#add-a-member-role-to-a-group).\n\n```\n$ export CUSTOM_ROLE_ID=1000782\n$ echo $CUSTOM_ROLE_ID\n1000782\n```\n\n* The ID of your group or project. You can obtain the group id from the [group UI](https://docs.gitlab.com/ee/user/group/#get-the-group-id) or using the [groups API](https://docs.gitlab.com/ee/api/groups.html). You can obtain the project ID from the [project UI](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-the-project-overview-page-by-using-the-project-id) or using the [projects API](https://docs.gitlab.com/ee/api/projects.html).\n\n```\n$ export GROUP_ID=10087220\n$ echo $GROUP_ID\n10087220\n\n$ export PROJECT_ID=45738177\n$ echo $PROJECT_ID\n45738177\n```\n\n4. Associate the guest user with the custom role using the appropriate [group or project APIs](https://docs.gitlab.com/ee/api/members.html#edit-a-member-of-a-group-or-project).\n\n* If the user just needs to role in a project, update the project membership:\n\n```\n\"Authorization: Bearer $TOKEN\" --data '{\"member_role_id\": $CUSTOM_ROLE_ID, \"access_level\": 10}' \"https://gitlab.example.com/api/v4/projects/$PROJECT_ID/members/$USER_ID\"\n```\n\n* If the user just needs to role in a group, update the group membership:\n\n```\n$ curl --request PUT --header \"Content-Type: application/json\" --header \"Authorization: Bearer $TOKEN\" --data '{\"member_role_id\": $CUSTOM_ROLE_ID, \"access_level\": 10}' \"https://gitlab.example.com/api/v4/groups/$GROUP_ID/members/$USER_ID\"\n```\n\nNow that the custom role has been applied to a guest user, when they login, they can see the Vulnerability dashboard present in the Secure tab. Notice, however, that they are still not allowed to see the source code. \n\nThis is useful because it allows users to audit the system without being able to make changes to the code base, which applies the PoLP for those auditing the system for vulnerabilities.\n\n## Security policies\nGitLab provides [security policies](https://docs.gitlab.com/ee/user/application_security/policies/) to help you achieve least privilege access. There are two different types of security policies provided by GitLab:\n- [Scan Execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) allow project maintainers and administrators the confidence of knowing that the scans they set up have not been changed, altered, or disabled.\n- [Merge Request Approval policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) prevent insecure code from being merged into production without appropriate approval.\n\nSome examples of how both policy types can be used in unison to provide least privilege access are as follows:\n- remove the ability for developers to disable security scanners\n- remove the ability for developers to merge insecure code\n\nPolicies are stored in a separate repo from the project they are being applied to called the Security Policy Project (SPP). This allows for separate permissions to be set to the SPP vs. the application repo, thus strengthening your ability to separate duties and apply PoLP.\n\n![Security policy hierarchy](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750099455074.png)\n\n\u003Ccenter>\u003Ci>Security policy hierarchy\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nTo enforce the policies contained in an SPP you link it to a project, subgroup, group, or multiples of each. An SPP can contain multiple policies but they are enforced together. An SPP enforced on a group or subgroup applies to everything below the hierarchy, including all subgroups and their projects.\n\nSecurity policies can be managed via the policy management UI as well as via yaml. Using the policy editor you can create, edit, and delete policies.\n\n![Policy management interface](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750099455076.png)\n\n\u003Ccenter>\u003Ci>Policy management interface\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nFeel free to leverage the [Simple Notes demo environment](https://gitlab.com/gitlab-de/tutorials/security-and-governance/devsecops/simply-vulnerable-notes) to try this yourself by following the provided [DevSecOps tutorial](https://gitlab-de.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/).\n\n### Creating a Scan Execution policy\nNow let's take a look at how to create a Scan Execution policy. Before getting started make sure you have met the following criteria:\n- GitLab Ultimate tier in the top-level group\n- Owner role to create/assign an SPP\n- Developer role or greater to create/edit/delete individual security policies\n\nWe will be creating a policy that automatically runs a SAST scan with each pipeline, regardless of the SAST template is defined within the gitlab-ci.yml:\n\n1. On the left sidebar, select **Search or go to** and search for the project to which you wish to add a policy.\n2. On the project left sidebar, go to **Secure > Policies**.\n3. Select **New policy**.\n4.  In the **Scan Execution Policy** section, select **Select policy**.\n5. Complete the fields:\n    - **Name:** The name of the policy\n    - **Description:** The description of the Policy\n    - **Policy status:** Whether it is enabled or not\n    - **Actions:** What actions to take when the defined conditions are met\n\n![Scan Execution policy actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750099455077.png)\n\n \u003Ccenter>\u003Ci>Scan Execution policy actions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n  - **Conditions:** Conditions which must be met (a pipeline is triggered or on a set schedule) in order for an action to take place.\n\n    ![Scan Execution policy conditions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099455078.png)\n \u003Ccenter>\u003Ci>Scan Execution policy conditions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n- Press the **Configure with a merge request** button.\n\nNow that the policy has been created, all we need to do is run a pipeline to see that SAST will be present even if it is not defined in the .gitlab-ci.yml.\n\n### Creating a Merge Request Approval policy\n\nNow let's take a look at how to create a Merge Request Approval policy. Before getting started make sure you have met the following criteria:\n- GitLab Ultimate tier in the top-level group\n- Owner role to create/assign an SPP\n- Developer role or greater to create/edit/delete individual security policies\n- Security scanners added to project\n\nWe will be creating a policy that requires approval from project maintainers if any security scanner detects a vulnerability when compared with any branch:\n\n1. On the left sidebar, select **Search or go to** and search for the project to which you wish to add a policy.\n2. On the project left sidebar, go to **Secure > Policies**\n3. Select **New policy**\n4. In the **Merge Request Approval policy** section, select **Select policy**.\n5. Complete the fields:\n    - **Name:** The name of the policy\n    - **Description:** The description of the policy\n    - **Policy status:** Whether it is enabled or not\n    - **Rules:** The conditions which must be met for an action (require approval) to take place.\n\n![Merge Request Approval policy rules](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750099455079.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval policy rules\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n   - **Actions:** The action to be taken whenever the conditions in the rules (defined vulnerabilities/licenses detected) are met.\n\n![Merge Request Approval  policy actions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099455080.png)\n\u003Ccenter>\u003Ci>Merge Request Approval  policy actions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n   - **Override project approval settings:** If selected, the following choices will overwrite project settings but only affect the branches selected in the policy.\n\n![Merge Request Approval policy approval settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750099455081.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval policy approval settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n6. Press the **Configure with a merge request** button.\n\nNow that the policy has been created, all we need to do is run a pipeline and if SAST detects any vulnerabilities then approvals will be required from the selected approver before the code change can be merged. Merge Request Approval policies can be used with all GitLab security scanners, including license scanning.\n\n![Merge Request Approval policies blocking code from being merged in an MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099455082.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval policies blocking code from being merged in an MR\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n## Branch protections and Code Owners\n[Branch protections](https://docs.gitlab.com/ee/user/project/protected_branches.html) allow you to impose additional restrictions on particular branches within your repository. This further strengthens the PoLP for the interactions on a particular set of branches. \n\nFor example, a protected branch can control:\n- which users can merge into the branch\n- which users can push to the branch\n- if users can force push to the branch\n- if changes to files listed in the CODEOWNERS file can be pushed directly to the branch\n- which users can unprotect the branch\n\n### Applying branch protections\n\nBranch protections are available in all tiers and offerings of GitLab. Branch protections can be applied to a single project or a group of projects. You can apply branch protections for required roles to push and merge as follows:\n\n1. On the left sidebar, select **Search or go to** and find your project or group.\n2. Select **Settings > Repository**.\n3. Expand **Protected branches**.\n4. Select **Add protected branch**.\n    - For groups, from the **Branch** text box, type the branch name or a wildcard.\n    - For projects, from the **Branch** dropdown list, select the branch you want to protect.\n5. From the **Allowed to merge** list, select a role that can merge into this branch.\n6. From the **Allowed to push and merge** list, select a role that can push to this branch.\n7. Select **Protect**.\n\nYou should now see the protected branch added to the list.\n\n![Protected branches settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750099455082.png)\n\n\u003Ccenter>\u003Ci>Protected branches settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nThe Owner role is required to add branch protections to a group and the Maintainer role or greater is required to add branch protections to a project.\n\n### Code Owners\nIf you want to further limit what files developers can perform changes on, one of the best features to implement is [Code Owners](https://docs.gitlab.com/ee/user/project/codeowners/). Code Owners allows you to define who has the expertise for specific parts of your project’s codebase. Defining the owners of files and directories in Code Owners will:\n\n- require owners to approve changes as well as merge requests before they merge into a protected branch\n- identify owners by displaying the Code Owner names on the files and directories they own\n\nTo set up Code Owners, follow these steps:\n1. Create a CODEOWNERS file in your preferred location.\n2. Define some rules in the file following the Code Owners syntax reference. You can configure all eligible approvers' approval rules and require Code Owner approval on a protected branch.\n3. Commit your changes, and push them up to GitLab.\n\nNow, when looking at files, you can see who the Code Owners are for a particular file.\n\n![Code Owners displayed for file](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099455083.png)\n\n\u003Ccenter>\u003Ci>Code Owners displayed for file\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nIf you implement Code Owner approvals, then when creating a merge request, the Code Owners must approve before the code can be merged.\n\n![Code Owners approvals](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099455084.png)\n\n\u003Ccenter>\u003Ci>Code Owners approvals\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n### Additional approval settings\nThere are additional approval settings that can be applied before code can be committed with a merge request. These additional approval settings are as follows:\n- prevent approval by author\n- prevent approvals by users who add commits\n- prevent editing approval rules in merge requests\n- require user re-authentication (password or SAML) to approve\n\nAdditionally, whenever a commit is added, you can:\n- keep approvals\n- remove all approvals\n- remove approvals by Code Owners if their files changed\n\n![Additional Approval settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750099455084.png)\n\n\u003Ccenter>\u003Ci>Additional Approval settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nTo configure additional approval settings you can perform the following steps:\n1. On the left sidebar, select **Search or go to** and find your project.\n2. Select **Settings > Merge requests**.\n3. Scroll down to the **Merge request approvals** section.\n4. Under **Approval settings** select the approval settings you would like to apply.\n5. Press the **Save changes** button.\n\nThese can also be applied to your top-level group by performing the following steps:\n1. On the left sidebar, select **Search or go to** and find your top-level group.\n2. Select **Settings > General**.\n3. Expand the **Merge request approvals** section.\n4. Under **Approval settings** select the approval settings you would like to apply.\n5. Press the **Save changes** button.\n\nBy leveraging these approval settings you can make sure that code always obtains oversight by a person who was not involved in creating the code, thereby preventing a conflict of interest.\n\n## Compliance pipelines and frameworks\nYou can create a compliance framework that is a label to identify that your project has certain compliance requirements or needs additional oversight. The label can optionally enforce compliance pipeline configuration to the projects on which it is applied.\n\nFeel free to leverage the [Compliance Frameworks Demo](https://gitlab.com/gitlab-de/tutorials/security-and-governance/compliance-frameworks) group to see an example of compliance frameworks and their usage.\n\n### Create a compliance pipeline\nTo create a compliance pipeline, all you need to do is create a new project which will store a `.gitlab-ci.yml` file that we wish to use in another project. The new compliance pipeline project can have separate permissions from the project to which you will apply it. This is beneficial because it prevents developers from making changes to pipelines that must run.\n\nYou can see I have created the following [pipeline definition](https://gitlab.com/gitlab-de/tutorials/security-and-governance/compliance-frameworks) which:\n- runs the SAST security scanner\n- runs the secret detection scanner\n- runs a SOC2 compliance job\n- runs the original pipeline defined in the project to which we will apply this pipeline. This allows developers to focus on the actual application development and the compliance team to focus on defining the SOC2 rules.\n\n### Create and apply a compliance framework\nNow that the compliance pipeline for SOC2 has been defined, we must define a compliance framework and apply it to our project. In this case, I will apply it to my Accounting Department project.\n\nTo create a compliance framework label, follow these steps:\n1. On the left sidebar, select **Search or go to** and find your group.\n2. Select **Settings > General**.\n3. Expand the **Compliance frameworks** section.\n4. Click the **Add framework** button.\n5. Create a new compliance framework and populate the following sections:\n    - **Name:** The name of your compliance framework\n    - **Description:** A description of your compliance framework\n    - **Compliance pipeline configuration:** The location of the compliance pipeline to run. \n    - **Background color:** A color for the compliance framework label\n\n![PoLP - image 15](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750099455085.png)\n\n   \u003Ccenter>\u003Ci>Creating a compliance framework\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n6. Press the **Add framework** button.\n\nAnd now you should see your newly added framework under active compliance frameworks.\n\n![Active compliance frameworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750099455085.png)\n\n\u003Ccenter>\u003Ci>Active compliance frameworks\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nNow let’s go ahead and assign this compliance label to our Accounting Department project:\n\n1. On the left sidebar, select **Search or go to** and find your project.\n2. Select **Settings > General**.\n3. Expand **Compliance frameworks**.\n4. Select the compliance framework created above.\n\n![Adding a compliance framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099455086.png)\n\n\u003Ccenter>\u003Ci>Adding a compliance framework\u003C/i>\u003C/center>\n\n5. Select **Save changes**.\n\nThe project should now have the compliance framework label applied. \n\n![Project running a compliance pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750099455086.png)\n\n\u003Ccenter>\u003Ci>Project running a compliance pipeline\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nThis enables separation of duties and prevents compliance pipelines from being altered by those without permissions.\n\nSecurity Policy Scope and Pipeline Execution\nOver the past several releases, GitLab has introduced two experimental features, Security Policy Scope and Pipeline Execution, to make it even easier to adhere to PoLP. These features are very similar to Compliance Pipelines and Compliance Frameworks and can be managed from GitLab’s security policy UI.\n\n**Note:** These features are currently considered experimental. An experiment is a feature that is in the process of being developed. It is not production ready. We encourage users to try experimental features and provide feedback.\n\nThe [pipeline execution policy action](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#pipeline-execution-policy-action) introduces a new scan action type into Scan Execution policies for creating and enforcing custom CI in your target development projects. You can execute a custom pipeline along with your current pipeline. This allows you to enforce compliance by always forcing particular actions to run that are not just security scanners and that cannot be overwritten by those without permissions.\n\n![Pipeline Execution policy scope selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750099455087.png)\n\u003Ccenter>\u003Ci>Pipeline Execution policy scope selection - insert code block\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n![Pipeline Execution policy scope selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750099455087.png)\n\u003Ccenter>\u003Ci>Pipeline Execution policy scope selection - link existing CI file\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\nThe [Security policy scope](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes) can be applied to either Merge Request Approval or Scan Execution policies. Scopes enable you to administer policies with a particular scope, meaning you can:\n\n- Include only projects containing a compliance framework label\n- Include or exclude selected projects from enforcement\n\nTo enable these experimental features, follow these steps:\n1. On the left sidebar, select **Search or go to** and find your top-level group.\n2. Select **Settings > General**.\n3. Expand **Permissions and group features**.\n4. Scroll down to the **Security policy management** section.\n5. Select the following checkboxes\n**Security policy pipeline execution action:** Create and enforce custom CI jobs and scripts using this new policy action.\n6. **Security policy scopes:** Granularly scope each policy you create to projects containing a compliance framework label, or a list of projects.\n7. **Enforce for all subgroups (optional):** Subgroups cannot change these settings.\n8. Scroll down to the **Experiment and Beta features** section.\n9. Select the **Use Experiment and Beta features** checkbox.\n10. Scroll down and press the **Save changes** button.\n\nNow, whenever you are creating a security policy, the following options will be available:\n\n- Inserting a CI code block (Scan Execution policy only)\n- Loading CI/CD code from file (Scan Execution policy only)\n- Linking an existing CI file from another project (Scan Execution policy only)\n- Scoping a policy to projects with selected compliance framework (Group Level only)\n- Scoping a policy towards specific projects (Group Level only)\n- Scoping a policy towards all projects in group (Group Level only)\n\nTo learn more about these features, check out the following documentation:\n- [Pipeline Execution Policy action (Scan Execution policy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#pipeline-execution-policy-action)\n- [Security Policy Scopes (Scan Execution policy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#security-policy-scopes)\n- [Security Policy Scopes (Merge Request Approval policy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes)\n\n## Additional resources\n\nThanks for reading! These are some of the ways that GitLab allows you to strengthen your organization's security posture through the enablement of PoLP. To learn more about GitLab and the other ways we can strengthen your organization's security throughout all parts of the SDLC, check out the following links:\n\n- [GitLab Security and Compliance](https://about.gitlab.com/solutions/security-compliance/)\n- [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)\n- [GitLab DevSecOps Demo Project](https://gitlab.com/gitlab-de/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n- [GitLab DevSecOps Tutorial](https://gitlab-de.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n- [GitLab Roles and Permissions Documentation](https://docs.gitlab.com/ee/user/permissions.html)\n- [GitLab Custom Roles Documentation](https://docs.gitlab.com/ee/user/custom_roles.html)\n- [GitLab Security Policies Documentation](https://docs.gitlab.com/ee/user/application_security/policies/)\n- [GitLab Compliance Frameworks Documentation](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html)\n- [GitLab Code Owners Documentation](https://docs.gitlab.com/ee/user/project/codeowners/)\n- [GitLab Branch Protections Documentation](https://docs.gitlab.com/ee/user/project/protected_branches.html)",[5794,746,704,9],"zero trust",{"slug":5796,"featured":90,"template":683},"the-ultimate-guide-to-least-privilege-access-with-gitlab","content:en-us:blog:the-ultimate-guide-to-least-privilege-access-with-gitlab.yml","The Ultimate Guide To Least Privilege Access With Gitlab","en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab.yml","en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab",{"_path":5802,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5803,"content":5809,"config":5815,"_id":5817,"_type":13,"title":5818,"_source":15,"_file":5819,"_stem":5820,"_extension":18},"/en-us/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":5804,"description":5805,"ogTitle":5804,"ogDescription":5805,"noIndex":6,"ogImage":5806,"ogUrl":5807,"ogSiteName":670,"ogType":671,"canonicalUrls":5807,"schema":5808},"The ultimate guide to token management at GitLab","Learn all the steps in the end-to-end process of identifying, managing, and securing tokens for improved security across the software development lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to token management at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }",{"title":5804,"description":5805,"authors":5810,"heroImage":5806,"date":5812,"body":5813,"category":704,"tags":5814},[5811],"Hakeem Abdul-Razak","2025-02-25","Imagine this: You are an engineer at a growing tech company, and it’s 2 a.m. when you get an urgent call. A critical deployment pipeline has failed, and your team is scrambling to figure out why. After hours of digging, you realize someone revoked a personal access token belonging to an engineer who left the company a week ago. This token was tied to several key automation processes, and now your entire system is in chaos. How do you make sure it does not happen again?\n\nFollow this guide, which takes GitLab customers through the end-to-end process of identifying, managing, and securing their tokens. It is meant to be a handy supplement to the extensive [token overview documentation](https://docs.gitlab.com/ee/security/tokens) for GitLab administrators, developers, and security teams who need to ensure proper token management within their projects.\n\nHere's what is covered in this guide:\n- [How to select the right token for the job](#how-to-select-the-right-token-for-the-job)\n- [Token types](#token-types)\n- [Discovering your tokens](#discovering-your-tokens)\n    - [Credentials inventory](#credentials-inventory)\n- [Managing tokens in the GitLab UI and API](#managing-tokens-in-the-gitlab-ui-and-api)\n- [Token rotation and expiration management](#token-rotation-and-expiration-management)\n- [Token management best practices](#token-management-best-practices)\n    - [Service accounts](#service-accounts)\n\n## How to select the right token for the job\n\nChoosing the right token ensures optimal security and functionality based on your use case. \nTokens can be used for authenticating API requests, automating CI/CD pipelines, integrating third-party tools, managing deployments and repositories, and more.\n\n![Token management guide - flow chart for tokens](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\nFor the sake of simplicity, the chart illustrates a straightforward use case tied to single user ownership. For more information, check out our documentation of user roles and permissions at each [namespace](https://docs.gitlab.com/ee/user/permissions.html) (user/group) in your instance or top-level group. Example use cases could be as follows: \n\n- **Personal access tokens** ([PAT](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)) can be used by developers when a user's personal access and permissions are required. In this case, the credentials follow the status and permissions of the user, including the removal of access if the account loses access to a specific project or group (or is blocked entirely).   \n- **Project/group access tokens** ([PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token)/[GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)) are recommended when access should be scoped to resources within a specific project/group, allowing anyone with a PrAT/GrAT to access those resources through mechanisms managed by assigned scopes.\n\n## Token types\n\nBelow is a list of GitLab tokens with their default prefixes and use cases. For more information, please visit the [GitLab Token overview page](https://docs.gitlab.com/ee/security/tokens/#available-scopes). \n\n| Tokens | Prefix  | Description |\n| :---: | :---: | :---: |\n| Personal access token | glpat | Access user-specific data |\n| OAuth 2.0 token |  gloas | Integrate with third-party applications using OAuth2.0 authentication protocol |\n| Impersonation token | glpat | Act on behalf of another user for administrative purposes |\n| Project access token | glpat | Access data from a specific project |\n| Group access token | glpat |  Access data from a specific group |\n| Deploy token | gldt |  Clone, push, and pull container registry images of a project without a user and a password |\n| Deploy keys | N/A | Allow read-only or read-write access to your repositories |\n| Runner authentication token | glrt | Authenticate GitLab Runners |\n| CI/CD job token  | glcbt | Automate CI/CD processes |\n| Trigger token | glptt | Trigger pipelines manually or programmatically |\n| Feed token | glft | Authenticate access to package/RSS feeds |\n| Incoming mail token  | glimt | Process incoming emails |\n| GitLab agent for Kubernetes token | glagent | Manage Kubernetes clusters via the GitLab agent |\n| SCIM tokens | glsoat | Enable SCIM integrations for user provisioning |\n| Feature flags client token | glffct | Enable feature flags programmatically |\n| Webhook token | N/A | User set secret token to secure webhook payloads and ensure that the requests are from GitLab |\n\n## Discovering your tokens\n\n### Credentials inventory\n\nOn GitLab Ultimate, administrators (GitLab Self-Managed) and top-level group owners of an enterprise organization (GitLab.com as of Version 17.5) can monitor the credentials in their namespace.\n\nThis inventory tracks token details such as:\n\n* Token type  \n  * Available tokens on [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)  \n  * Available tokens on [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)  \n* Associated user accounts  \n* Token scopes, and creation and expiration dates  \n* Token last used IP addresses (as of GitLab 17.10)  \n* Token filtration based on the above user-defined parameters  \n* Ability to revoke and rotate those tokens\n\nA well-maintained credentials inventory helps identify over-permissioned tokens, and gives insight into credentials that may need to be rotated, ensuring a secure and efficient workflow.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Credentials inventory API\n\nAs a complement to the UI, there is [ongoing development](https://gitlab.com/groups/gitlab-org/-/epics/16343) to release a credentials inventory API through the new /group/:id/manage [endpoint](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project). The credentials accessible under this endpoint are limited to enterprise [users](https://docs.gitlab.com/ee/user/enterprise_user/), and can be accessed by the top-level group owner of an enterprise organization. An example of the future API call would be:\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\" \"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"           \n```\n### GitLab API\n\nThe GitLab API allows you to programmatically list and manage tokens within your organization. Key authentication-related endpoints support [various token types](https://docs.gitlab.com/ee/api/rest/authentication.html)), including personal, group, CI/CD tokens, and more. An example of using a personal access token to list all visible projects across GitLab for the authenticated user is:\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \\\n     \"https://gitlab.example.com/api/v4/projects\"\n\n```\n\nWatch this video to learn how to make API calls to the GitLab API.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Finding where tokens are used\n\nCustomers can find where tokens are used in different ways:\n* under **User Profile > [Access Tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n* in credentials inventory\n* in audit events\n* via the API \n\nInformation on token usage is updated every 10 minutes for **last_used** and every minute for **last_used_ip**. \n\nThe ability to view IP addresses was introduced in GitLab 17.9, and is controlled by the **:pat_ip** feature flag. Follow these [steps to view the last time a token was used](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used), along with its last five distinct IP addresses.\n\n![Token management guide - personal access tokens settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n## Managing tokens in the GitLab UI and API\nThe following table includes videos detailing a few token creations in the UI and demonstrates their usage via the API.\n\n| Tokens     | GitLab UI    | GitLab API    |\n| ---------- | ---------- | ---------- |\n| Personal access token | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=3)  | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=43)  |\n| Group access token | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) and [video](https://youtu.be/v5Nj3Jy4vaI?t=120)  | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=157)  |\n| Project access token | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) and [video](https://youtu.be/v5Nj3Jy4vaI?t=254)  | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=285)  |\n\n## Token rotation and expiration management\n\nImplementing token rotation and strict expiration policies reduces the risk of compromise and ensures compliance with security standards. Regular rotation and enforced expirations prevent stale credentials from becoming security vulnerabilities.\n\nPreviously, expired group and project access tokens were automatically deleted upon expiration, which made auditing and security reviews more challenging due to the lack of a record of inactive tokens. To address this, a [recent feature](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) introduced the retention of inactive group and project access token records in the UI for 30 days after they became inactive. This enhancement aims to allow teams to track token usage, expiration, and revocation for better compliance and monitoring.\n\nTo be more proactive in your token rotation and expiration management, do the following: \n\n* Actively rotate your tokens via the UI or API. If you use the latter, be mindful of the [automatic token reuse detection](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection) security mechanism.  \n* Set an instance-wide [maximum lifetime limit](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) for access tokens. \n\n### Token rotation API\n\nUntil GitLab 17.7, customers had to programmatically rotate access tokens with the API. Its counterpart is now available on the UI. Check out the video in the table below or follow the [documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui) for guidance.\n\n### Token rotation snippets\n\nThe following table includes videos detailing the rotation of GitLab tokens. \n\n| Tokens | Prerequisites | GitLab UI | GitLab API |\n| :---: | :---: | ----- | ----- |\n| Personal access token | Scope: api\u000b | [Documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=76)  | [Documentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=92)  |\n| Group access token | Scope: api and Role(s): owner | [Documentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) and [video](https://youtu.be/v5Nj3Jy4vaI?t=203)  | [Documentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=214)  |\n| Project access token | Scope: api and Role(s): owner, maintainer | [Documentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) and [video](https://youtu.be/v5Nj3Jy4vaI?t=335)  | [Documentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) and [video](https://youtu.be/v5Nj3Jy4vaI?t=349)  |\n\n## Token management best practices\n\n### Principle of least privilege\n\nMitigate risk by restricting assigned permissions to tokens required for their respective tasks. This allows you to proactively predict and troubleshoot points of failure in your systems. You can do this by: \n\n* Selecting the right token for the right job. See the flowchart.  \n* Assign only the required scopes when creating a token. For example, use read-only scopes for tokens with auditor-like jobs. See [roles](https://docs.gitlab.com/ee/user/permissions.html#roles).  \n* Avoid granting administrative privileges unless specifically required.  \n* Enforce instance-wide default token [lifetimes](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1).  \n* Regularly review and audit token permissions to ensure they align with current operational needs.  \n* Revoke tokens once the task is complete.\n\n### Service accounts\n\n[Service accounts](https://docs.gitlab.com/ee/user/profile/service_accounts.html) ensure tokens are tied to non-human entities, separating them from individual user accounts and reducing dependency on specific users. Instead of using personal accounts to generate tokens for automation, create service accounts with limited scopes. Benefits include:\n\n* Usage of service account tokens in CI/CD pipelines to avoid disruptions caused by user account changes  \n* Programmatically automate rotation processes, as personal accounts remain unaffected  \n* Clearer monitoring and auditing trail of actions taken by service accounts  \n* Service accounts with [no expiration](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date) date  \n* Does not consume [a license seat](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account)\n\nGitLab plans to release a new [Service Accounts UI](https://gitlab.com/groups/gitlab-org/-/epics/9965) as a counterpart to its [API-based creation](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), designed to simplify the management of service accounts and their associated tokens. Check out the demo below on the programmatic usage of service accounts.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Vulnerability tools\n\nLeverage GitLab’s built-in security tools to identify and mitigate vulnerabilities associated with token usage. For maximum coverage, it is recommended to use them all in tandem.\n\n* [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/): Scans your repository for hardcoded secrets like API tokens, passwords, and other sensitive information. View the [list of detected secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html).  \n* [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/): Analyzes your source code for security vulnerabilities and [provides reports with UI findings in merge requests](https://docs.gitlab.com/ee/user/application_security/sast/#features), among other features.  \n* [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/): Ensures that third-party libraries used in your project do not expose token-related vulnerabilities. \n\n### Audit logs and monitoring\n\nMaintain token health by regularly reviewing audit logs and token usage, instance- and/or group-wide.\n\n* [Audit events](https://docs.gitlab.com/ee/user/compliance/audit_events.html): Enable audit event logging in GitLab to track token-related activities such as creation, usage, deletion and unusual API calls (unpermitted parameters in logs, and consistent triggers of the rate limiter). \n* [IP allowlisting](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions): Helps prevent malicious users from hiding their activities behind multiple IP addresses.  \n* [Alerts](https://docs.gitlab.com/ee/operations/incident_management/alerts.html): Set up alerts for unusual activities (trigger paging for on-call rotations or be used to create incidents).  \n* [Credentials inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html): Complete control of all available access tokens with the ability to revoke as needed.  \n* [Notifications](https://docs.gitlab.com/ee/user/profile/notifications.html): Proactively handle any token (group, project, and personal) expiration notification emails you receive. Based on customer demand, this feature was recently extended to include 30-day and 60-day notifications from the seven-day default.   \n* [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook): Access token webhooks can be configured on groups and projects to send seven-day token expiry events. This feature was also recently extended to include 30-day and 60-day notifications behind the **:extended_expiry_webhook_execution_setting** feature flag (disabled by default).\n\n## What's next\n\nWith GitLab’s large token catalog, there are ongoing [plans](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) for consolidation with a focus on the lifetime, fine-grained scopes, consistent management, and usage. Our current prioritized token-related features include a complete UI for service accounts, additional credential types in the credentials inventory, and improved auditing for tokens and service accounts.\n\n> Sign up for a [free 60-day trial of GitLab Ultimate](https://about.gitlab.com/free-trial/) to start using token management.",[746,704,478,9,701],{"slug":5816,"featured":90,"template":683},"the-ultimate-guide-to-token-management-at-gitlab","content:en-us:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","en-us/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","en-us/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":5822,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5823,"content":5829,"config":5836,"_id":5838,"_type":13,"title":5839,"_source":15,"_file":5840,"_stem":5841,"_extension":18},"/en-us/blog/three-levels-data-analysis",{"title":5824,"description":5825,"ogTitle":5824,"ogDescription":5825,"noIndex":6,"ogImage":5826,"ogUrl":5827,"ogSiteName":670,"ogType":671,"canonicalUrls":5827,"schema":5828},"A framework for sssessing data organization maturity","GitLab Data Engineer Emilie Schario lays out a framework for data analysis that can help an organization understand the maturity of their data team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666603/Blog/Hero%20Images/book.jpg","https://about.gitlab.com/blog/three-levels-data-analysis","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The 3 Levels of Data Analysis- A Framework for Assessing Data Organization Maturity\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilie Schario\"}],\n        \"datePublished\": \"2019-11-04\",\n      }",{"title":5830,"description":5825,"authors":5831,"heroImage":5826,"date":5833,"body":5834,"category":1353,"tags":5835},"The 3 Levels of Data Analysis- A Framework for Assessing Data Organization Maturity",[5832],"Emilie Schario","2019-11-04","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIf I had a nickel for every time I saw that [Data Science Hierarchy of Needs](https://hackernoon.com/the-ai-hierarchy-of-needs-18f111fcc007) visual in a presentation at a conference, I'd be a gazillionaire (technical term).\nThe pyramid, a nod to Maslow's Hierarchy of Needs, lays out that data science, in it's Machine Learning or Artificial Intelligence forms, has a series of \"needs\" or requirements that must be met in order to *actually* output AI.\n\nThis visual is great, but I've spent the last couple years working in data, and this visual doesn't capture what I do.\nML and AI are attractive subjects to talk about, but the reality for most organizations is that their data teams are incredibly immature and spend the bulk of their time working on analyses.\nData organization maturity is made up of many factors;\nit's not just the details of your machine learning models, the pedigree of your team members, or the headcount of your function.\nThe maturity of your data organization is not something that can be solved by throwing people at the problem.\n\n## A mature data organization, first and foremost, is a mature analytics organization.\n\nSo, how do you know if you are a mature analytics organization?\n\nThere are three tiers of data analysis: reporting, insights, and prediction.\nAs an organization matures in their data analyses, they move through the tiers.\nThis data analysis framework is not focused on all the things your data team will produce, nor does the framework apply to anything outside of data analysis.\nThings like recommendation engines and predictive analytics are not data analyses;\nthey're a different application of data entirely.\n\nA mature analytics organization is one part of a data function, but it is foundational to a mature data function.\nSpending an investment in *doing analytics right* will pay dividends to your data function down the road.\n\n## The Briefest History of Data\n\nBefore evaluating where data analysis is today, it's important to consider how data got here.\nOnce upon a time, data was impossible to get.\n\nYears ago, SQL was the prerequisite for answering data questions, and those lucky enough to work in an organization that maintained a centralized data warehouse still had to navigate delicate databases easily waylaid by a bad query.\n\nData analysts were the gatekeepers of data.\nAnything that was needed— from a pretty chart for a stakeholder meeting or a spreadsheet produced so business or financial analysts could further dig into the data – had to go through a data analyst.\n\nIn a world where, [knowledge workers are making thousands of decisions a day](https://www.psychologytoday.com/us/blog/stretching-theory/201809/how-many-decisions-do-we-make-each-day), we cannot let data live behind the gates.\nBusiness leaders have recognized this and are investing in building out data teams whose responsibility it is to [democratize data in their organizations](/handbook/business-technology/data-team/).\nData teams are investments in your organization, but they can only provide a return if they mature; and the first step is through reporting.\n\n## Reporting\n\nReporting is the straightforward, simplistic asking and answering of questions.\nThe answers to these simple questions give an idea of what data is needed, but doesn’t allow for the standardization, collection, or tracking of data.\n\n**When you have no answers, you never get beyond looking for facts.**\nExample reporting questions are:\n* How many new users visited our e-commerce site last week?\n* How many leads did we capture this month?\n* How many MRs were merged this week?\n\nSometimes, there is no data to answer these questions.\nThis can help identify gaps and drive conversations around the data being collected.\nWhen getting data is hard, you never move past reporting.\n\nToday, getting data is easy, at least by comparison.\nWith the rise of analytical data warehouses ([at GitLab, we use Snowflake](/handbook/business-technology/data-team/platform/#our-data-stack)) optimized for columnar analyses and incredibly cheap storage, the barriers to analyses are changing, as are the kinds of questions we want to answer.\n\nMost reporting questions are possible to answer in their recording system of truth:\n* You can build a Salesforce dashboard to show you your pipeline for the next quarter.\n* You can build a Heap dashboard to show you user retention.\n* Even [bitmapist](https://github.com/Doist/bitmapist)— an open-source Mixpanel alternative— comes with off-the-shelf user cohorting.\n\nData analysts spending their time building analyses that are available in the system of record aren’t adding value, they’re paying tolls: they’re verifying data and getting buy-in from business stakeholders.\n\nToday, the value in data analyses lies in producing insights.\n\n## Insights\n\nWhile reporting analyses are about *gathering facts* to report on them, insights are about *understanding relationships between facts.*\nDeriving insights is a result of combining systems of records, focusing on looking for relationships in the data.\nThis is different from systems informing systems, such as piping account information from Salesforce into Zendesk to see if you’re meeting your [Support SLAs](/handbook/support/performance-indicators/#service-level-agreement-sla);\ninstead it's about producing insights that can only be gathered by combining two data sources into something new.\n\nThe GitLab Data team’s [net and gross retention analyses](/handbook/customer-success/vision/#retention-and-reasons-for-churn) are a great example of insights.\nWhile subscription information comes from Zuora, our customer accounts— and how they do or don’t roll up into parent accounts— all come from Salesforce.\nIntegrating these two data sources to build out our retention analysis helps inform our Sales and Product teams.\n\nA product manager that knows their engineering team's velocity can better estimate what features will make the next release.\nA sales team that understands what their inbound marketing pipeline is looking like for next quarter is empowered to better plan their work.\nIt's not enough to know that a particular performance indicator is up or down compared to its target;\ninsights help you understand the why behind the fact.\n\nAnswering questions such as these will show the biggest impact and value to your business:\n* Which landing pages have the lowest CAC?\n* What is the average number of site visits before a user converts?\n* What is the MoM user retention in our web application?\n\nInsights are where your data analysts need to be spending their time because insights are where data teams can start providing value.\nAnalysts can only move on to providing insights if they’re not spending all their time building reporting, but accurate reporting _is_ a prerequisite to insights.\n\nA data team that spends all their time producing numbers that already exist for the sole purpose of getting stakeholder buy-in or data tool adoption will quickly find the organization frustrated, as they will not have added new value to the business.\nBeing data-driven means you’ve crossed into a place where decisions are influenced by data, not simply finding data that matches a goal.\n\n## Predictions\n\nMature data analyses are using predictions to help drive the business forward.\n\nA product manager who can estimate the financial impact, both in cost and potential return, of developing a new feature can make a much stronger case for prioritization than a product manager who has a gut feeling and crossed fingers.\nThe same is true throughout the organization.\nIf the Financial Planning and Analysis team can predict revenue, the Support team can predict hiring requirements to support all customers, and the recruiting team can predict what hiring and onboarding timelines look like for those support engineers.\n\nAn organization that is empowered with the ability to predict performance through advanced analyses is a data-driven organization;\nand, because they have reporting in place to track against those predictions, they have the mechanisms to react with when reality differs from those predictions and can adjust appropriately.\n\n## How do we mature data teams?\n\nI see you nodding your head in agreement.\nHopefully, by now, you've estimated where your team is in this framework, and you're wondering how you can help them move up to the next level.\n\n### Invest in your team\n\nData teams [tend to be 2-8% of your organization](https://blog.getdbt.com/data-team-structure-examples/), and data teams do scale with organization headcount.\nYour data team will fail if you set them up for failure through understaffing.\nThe company will be frustrated with the team and default to the tools they've always known and loved (spreadsheets - and [I hate spreadsheets](https://youtu.be/PLe9sovhtGA?t=1779)).\n\nOnce you're appropriately staffed, make sure your team is using the right tools, technologies, and processes.\nAt GitLab, we firmly believe in [DataOps](https://youtu.be/PLe9sovhtGA) and that [analytics is a subfield of software engineering](https://docs.getdbt.com/docs/viewpoint).\nMany data analysts are coming from old models where version control, the command line, and checking logs are foreign ideas.\nEnsure your team is [using modern technologies](https://meltano.com) and [leveling up along the way](/handbook/business-technology/data-team/learning-library/#data-learning-and-resources).\n\n### Empower everyone in your organization with data\n\nAllow all team members to find and build the reporting they need to do their jobs.\nBy empowering them to self-serve the reporting they need, they can gather their own facts and free up the data team to move into the next tier of analysis.\nAllowing your data team to grow and mature means putting other people in positions to access and analyze the data that they need daily.\n\nAccept that the margin of error is larger on reporting when it's not produced by a member of the data team.\nIt is more important for the data to be directionally correct and accessible than perfect and bottlenecked.\n\nThis does require trusting that reporting is facts.\nData are not opinion-based.\nReporting provides you with the answers and the person or people analyzing can formulate opinions, but reporting itself is not opinionated.\n\n### Speed to Value\n\nThe sooner there is confidence in data and your data organization through reporting, the sooner your team can start providing value through insights.\nPart of how we can implement that speed is by leveraging [open source analytics](/2019/04/15/open-source-analytics/).\nMany data teams are working through the same or similar questions and [open sourcing](/blog/managing-your-snowflake-spend-with-periscope-and-dbt/) and leveraging things like [dbt packages](https://hub.getdbt.com) can help minimize the time spent reinventing the reporting wheel.\n\nThe best practices of software can help make sure a team maintains their velocity.\nThrough data quality and freshness testing, alerting, and documentation through a tool like [dbt](https://www.getdbt.com/product/), data teams can be proactive rather than reactive, setting them up for better success.\n\nData is an incredible tool, but the road to maturity can be bumpy.\nWith a strong team, you can create a data driven organization and quickly find yourself seeing the team's value.\n\n*Special thanks to [Taylor Murphy](https://gitlab.com/tayloramurphy) and [Claire Carroll](https://gitlab.com/clrcrl) for helping me develop my thoughts on the subject and reading early drafts of this framework.*\n",[976,9],{"slug":5837,"featured":6,"template":683},"three-levels-data-analysis","content:en-us:blog:three-levels-data-analysis.yml","Three Levels Data Analysis","en-us/blog/three-levels-data-analysis.yml","en-us/blog/three-levels-data-analysis",{"_path":5843,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5844,"content":5850,"config":5855,"_id":5857,"_type":13,"title":5858,"_source":15,"_file":5859,"_stem":5860,"_extension":18},"/en-us/blog/three-new-support-tools",{"title":5845,"description":5846,"ogTitle":5845,"ogDescription":5846,"noIndex":6,"ogImage":5847,"ogUrl":5848,"ogSiteName":670,"ogType":671,"canonicalUrls":5848,"schema":5849},"We've open sourced 3 tools to help troubleshoot system performance","Say hello to the open source tools our Support team is using to better summarize customer performance data – and find out how they can help you.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670405/Blog/Hero%20Images/open_source_tools.jpg","https://about.gitlab.com/blog/three-new-support-tools","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"We've open sourced 3 tools to help troubleshoot system performance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Will Chandler\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-07-24\",\n      }",{"title":5845,"description":5846,"authors":5851,"heroImage":5847,"date":1770,"body":5853,"category":849,"tags":5854},[5852,675],"Will Chandler","\nOur self-managed customers often encounter issues related to performance, or the time it takes to execute something. In the past, the [Support team](/handbook/support/) had to pull data from disparate sources and cobble it together in order to analyze performance-related issues.\n\n“We’re dealing with someone else’s computer on support, so we have to be able to handle environments with limited observability,” says [Will Chandler](/company/team/#wchandler), senior support engineer. “We’re at the mercy of their infrastructure. That’s why the team has made tools to reduce the friction.”\n\n“With [GitLab.com](/pricing/), we have all of this fancy tooling that helps us collect performance data,” says [Lee Matos](/company/team/#leematos), support engineering manager. “But when we’re working with customers, we need to be ready to bring lightweight tools that don’t require a lot of setup that we can use based on what they have in place.”\n\nThe Support team is working on becoming more data driven by using three new tools designed to aggregate and summarize performance data for self-managed customers. A focus on data-driven decision-making improves the customer relationship and demonstrates our commitment to making performance a key feature of GitLab.\n\nWe'll look at three open source tools created by GitLab Self-Managed Support. Strace parser is a general tool that could be of use to anyone, while JSON Stats and GitLabSOS are tailored to GitLab, but could be easily modified.\n\n## 1. [Strace parser](https://gitlab.com/gitlab-com/support/toolbox/strace-parser)\n\n[Strace](https://gitlab.com/strace/strace) is a commonly used debugging and diagnostic tool in Linux that captures information about what’s happening inside processes running on our customers’ environments.\n\nUnlike [newer](http://man7.org/linux/man-pages/man1/perf.1.html) and [more powerful](https://github.com/iovisor/bpftrace) tracing tools, strace adds [significant overhead to a process](http://www.brendangregg.com/blog/2014-05-11/strace-wow-much-syscall.html). However, strace is generally available even on very old versions of Linux.\n\nAn strace of a single-threaded program is linear, but following the threads of execution quickly gets difficult when there are many processes being captured. At GitLab Support we are typically tracing [Unicorn](https://bogomips.org/unicorn/) workers or [Gitaly](https://gitlab.com/gitlab-org/gitaly), which are highly concurrent, resulting in hundreds of process IDs being traced and hundreds of thousands of lines of output from traces only a few seconds long.\n\nWill built [strace parser](https://gitlab.com/gitlab-com/support/toolbox/strace-parser) for these types of use cases. Strace parser summarizes the most meaningful processing data delivered by an strace in a more accessible format, allowing users to find the critical section sections of the data quickly.\n\nThe next two examples are from a GitLab customer that was using a very slow file system to host their .gitconfig file, which was a major performance bottleneck. But it was not immediately clear what was happening from the perspective of a user trying to troubleshoot. By running an strace on Gitaly, we were able to get a better understanding of why the system was so slow.\n\n```\n3694  13:45:06.207369 clock_gettime(CLOCK_MONOTONIC, {3016230, 201254200}) = 0 \u003C0.000015>\n3694  13:45:06.207409 futex(0x7f645bb49664, FUTEX_WAIT_BITSET_PRIVATE, 192398, {3016230, 299906871}, ffffffff \u003Cunfinished ...>\n3542  13:45:06.209616 \u003C... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) \u003C0.005236>\n3542  13:45:06.209639 futex(0x1084ff0, FUTEX_WAKE, 1) = 1 \u003C0.000023>\n3510  13:45:06.209673 \u003C... futex resumed> ) = 0 \u003C0.002909>\n3542  13:45:06.209701 futex(0xc420896548, FUTEX_WAKE, 1 \u003Cunfinished ...>\n3510  13:45:06.209710 pselect6(0, NULL, NULL, NULL, {0, 20000}, NULL \u003Cunfinished ...>\n16780 13:45:06.209740 \u003C... futex resumed> ) = 0 \u003C0.002984>\n3542  13:45:06.209749 \u003C... futex resumed> ) = 1 \u003C0.000043>\n16780 13:45:06.209776 pselect6(0, NULL, NULL, NULL, {0, 3000}, NULL \u003Cunfinished ...>\n3542  13:45:06.209787 futex(0xc420053548, FUTEX_WAKE, 1 \u003Cunfinished ...>\n16780 13:45:06.209839 \u003C... pselect6 resumed> ) = 0 (Timeout) \u003C0.000056>\n3544  13:45:06.209853 \u003C... futex resumed> ) = 0 \u003C0.003148>\n3542  13:45:06.209861 \u003C... futex resumed> ) = 1 \u003C0.000069>\n3510  13:45:06.209868 \u003C... pselect6 resumed> ) = 0 (Timeout) \u003C0.000151>\n3544  13:45:06.209915 epoll_ctl(4\u003Canon_inode:[eventpoll]>, EPOLL_CTL_DEL, 181\u003CUNIX:[164869291]>, 0xc42105bb14 \u003Cunfinished ...>\n16780 13:45:06.210076 write(1\u003Cpipe:[55447]>, \"time=\\\"2019-02-14T18:45:06Z\\\" level=warning msg=\\\"health check failed\\\" error=\\\"rpc error: code = DeadlineExceeded desc = context deadline exceeded\\\" worker.name=gitaly-ruby.4\\n\", 170 \u003Cunfinished ...>\n3544  13:45:06.210093 \u003C... epoll_ctl resumed> ) = 0 \u003C0.000053>\n3542  13:45:06.210101 futex(0x1089020, FUTEX_WAIT, 0, {0, 480025102} \u003Cunfinished ...>\n3510  13:45:06.210109 pselect6(0, NULL, NULL, NULL, {0, 20000}, NULL \u003Cunfinished ...>\n16780 13:45:06.210153 \u003C... write resumed> ) = 170 \u003C0.000064>\n3544  13:45:06.210163 close(181\u003CUNIX:[164869291]> \u003Cunfinished ...>\n```\n\nThis strace delivers more than 300,000 lines about the different Gitaly processes running on this customer’s GitLab environment, making it challenging to decipher the flow of execution.\n{: .note.text-center}\n\n“In this case, we can use strace-parser to say, ‘Just give me all the files that were opened, and sort them by how long it took to open,’” says Will.\n\n```\n$ strace-parser trace.txt files --sort duration\n\nFiles Opened\n\n      pid      dur (ms)       timestamp            error         file name\n  -------    ----------    ---------------    ---------------    ---------\n    24670      5203.999    13:45:16.152985           -           /efs/gitlab/home/.gitconfig\n    24859      5296.580    13:45:23.367482           -           /efs/gitlab/home/.gitconfig\n    24584      5279.810    13:45:09.286019           -           /efs/gitlab/home/.gitconfig\n    24666      5276.975    13:45:16.079697           -           /efs/gitlab/home/.gitconfig\n    24667      5255.649    13:45:16.101009           -           /efs/gitlab/home/.gitconfig\n    14871      2594.364    13:45:18.762347           -           /efs/gitlab/home/.gitconfig\n    24885      2440.635    13:45:26.224189           -           /efs/gitlab/home/.gitconfig\n    24886      2432.980    13:45:26.231009           -           /efs/gitlab/home/.gitconfig\n    24656        55.873    13:45:15.916836        ENOENT         /nfs/gitlab/gitdata/repositories/group/project.git/objects/info/alternates\n    24688        42.764    13:45:21.522789        ENOENT         /nfs/gitlab/gitdata/repositories/group/project.git/objects/info/alternates\n     3709        39.631    13:45:07.816618           -           /efs/gitlab/home/.gitconfig\n    24583        37.959    13:45:09.218283           -           /efs/gitlab/home/.gitconfig\n```\n\nBy summarizing the data in this way, we see multiple files that took 2-5 seconds to open, which is several orders of magnitude slower than expected.\n{: .note.text-center}\n\n“If it’s a particularly busy server and we’re performing these actions 50 times a second, 100 times a second, that adds up really fast,” says Will. “Strace-Parser lets you drill down quickly, and say, ‘OK, this specific thing we’re doing is super slow.’”\n\n### Get a closer look at processes using strace-parser\n\nStrace-Parser can also be used to drill down into details of a process.\n\nThe previous output showed PID 24670 is one of the slower processes, so we use the parser to understand how this slow call impacted the performance of the process overall.\n\n```\n$ strace-parser trace.txt pid 24670\n\nPID 24670\n\n  271 syscalls, active time: 5303.438ms, user time: 34.662ms, total time: 5338.100ms\n  start time: 13:45:16.116671    end time: 13:45:21.454771\n\n  syscall                 count    total (ms)      max (ms)      avg (ms)      min (ms)    errors\n  -----------------    --------    ----------    ----------    ----------    ----------    --------\n  open                       29      5223.073      5203.999       180.106         0.031    ENOENT: 9\n  read                       25        46.303        28.747         1.852         0.031\n  access                     11         6.948         4.131         0.632         0.056    ENOENT: 3\n  lstat                       6         5.116         2.130         0.853         0.077    ENOENT: 4\n  mmap                       32         3.868         0.485         0.121         0.028\n  openat                      2         3.757         2.934         1.878         0.823\n  fstat                      28         3.395         0.272         0.121         0.033\n  munmap                     11         2.551         0.929         0.232         0.056\n  rt_sigaction               59         2.548         0.121         0.043         0.024\n  close                      22         2.375         0.279         0.108         0.032\n  mprotect                   14         0.927         0.174         0.066         0.032\n  execve                      1         0.621         0.621         0.621         0.621\n  brk                         6         0.595         0.210         0.099         0.046\n  stat                        8         0.388         0.082         0.048         0.027    ENOENT: 3\n  getdents                    4         0.361         0.138         0.090         0.044\n  rt_sigprocmask              3         0.141         0.059         0.047         0.040\n  write                       1         0.101         0.101         0.101         0.101\n  dup2                        3         0.090         0.032         0.030         0.026\n  arch_prctl                  1         0.077         0.077         0.077         0.077\n  getrlimit                   1         0.062         0.062         0.062         0.062\n  getcwd                      1         0.044         0.044         0.044         0.044\n  set_robust_list             1         0.035         0.035         0.035         0.035\n  set_tid_address             1         0.032         0.032         0.032         0.032\n  setpgid                     1         0.030         0.030         0.030         0.030\n  ---------------\n\n  Program Executed: /opt/gitlab/embedded/bin/git\n  Args: [\"--git-dir\" \"/nfs/gitlab/gitdata/repositories/group/project.git\" \"cat-file\" \"--batch-check\"]\n\n  Parent PID:  3563\n\n  Slowest file open times for PID 24670:\n\n    dur (ms)       timestamp            error         file name\n  ----------    ---------------    ---------------    ---------\n    5203.999    13:45:16.152985           -           /efs/gitlab/home/.gitconfig\n       5.420    13:45:16.143520           -           /nfs/gitlab/gitdata/repositories/group/project.git/config\n       2.959    13:45:21.372776           -           /efs/gitlab/home/.gitconfig\n       2.934    13:45:21.401073           -           /nfs/gitlab/gitdata/repositories/group/project.git/refs/\n       2.736    13:45:21.417333        ENOENT         /nfs/gitlab/gitdata/repositories/group/project.git/info/grafts\n       2.683    13:45:21.421558           -           /nfs/gitlab/gitdata/repositories/group/project.git/objects/b7/ef5eba3a425af1e2a9cf6f51cb87454b6e1ad1\n       2.430    13:45:21.407170        ENOENT         /nfs/gitlab/gitdata/repositories/group/project.git/objects/info/alternates\n       0.992    13:45:21.420213        ENOENT         /nfs/gitlab/gitdata/repositories/group/project.git/shallow\n       0.823    13:45:21.405535           -           /nfs/gitlab/gitdata/repositories/group/project.git/objects/pack\n       0.275    13:45:21.380382           -           /nfs/gitlab/gitdata/repositories/group/project.git/config\n```\n\nThe output shows the time this process spent working was dominated by the slow file open. This data points the Support team in the right direction for fixing the underlying issue.\n{: .note.text-center}\n\nStrace itself has the `-c` flag which provides a similar summary, but its utility is limited when multiple processes are traced as it cannot break out per-process statistics.  Strace-Parser breaks these down to the PID level, and can also include the details of parent and child processes on demand.\n\n“In this case Will has identified an interesting area for our customer and then very quickly anchored it in the fact that when we look at that one spot it was slow,” says Lee. “When we’re debugging, having this data available really helps us pinpoint the problem for our customers so we can give them answers.”\n\nThe typical GitLab deployment has many different processes and services running at a time, which can create dozens of different child processes, so there is a large surface area for potential errors or slowness to occur.\n\nStrace-Parser is an open source, generic tool that anyone can use to better understand their strace data.\n\n## 2. [JSON Stats](https://gitlab.com/gitlab-com/support/toolbox/json_stats)\n\nWill also built [JSON Stats](https://gitlab.com/gitlab-com/support/toolbox/json_stats), a script that pulls performance statistics for different logs from the customer’s GitLab environment and summarizes the results in an easy-to-interpret table.\n\n```\nMETHOD                             COUNT     RPS     PERC99     PERC95     MEDIAN         MAX        MIN          SCORE    % FAIL\nFetchRemote                         2542    0.17  962176.08  130154.88   36580.23  4988513.00    1940.45  2445851585.19      1.06\nFindAllTags                         5200    0.34   30000.37   11538.63    1941.84    30006.23     252.10   156001924.68      1.63\nFindCommit                          3506    0.23   20859.98   16622.78   10841.86    30001.59    2528.67    73135073.75      0.23\nFindAllRemoteBranches               1664    0.11   20432.93   12996.75    8606.60   405503.94    1430.84    34000396.10      0.00\nAddRemote                           2603    0.17   10001.03    8094.97     825.46    10007.46     228.13    26032673.70      3.00\nFindLocalBranches                   2535    0.16   10004.68   10002.90    9051.91    10036.16    1260.89    25361871.05     34.32\n```\n\nThis output shows that we’re calling the “FindLocalBranches” service 2500+ times, and it’s failing 34% of the time.\n{: .note.text-center}\n\nThe Support team can use JSON Stats to ground their findings in evidence when evaluating overall performance for a customer. It's the same concept as strace-parser. Can we pivot the information in a way that it clearly becomes meaningful data?\n\n“It’s a quick way of extracting data that you can give to a customer. Instead of saying ‘Look, this failed once,’ we can say, ‘Look, this is failing a third of the time and that suggests there’s a problem with X,’” says Will.\n\nIn the sample output we see that JSON Stats is working with Gitaly logs, but the tool is nimble enough to work on the logs from all the heavy components of GitLab, including Rails, which runs the UI, and Sidekiq, which works on background tasks.\n\n“Some of our customers are very sophisticated and may have advanced monitoring that could give us this information. But we wanted to build a tool that would help us align and easily standardize on how we can get this performance information for customers that don’t have an advanced monitoring setup,” says Lee.\n\nWhile this specific tool isn't as helpful for people outside of the GitLab community, hopefully it helps to inspire others to consider how they are drawing conclusions, and how they can speed that process up.\n\n### Benchmarking with JSON Stats\n\nWill is building a future iteration of JSON Stats that will compare the performance of a customer’s GitLab instance with GitLab.com.\n\n![JSON benchmarking table](https://about.gitlab.com/images/blogimages/support-tools-update.png){: .shadow}\n\nBenchmarking the performance of GitLab.com (the first row) with the customer environment (second row), and the ratio between the two (third row). We can see that in the worst case, the customer’s 99th percentile FindCommit latency was almost eight times slower than it was on GitLab.com.\n{: .note.text-center}\n\n“Our vision here is to give accountability to our customers. We’re going to treat GitLab.com as the pinnacle experience for GitLab,” says Lee. “We want to use JSON Stats with benchmarking to help us understand how far away our customers are from GitLab.com.”\n\nLee and Will are still assessing how to set the target range for the customer’s instance of GitLab. But considering the wealth of resources allocated to GitLab.com, any self-managed customer that is performing within 5-10% of GitLab.com would be considered hugely successful.\n\n## 3. [GitLab SOS](https://gitlab.com/gitlab-com/support/toolbox/gitlabsos)\n\nWhen a customer encounters an issue, but they are unsure of what they problem is, they can run [GitLab SOS](https://gitlab.com/gitlab-com/support/toolbox/gitlabsos), created by support engineer [Cody West](/company/team/#codyww), to create a snapshot of different activities happening on their system. It's been so helpful in debugging GitLab that it's being added into our [Omnibus delivery](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/3430).\n\nBy capturing so much data about a moment in time during or shortly after encountering a problem, the support team is able to work asynchronously to troubleshoot on behalf of the customer.\n\n```\ncpuinfo              getenforce           iotop                netstat              opt                  sestatus             unicorn_stats\ndf_h                 gitlab_status        lscpu                netstat_i            pidstat              systemctl_unit_files uptime\ndmesg                gitlabsos.log        meminfo              nfsiostat            ps                   tainted              var\netc                  hostname             mount                nfsstat              sar_dev              ulimit               vmstat\nfree_m               iostat               mpstat               ntpq                 sar_tcp              uname\n```\n\nGitLab SOS works best if the script is run while an issue is occurring, or moments after, but even if the window of opportunity is missed you can still successfully gather information to diagnose the problem.\n{: .note.text-center}\n\n“If a customer is sharp, they may know what problems to look for already,” says Lee. “But if a customer is scared and they don’t know what to look for, then they can lean on a tool like GitLab SOS and learn from GitLab SOS. We even have some sharp customers that will generate the SOS output and begin to troubleshoot themselves because of the comprehensive overview it provides.”\n\n## These new tools drive data-driven decision-making in Support\n\nTools like strace-parser, JSON Stats, and GitLab SOS provide the Support team and GitLab customers with critical evidence about performance. By letting the data drive decision-making, the Support team is able to identify problems faster and quickly start debugging customer environments. Performance is a key feature of GitLab, and by filling our toolbox with data-driven solutions we can ensure greater [transparency](https://handbook.gitlab.com/handbook/values/#transparency) between GitLab and our customers.\n\nLearn more about debugging from a support engineering perspective in a GitLab Unfiltered video.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/9W6QnpYewik\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nCover photo by [Diogo Nunes](https://unsplash.com/@dialex?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/tools?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1187,9,680],{"slug":5856,"featured":6,"template":683},"three-new-support-tools","content:en-us:blog:three-new-support-tools.yml","Three New Support Tools","en-us/blog/three-new-support-tools.yml","en-us/blog/three-new-support-tools",{"_path":5862,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5863,"content":5869,"config":5874,"_id":5876,"_type":13,"title":5877,"_source":15,"_file":5878,"_stem":5879,"_extension":18},"/en-us/blog/three-steps-to-optimize-software-value-streams",{"title":5864,"description":5865,"ogTitle":5864,"ogDescription":5865,"noIndex":6,"ogImage":5866,"ogUrl":5867,"ogSiteName":670,"ogType":671,"canonicalUrls":5867,"schema":5868},"GitLab's 3 steps to optimizing software value streams","Discover the power of GitLab Value Streams Dashboard (VSD) for optimizing software delivery workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667893/Blog/Hero%20Images/workflow.jpg","https://about.gitlab.com/blog/three-steps-to-optimize-software-value-streams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab's 3 steps to optimizing software value streams\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2023-06-26\",\n      }",{"title":5864,"description":5865,"authors":5870,"heroImage":5866,"date":5871,"body":5872,"category":1513,"tags":5873},[2014],"2023-06-26","\n\n\u003Ci>This is part three of our multipart series introducing you to the capabilities within GitLab Value Stream Management and the Value Streams Dashboard. In part one, [learn about the Total Time Chart](https://about.gitlab.com/blog/value-stream-total-time-chart/) and how to simplify top-down optimization flow with Value Stream Management. In part two, learn how to [get started with the Value Streams Dashboard](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/). \u003C/i>\n\nIt’s no news that software development is a complex process that involves many different stages, teams, and tools. With significant investments made in digital transformation and adopting new tools following the shift to remote work, measuring and managing the business value of the software development lifecycle (SDLC) have become more complex.\n\nThis is where Value Stream Management (VSM) comes in. VSM is a methodology that helps organizations optimize their software delivery process by visualizing, measuring, and improving the flow of value (a.k.a. the “value stream”) from ideation to production. Some examples are: the amount of time it takes to go from an idea to production, the velocity of the project, bottlenecks in the development process, and long-running issues or merge requests. As you’ve probably guessed from its title, this blog will cover how the [new capabilities of GitLab Value Streams Dashboard](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#value-streams-dashboard-is-now-generally-available) can help you do all that, and optimize your software delivery.\n\n## Value Stream Management in a nutshell \nGitLab [VSM](https://about.gitlab.com/solutions/value-stream-management/) provides end-to-end visibility into your software delivery process. It enables you to [map out your value stream](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#create-a-value-stream-with-custom-stages), identify bottlenecks, measure key metrics, and identify the places where you are either lagging or doing exceptionally well. It then also allows you to take action on these insights. In essence, GitLab VSM helps you to understand and optimize your development processes to deliver software faster and better.\n\n![GitLab Value Stream Analytics](https://about.gitlab.com/images/blogimages/2023-05-24-vsm-overview.png){: .shadow}\nWith Value Stream Analytics, you can establish a baseline for measuring software delivery performance progress and identifying the touchpoints in the process that do not add value to the customer or your business.\n{: .note.text-center}\n\nAnd if you’re wondering how GitLab VSM is able to do that, it’s because GitLab provides an entire DevSecOps platform as a single application and, therefore, holds all the data needed to provide end-to-end visibility throughout the entire SDLC. So now, your decisions rely on actual data rather than blind estimation or gut feelings. Additionally, since GitLab is the place where work happens, these insights are also actionable, allowing your users to move from “understanding” to “fixing” at any time, from within their workflow and without losing context.\n\n## How VSM works: The three-step analysis\nLet’s take a look at how GitLab VSM helps you optimize your SDLC in three easy steps:\n\n**Step 1:** Get an end-to-end view across your entire organization and pinpoint the value streams you need to focus on.\n\nThe [Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html) is a centralized view where you can see and compare all of the SDLC metrics of all your organization's projects. This dashboard enables you to identify hotspots in your SDLC streams — projects or teams that are underperforming, with longer stages and cycle times. It also shows you where you have the largest value contributors, so you can identify and learn what is working well and what's not. With this information at hand, you can now prioritize your efforts and understand where to spend your time.\n\n![VSM illustration](https://about.gitlab.com/images/blogimages/2023-05-24_vsm1.gif){: .shadow}\n\n\nThis centralized UI acts as a single source of truth for your organization, where all the relevant stakeholders can access, view, and analyze the same set of metrics. This ensures everyone is on the same page, promoting consistency in analysis and decision-making.\n\nRead more: [Getting started with the new GitLab Value Streams Dashboard](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n\n**Step 2:** Drill down into a specific project.\n\nWhen you select a project from the main dashboard, you are directed to that project's Value Stream Analytics (VSA), where you see its value stream. The project's metrics are presented for each stage of the project, helping you understand where the main work lies and which stages need improvement. The VSA overview provides valuable insights into lead times, cycle times, and other critical metrics that help you identify areas for optimization.\n\n![VSM illustration](https://about.gitlab.com/images/blogimages/2023-05-24_vsm2.gif){: .shadow}\n\n\nRead more: [Value stream management: Total Time Chart simplifies top-down optimization flow](https://about.gitlab.com/blog/value-stream-total-time-chart/)\n\n**Step 3:** Dive deep into the Value Stream Analytics dashboard to analyze and fix issues.\n\nOnce the main areas of interest are identified, GitLab Value Stream Analytics (VSA) enables you to drill down further into a specific stage of the project. In the stage table, you can sort the **Last event** column to view the most recent workflow event, and sort the items by **duration** so you can rearrange the events and gain insights faster. This way, you can easily detect work items that are slowing down the project in that stage. Here's an example how we dogfood [VSA on gitlab-org](https://gitlab.com/gitlab-org/gitlab/-/value_stream_analytics). \n\nYou can identify the owner of the work items responsible for the delays, examine code changes, and perform a comprehensive analysis of the issue. This level of visibility and traceability empowers you to take targeted actions and make the necessary improvements to optimize the value stream, all within the context of your current workflow.\n\n![VSM illustration](https://about.gitlab.com/images/blogimages/2023-05-24_vsm3.gif){: .shadow}\nUse GitLab Value Stream Management to visualize the progress of work from planning to value delivery, and gain actionable context.\n{: .note.text-center}\n\n## The value of Value Stream Management\nGitLab VSM is a powerful solution that fits seamlessly into your SDLC. By providing end-to-end visibility and granular, actionable insights into the value stream, VSM enables you to optimize your software delivery and provide value to your customers faster. Access the information you need, when you need it — and easily act on it from within your workplace. VSM offers you the best of both worlds: out-of-the-box functionality and the ability to customize features.\n\nSay goodbye to time-consuming searches and hello to instant access to the information you need most. To learn more, check out the [Value Stream Analytics documentation](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html).\n\nTo help us improve the Value Stream Management, please share feedback about your experience in this [survey](https://gitlab.fra1.qualtrics.com/jfe/form/SV_50guMGNU2HhLeT4).\n",[1164,851,9,2018,894],{"slug":5875,"featured":6,"template":683},"three-steps-to-optimize-software-value-streams","content:en-us:blog:three-steps-to-optimize-software-value-streams.yml","Three Steps To Optimize Software Value Streams","en-us/blog/three-steps-to-optimize-software-value-streams.yml","en-us/blog/three-steps-to-optimize-software-value-streams",{"_path":5881,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5882,"content":5887,"config":5893,"_id":5895,"_type":13,"title":5896,"_source":15,"_file":5897,"_stem":5898,"_extension":18},"/en-us/blog/three-things-you-might-not-know-about-gitlab-security",{"title":5883,"description":5884,"ogTitle":5883,"ogDescription":5884,"noIndex":6,"ogImage":5482,"ogUrl":5885,"ogSiteName":670,"ogType":671,"canonicalUrls":5885,"schema":5886},"Three things you might not know about GitLab security","There's so much more to GitLab's security offering than meets the eye. Here are three features you may have missed.","https://about.gitlab.com/blog/three-things-you-might-not-know-about-gitlab-security","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Three things you might not know about GitLab security\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Wilson\"}],\n        \"datePublished\": \"2021-11-23\",\n      }",{"title":5883,"description":5884,"authors":5888,"heroImage":5482,"date":5890,"body":5891,"category":704,"tags":5892},[5889],"Matt Wilson","2021-11-23","\n\nOver the past couple of years, our users have come to know and regularly use our many security features that are part of the [Secure](/stages-devops-lifecycle/secure/) and [Protect](/stages-devops-lifecycle/govern/) stages. We have seen success stories from customers who have improved their security postures by reducing vulnerabilities in application code. One thing that surprises me when I speak to our users is that many aren’t aware of some of our most useful features. Here are three things you really should know about GitLab’s capabilities that will help take your security game to the next level.\n\n## We have a GraphQL API!\n\nGitLab has long offered a [REST API](https://docs.gitlab.com/ee/api/api_resources.html). It is quite capable but when it comes to vulnerability management, it is limited in what you can do. Our [GraphQL API](https://docs.gitlab.com/ee/api/graphql/index.html) is newer and is the area of focus for new API development. Vulnerability management in particular has quite an extensive feature set in the GraphQL API. Whether you are looking to build task automation, create custom reports, or pull in vulnerability data from external sources, GraphQL is your go to resource.\n\nBringing in vulnerability data from outside GitLab is a new capability worth calling extra attention to. You can use GraphQL to [directly create vulnerability records](https://docs.gitlab.com/ee/api/graphql/reference/#mutationvulnerabilitycreate) on projects. This is great for migrating vulnerability data from other systems, creating integrations with a bug bounty program, or even bringing in results from security tools that don’t run in GitLab pipeline jobs. I’m sure our users will come up with many more creative use cases. Even better, these vulnerability records show up in [Vulnerability Reports](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) and [Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) just like results from any of our many included security scanners.\n\n## Security approvals help stop new vulnerabilities\n\nA primary goal of any application security program is to reduce risk by keeping vulnerabilities out of deployed code. One of the best ways to do this is by preventing new vulnerabilities from getting into your main branch in the first place. Scanning feature branches on every commit is a recommended practice many of our customers employ. But it’s how to keep vulnerability findings from being merged where I see a lot missing out on a power feature that can help.\n\nI commonly see pipelines configured to block or fail if any security scan jobs detect a potential vulnerability in new code. While this approach is effective in keeping new vulnerabilities from being merged, it can be more disruptive and less efficient for developers and AppSec teams. Instead, we recommend using [security approvals in merge requests](https://docs.gitlab.com/ee/user/application_security/index.html#security-approvals-in-merge-requests). Like normal MR approval rules, you first specify one or more individuals that will be part of the security approval group. Members of security approval groups don’t even need to have merge rights to the project so you can have [segregation of duties](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties). You then configure the detection rule to set the number of approvals required, severity levels that trigger the approval and even which scanners the rule applies to. And while you are setting up your approval rules, consider enabling the setting that [prevents merge approvals by the MR author](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#prevent-approval-by-author) for further segregation of duties.\n\nSecurity approval rules are great for a few reasons. First, you can more quickly enable and configure them on a project than custom pipeline behaviors. Also, only project owners and maintainers are able to access and modify these approvals. Contrast this with pipelines where anyone with the developer role can change pipeline configurations by default. Security approvals are also more visible and collaborative. When a pipeline is blocked or fails, the developer must navigate into the pipeline and try to figure out what failed by reading the job output. When a security approval is triggered, it will clearly show on the MR that merging is blocked until the flagged vulnerabilities are removed or approval is provided from the required number of security approvers. And because you can see any [scanner findings on the MR](https://docs.gitlab.com/ee/user/application_security/index.html#ultimate), developers can not only quickly investigate these potential vulnerabilities, they can also add comments and communicate with the security team. Best of all, developers can simply fix any findings that would require approval. Once the security scans no longer detect the violations, merging is immediately possible again.\n\n## Compliance pipelines enforce security hygiene\n\nLast but certainly not least is the newest of these three features: [compliance pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration). Have you ever wanted to make sure your code branches are properly scanned for vulnerabilities but you were having trouble auditing and enforcing it? Compliance pipelines to the rescue! Compliance pipelines allow group owners to add an additional pipeline configuration to projects. These configurations are combined with any existing configurations for the project pipeline. Compliance pipeline configurations are evaluated before any project configurations meaning they can override any values in the project pipeline. This is a powerful tool for automatically enforcing compliance with various regulatory and private industry standards as well as any internal company policies.\n\nCompliance pipelines work best when combined with [compliance frameworks](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-frameworks). Compliance frameworks allow group owners to specify the location of a compliance pipeline configuration. The configuration can be stored and managed in a dedicated project with restricted access. Special compliance framework labels are created which can then be applied by the group owner to any projects within the group. This label is what tells a project’s pipeline to pull in the associated compliance pipeline configuration. For example, you might create a PCI compliance label. You then simply apply the label to any projects within the scope of PCI such as any that process or store customer information and payment details.\n\nContinuing with our PCI example, you can enforce code scanning with these two features in place. Simply create a compliance pipeline configuration with the desired scanners included such as SAST and Secret Detection. Be sure the configuration file is in a project with access granted only to those users who should have permissions to modify it. Then, edit your PCI compliance label in your group settings and point it to the compliance pipeline configuration. You can even allow compliance job values to be settable at the project level. This means you can, for example, ensure a SAST job runs but leave room to select the right language-specific analyzers for a particular project’s codebase. Even better, [use GraphQL to quickly apply compliance labels](https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationprojectsetcomplianceframework) to multiple projects.\n\n## Wrapping it up\n\nWith so many features in a single platform, it is easy to overlook some. The ones I’ve shared are only a few of the many security-related features GitLab includes. They are also important to know about because of the additional flexibility and control they offer in addition to our comprehensive security scanning capabilities. I hope you’ve found at least one new idea to add to your security toolbelt.\n",[851,704,9],{"slug":5894,"featured":6,"template":683},"three-things-you-might-not-know-about-gitlab-security","content:en-us:blog:three-things-you-might-not-know-about-gitlab-security.yml","Three Things You Might Not Know About Gitlab Security","en-us/blog/three-things-you-might-not-know-about-gitlab-security.yml","en-us/blog/three-things-you-might-not-know-about-gitlab-security",{"_path":5900,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5901,"content":5907,"config":5912,"_id":5914,"_type":13,"title":5915,"_source":15,"_file":5916,"_stem":5917,"_extension":18},"/en-us/blog/tips-for-managing-monorepos-in-gitlab",{"title":5902,"description":5903,"ogTitle":5902,"ogDescription":5903,"noIndex":6,"ogImage":5904,"ogUrl":5905,"ogSiteName":670,"ogType":671,"canonicalUrls":5905,"schema":5906},"5 Tips for managing monorepos in GitLab","Learn the benefits of operating a monolothic repository and how to get the most out of this structure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667591/Blog/Hero%20Images/code-review-blog.jpg","https://about.gitlab.com/blog/tips-for-managing-monorepos-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Tips for managing monorepos in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah Waldner\"}],\n        \"datePublished\": \"2022-07-12\",\n      }",{"title":5902,"description":5903,"authors":5908,"heroImage":5904,"date":5909,"body":5910,"category":849,"tags":5911},[2294],"2022-07-12","\nGitLab was founded 10 years ago on Git because it is the market leading version control system. As [Marc Andressen pointed out in 2011](https://www.wsj.com/articles/SB10001424053111903480904576512250915629460), we see teams and code bases expanding at incredible rates, testing the limits of Git. Organizations are experiencing significant slowdowns in performance and added administration complexity working on enormous repositories or monolithic repositories. \n\n## Why do organizations develop on monorepos? \n\nGreat question. While [some](https://www.infoworld.com/article/3638860/the-case-against-monorepos.html) might believe that monorepos are a no-no, there are valid reasons why companies, including  Google or GitLab (that’s right! We operate a monolithic repository), choose to do so. The main benefits are: \n\n- Monorepos can reduce silos between teams, streamlining collaboration on design, development, and operation of different services because everything is within the same repository.\n- Monorepos help organizations standardize on tooling and processes. If a company is pursuing a DevOps transformation, a monorepo can help accelerate change management when it comes to new workflows or the rollout of new tools.\n- Monorepos simplify dependency management because all packages can be updated in a single commit.\n- Monorepos offer unified CI/CD and build processes. Having all services in a single repository means that you can set up one system of pipelines for everyone.\n\nWhile we still have a ways to go before monorepos or monolithic repositories are as easy to manage as multi-repos in GitLab, we put together five tips and tricks to maintain velocity while developing on a monorepo in GitLab.\n\n**1. Use CODEOWNERS to streamline merge request approvals**\n\nCODEOWNERS files live in the repository and assign an owner to a portion of the code, making it super efficient to process changes. Investing time in setting up a robust [CODEOWNERS file](https://docs.gitlab.com/ee/user/project/codeowners/) that you can then use to automate [merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) from required people will save time down the road for developers. \n\nYou can then set your merge requests so they must be approved by Code Owners before merge. CODEOWNERS specified for the changed files in the merge request will be automatically notified.\n\n**2. Improve git operation performance with Git LFS**\n\nA universal truth of git is that managing large files is challenging. If you work in the gaming industry, I am sure you’ve been through the annoying process of trying to remove a binary file from the repository history after a well-meaning coworker committed it. This is where [Git LFS](https://docs.gitlab.com/ee/topics/git/lfs/#git-large-file-storage-lfs) comes in. Git LFS keeps all the big files in a different location so that they do not exponentially increase the size of a repository.\n\nThe GitLab server communicates with the Git LFS client over HTTPS. You can enable Git LFS for a project by toggling it in [project settings](https://docs.gitlab.com/ee/user/project/settings/index.html#configure-project-visibility-features-and-permissions). All files in Git LFS can be tracked in the GitLab interface. GitLab indicates what files are stored there with the LFS icon.\n\n**3. Reduce download time with partial clone operations**\n\n[Partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html#partial-clone) is a performance optimization that allows Git to function without having a complete copy of the repository. The goal of this work is to allow Git to better handle extremely large repositories.\n\nAs we just talked about, storing large binary files in Git is normally discouraged, because every large file added is downloaded by everyone who clones or fetches changes thereafter. These downloads are slow and problematic, especially when working from a slow or unreliable internet connection.\n\nUsing partial clone with a file size filter solves this problem, by excluding troublesome large files from clones and fetches. \n\n**4. Take advantage of parent-child pipelines**\n\n[Parent-child pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) are where one pipeline triggers a set of downstream pipelines in the same project. The downstream pipelines still execute in the same stages or sequence without waiting for other pipelines to finish. Additionally, child pipelines reduce the configuration to the child pipeline, making it easier to interpret and understand. For monorepos, using parent-child pipelines in conjunction with `rules:changes` will only run pipelines on specified files changes. This reduces wasted time running pipelines across the entire repository.  \n\n**5. Use incremental backups to eliminate downtime** \n\n[Incremental backups](https://docs.gitlab.com/ee/raketasks/backup_restore.html#incremental-repository-backups) can be faster than full backups because they only pack changes since the last backup into the backup bundle for each repository. This is super useful when you are working on a large repository and only developing on certain parts of the code base at a time.\n\n## Where we are headed\n\nWhile these tips have helped many customers migrate from other version control systems to GitLab, we know there is still room for improvement. Over the next year, you will see us working on the following projects. We’d LOVE to hear from you, so share your thoughts, ideas, or simply 👍 on an issue to help prioritize things that will make your life easier.\n\n- [Git for enormous repositories](https://gitlab.com/groups/gitlab-org/-/epics/773)\n- [Expand SAST scanner support for monorepos](https://gitlab.com/groups/gitlab-org/-/epics/4895)\n- [Allow Reports to be Namespace to support monorepos](https://gitlab.com/gitlab-org/gitlab/-/issues/299490)\n",[851,9,2018,701,894],{"slug":5913,"featured":6,"template":683},"tips-for-managing-monorepos-in-gitlab","content:en-us:blog:tips-for-managing-monorepos-in-gitlab.yml","Tips For Managing Monorepos In Gitlab","en-us/blog/tips-for-managing-monorepos-in-gitlab.yml","en-us/blog/tips-for-managing-monorepos-in-gitlab",{"_path":5919,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5920,"content":5925,"config":5931,"_id":5933,"_type":13,"title":5934,"_source":15,"_file":5935,"_stem":5936,"_extension":18},"/en-us/blog/tips-for-working-from-home-remote-work",{"title":5921,"description":5922,"ogTitle":5921,"ogDescription":5922,"noIndex":6,"ogImage":1825,"ogUrl":5923,"ogSiteName":670,"ogType":671,"canonicalUrls":5923,"schema":5924},"How to live your best remote life","GitLab team members offer their best advice on working from home (and it might surprise you).","https://about.gitlab.com/blog/tips-for-working-from-home-remote-work","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to live your best remote life\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jarka Košanová et al\"}],\n        \"datePublished\": \"2019-07-09\",\n      }",{"title":5921,"description":5922,"authors":5926,"heroImage":1825,"date":5928,"body":5929,"category":996,"tags":5930},[5927],"Jarka Košanová et al","2019-07-09","\nIf there’s one thing GitLab team members ought to be experts at by now it’s [how to work from home](/company/culture/all-remote/).\n\nThat’s why we asked for your single best [work-from-home](/blog/eliminating-distractions-and-getting-things-done/) tip. The answers – involving cars, snacks, clothing, exercise, and the importance of a closed door – just might surprise you.\n\n## The definition of done\n\nThis well-known software development concept applies equally to working at home. [Jarka Košanová](/company/team/#jajina_k), backend engineer, stresses the importance of flexibility when it comes to deciding when to end the work day. “Many people who start working remotely have a problem recognizing they should stop working for the day. It is easy to advise setting a time when you finish your work in the same way as if you were in an office. But then you kind of lose the flexibility working from home is about. What helped me was my husband returning home from his work. If I had a day without any big break I knew it was time to finish my work as well. If I had a day with a break, I knew, on the other hand, I still could work a bit more and it would be ok.”\n\n## Start your engines\n\nIf you’ve been used to a commute as the first part of your day, this tip senior content editor [Valerie Silverthorne](/company/team/#valsilverthorne) borrowed from a friend is for you. “A work-at-home friend starts his day off by jumping in his car and driving around his neighborhood. When he pulls back in to his driveway, his ‘commute’ is complete and he’s ready to start his day.”\n\nOthers at GitLab have their own, perhaps more carbon-friendly, versions of this ritual. [Daniel Gruesso](/company/team/#danielgruesso), Configure product manager, has a good plan that involves a different kind of locomotion. “Getting out of the house before I start my day is very important for me. Either walking the dog or going for a swim to clear my head and get the blood flowing.”\n\n## Literally dressing for success\n\n### No PJs\n\nClothes make the person, even, apparently, in a work-from-home culture. No PJs for Secure frontend engineer [Sam Beckham](/company/team/#samdbeckham), at least. His top tip: “Getting dressed. It might be tempting to work in your pyjamas all day (and I occasionally still do) but getting dressed and presenting yourself as if you were to be going to an office job can go a long way towards getting you into a working mindset.”\n\n### Dress comfy\n\nOf course, there’s dressed, and then there’s dressed up, which is a significant difference according to [Heather Simpson](/company/team/#Heatherswall), senior external communications analyst, Security. “(I) agree, getting dressed is crucial for me… although I appreciate the attire I feel comfortable with wearing here at GitLab vs at my old company (where I worked remotely for 10 years). I now feel completely comfortable in a hoodie.”\n\n### Have a uniform\n\nContent marketing associate [Suri Patel](/company/team/#suripatel) takes a different tack with her clothing. She’s assembled a work uniform that draws a distinct line between time on and time off. “I have a hard time not thinking about work after I close my computer, so I have 10 black shirts (they were on sale), specific sweaters, and trousers that I only wear while working. The last thing I want to do is pair my favorite dress with a stressful project and be reminded of that while at the beach.”\n\n## A routine routine\n\nWe know we like [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions) and a lot of us really like/need/want a routine, particularly when it comes to working from home. [Carol Wainana](/company/team/#carowangar), service support agent, likes a routine. “Having a fixed routine that is time to wake up, time to start working, time for lunch and time to log off has been really beneficial for me.” And Heather agrees. “For me, a routine is helpful too – I start my day with coffee and checking out Twitter for interesting articles to read and/or share. This eases me into the day but still helps me stay informed and able to share thoughtful articles, etc., on the regular (mostly).”\n\nBut a routine doesn’t necessarily work for everyone, as [Tanya Pazitny](/company/team/#tpazitny), interim quality engineering manager, Secure & Enablement, points out. “I think you need to throw the concept of “nine to five” out the window and actively experiment to find what schedule lets you make the most of your time. I often find the midday slump to be so real, so if i'm feeling this way I step away for a while and then come back for a few hours in the evening when I generally feel supercharged.”\n\n## The magic of a door\n\nFor some of us work at home productivity starts with a closed door. That’s definitely true for Create senior backend engineer [Nick Thomas](/company/team/#nick.thomas). “(There need to be) clear signals to other inhabitants about whether you can be disturbed or not. When I'm in the spare room, the rule is simple – if the door is closed, do not come in.”\n\nHis other tip involves walking through the door and to somewhere else. “Also, I find it really helpful to work from ‘not home’ every now and again. A change is as good as a rest.”\n\n## The snack struggle is real\n\nTanya and [Mario de la Ossa](/company/team/#mdelaossa) both think remote work peril lies in the cupboard. “Keep junk food out of your house or you'll graze all day,” Tanya warns. Mario, backend engineer, Plan, agrees: “If I know there are snacks I WILL eat them, so I keep none in the house.”\n\n## The takeaway\n\nPerhaps [Brad Downey](/company/team/#TechBradD), strategic account leader, southern California, sums it up best: “Get dressed, have a proper work area (not the couch), and don’t eat lunch at your desk.”\n\nHave a great idea we didn’t mention? Leave it below and we’ll add it, and these, to the handbook.\n",[9,680,998],{"slug":5932,"featured":6,"template":683},"tips-for-working-from-home-remote-work","content:en-us:blog:tips-for-working-from-home-remote-work.yml","Tips For Working From Home Remote Work","en-us/blog/tips-for-working-from-home-remote-work.yml","en-us/blog/tips-for-working-from-home-remote-work",{"_path":5938,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5939,"content":5945,"config":5950,"_id":5952,"_type":13,"title":5953,"_source":15,"_file":5954,"_stem":5955,"_extension":18},"/en-us/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"title":5940,"description":5941,"ogTitle":5940,"ogDescription":5941,"noIndex":6,"ogImage":5942,"ogUrl":5943,"ogSiteName":670,"ogType":671,"canonicalUrls":5943,"schema":5944},"Top 10 GitLab workflow hacks you need to know","A GitLab product manager shares her favorite tricks to navigate quickly and efficiently around the GitLab DevSecOps Platform and to boost team collaboration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099361/Blog/Hero%20Images/Blog/Hero%20Images/lightvisibility_lightvisibility.png_1750099361252.png","https://about.gitlab.com/blog/top-10-gitlab-workflow-hacks-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top 10 GitLab workflow hacks you need to know\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-04-09\",\n      }",{"title":5940,"description":5941,"authors":5946,"heroImage":5942,"date":5947,"body":5948,"category":1513,"tags":5949},[1225],"2024-04-09","In the world of software development, efficiency isn't just about moving fast – it's about smart navigation. As a GitLab product manager, I truly understand the value of efficiency when working within the DevSecOps platform. These are my top 10 favorite GitLab features and they might be the workflow hacks you never knew you needed.\n\nLet's dive into these hidden gems to unlock a new level of productivity and collaboration within your team.\n\n## 1. Resolve comments\n\nNot just for merge requests! Resolving comments on issues can significantly reduce noise and streamline task management. It's particularly handy for managing feedback efficiently.\n\n> **Why do I love it?** Not only does resolving comments reduce the noise on an issue, but it’s also a great way to manage tasks.\n>\n> **Use case.** Resolving comments is a great tool for issues where you are collecting feedback – respond to the feedback and provide a link, resolve the comment, and move on to the next one.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)__\n\n![example of resolve comments - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099376147.gif)\n\n\u003Cp>\u003C/p>\n\n## 2. Internal comments\n\nSpeak directly to your team without an external audience. Keep discussions private within an issue or merge request with comments visible only to your team members. It's the perfect balance between transparency and privacy.\n\n> **Why do I love it?** It balances privacy with transparency, while keeping the broader discussion open for the community.\n>\n> **Use case.** When coordinating a product launch, your marketing team can use internal comments to discuss and refine messaging and strategy. This keeps your discussions centralized and easily accessible to the team while in draft mode.\n>\n> **[How-to documentation](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note)**\n\n![internal comments example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099376148.png)\n\n\u003Cp>\u003C/p>\n\n## 3. And/or in filters\n\nWhen searching records on a listing page, using and/or filters can help you slice through the noise and find exactly what you're looking for quickly and efficiently.\n\n> **Why do I love it?** Perfect for finding exactly what you need, powering efficient and streamlined workflows.\n>\n>**Use case.** Search for feature issues related to a specific initiative that are assigned to specific groups.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#filter-with-the-or-operator)__\n\n![and/or filter example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/and_or__1__aHR0cHM6_1750099376152.gif)\n\n\u003Cp>\u003C/p>\n\n## 4. Auto expand URLs\n\nAppending '+' or '+s' to the end of a GitLab URL transforms it into an informative snippet, allowing you to share progress without forcing your teammates to leave the page.\n\n> **Why do I love it?** It's like having x-ray vision for URLs – see the important stuff without even clicking!\n>\n> **Use case.** Sharing progress in comments? Just add '+s' to the link, and boom – everyone's instantly on the same page.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference)__\n\n![auto expand URLs example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099376154.gif)\n\n\u003Cp>\u003C/p>\n\n## 5. Quick actions\n\nWith simple text commands, quick actions let you perform tasks like assigning users, adding labels, and more, directly from the description or comment box, saving you clicks and time.\n\n> **Why do I love it?** Saves clicks and time.\n>\n> **Use case.** When creating a new issue I use quick actions to automatically add labels, a milestone, and connect to the epic upon saving the record.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/project/quick_actions.html)__\n\n![quick actions example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099376156.gif)\n\n\u003Cp>\u003C/p>\n\n## 6. Bulk edit\n\nApply labels, change assignees, or update milestones for multiple issues at once. This feature turns potentially tedious updates into a breeze, allowing for quick adjustments across numerous issues.\n\n> **Why do I love it?** Because it turns tedious updates into quick updates!\n>\n> **Use case.** Need to tag the whole sprint's issues as Review needed? Just filter, select all, and add that label in bulk – easy peasy.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-edit-issues-from-a-project)__\n\n![bulk edit example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099376157.gif)\n\n\u003Cp>\u003C/p>\n\n## 7. Epic swimlanes\n\nGroup issues under epics on your board to visually track and discuss progress. It's a powerful way to contextualize work during reviews or standups.\n\n> **Why do I love it?** Easily understand the context of work as you’re walking the board.\n>\n> **Use case.** Group by epic during standup reviews to easily piece together work with its parent initiative.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes)__\n\n![epic swimlanes example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099376158.gif)\n\n\u003Cp>\u003C/p>\n\n## 8. Wiki diagrams\n\nIllustrate ideas and workflows directly in your wiki pages with easy-to-create diagrams. This feature supports visual learning and simplifies complex concepts.\n\n> **Why do I love it?** It’s incredibly user-friendly and flexible.\n>\n> **Use case.** When outlining a new feature workflow, draw it directly in the wiki page, making it crystal clear for everyone on the team.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/administration/integration/diagrams_net.html)__\n\n![wiki diagrams example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099376159.gif)\n\n\u003Cp>\u003C/p>\n\n## 9. Table creation\n\nForget about wrestling with markdown for table creation. The rich text editor lets you effortlessly insert and format tables, making documentation cleaner and more structured.\n\n> **Why do I love it?** It turns the table creation ordeal into a breeze, making updates clean and structured with just a few clicks.\n>\n> **Use case.** Compiling a sprint retro? Quickly insert a table to organize feedback, action items, and owners, making the review process smoother for everyone.\n>\n> __[How-to documentation](https://docs.gitlab.com/ee/user/rich_text_editor.html#tables)__\n\n![table creation example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099376160.gif)\n\n\u003Cp>\u003C/p>\n\n## 10. Video and GIF embeds\n\nEnhance your issues and epic descriptions or comments with embedded GIFs and YouTube videos, adding a dynamic layer to your communication.\n\n> **Why do I love it?** Sometimes a GIF or video speaks better than words.\n>\n> **Use case.** Trying to explain a UI bug? Embed a YouTube video for a quick walkthrough of the proposed feature enhancement.\n\n![video and gif embed example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/gif__1__aHR0cHM6_1750099376161.gif)\n\n\u003Cp>\u003C/p>\n\n## Explore these features\n\nThese features represent just the tip of the iceberg in GitLab's comprehensive toolkit designed to boost efficiency and foster better collaboration. While they may be underutilized, their impact on your workflow could be substantial. I encourage you to explore these features further and integrate them into your daily routines.\n\n> Are you excited to power your DevSecOps workflow using GitLab? [Try GitLab Ultimate for free for 30 days](https://gitlab.com/-/trial_registrations/new).\n",[746,478,9,894],{"slug":5951,"featured":6,"template":683},"top-10-gitlab-workflow-hacks-you-need-to-know","content:en-us:blog:top-10-gitlab-workflow-hacks-you-need-to-know.yml","Top 10 Gitlab Workflow Hacks You Need To Know","en-us/blog/top-10-gitlab-workflow-hacks-you-need-to-know.yml","en-us/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"_path":5957,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5958,"content":5964,"config":5969,"_id":5971,"_type":13,"title":5972,"_source":15,"_file":5973,"_stem":5974,"_extension":18},"/en-us/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo",{"title":5959,"description":5960,"ogTitle":5959,"ogDescription":5960,"noIndex":6,"ogImage":5961,"ogUrl":5962,"ogSiteName":670,"ogType":671,"canonicalUrls":5962,"schema":5963},"Top tips for efficient AI-powered Code Suggestions with GitLab Duo","Explore best practices  for using Code Suggestions and how to combine it with our other AI features to greatly improve the developer experience (includes real-world exercises).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669095/Blog/Hero%20Images/gitlabduo.png","https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Top tips for efficient AI-powered Code Suggestions with GitLab Duo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-06-11\",\n      }",{"title":5959,"description":5960,"authors":5965,"heroImage":5961,"date":5966,"body":5967,"category":806,"tags":5968},[2037],"2024-06-11","[GitLab Duo](https://about.gitlab.com/gitlab-duo/), our suite of AI-powered features, provides a unique opportunity to make your DevSecOps workflows more efficient. To make the most of GitLab Duo requires hands-on practice and learning in public together. This tutorial centers on GitLab Duo Code Suggestions and provides tips and tricks, learned best practices, and some hidden gems (including how to pair Code Suggestions with our other AI features for even more efficiency). You'll also discover how AI greatly improves the developer experience.\n\nThe best practices, tips, and examples in this article have been created from scratch and are included in the [GitLab Duo documentation](https://docs.gitlab.com/ee/user/gitlab_duo/index.html) and [GitLab Duo prompts project](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts), maintained by the GitLab Developer Relations team. Bookmark this page, and navigate into the respective chapters at your convenience.\n\nWhat you'll learn:\n\n1. [Why use GitLab Duo Code Suggestions?](#why-use-gitlab-duo-code-suggestions%3F)\n1. [Start simple, refine prompts](#start-simple-refine-prompts)\n1. [Practice, practice, practice](#practice-practice%2C-practice)\n    - [Fix missing dependencies](#fix-missing-dependencies)\n    - [Boilerplate code: Optimized logging](#boilerplate-code-optimized-logging)\n    - [Utility helper functions, well tested](#utility-helper-functions-well-tested)\n    - [Generate regular expressions](#generate-regular-expressions)\n1. [Re-trigger Code Suggestions](#re-trigger-code-suggestions)\n    - [Common keyboard combinations to re-trigger Code Suggestions](#common-keyboard-combinations-to-re-trigger-code-suggestions)\n    - [Stuck in the middle of suggestions](#stuck-in-the-middle-of-suggestions)\n    - [Code Suggestions stopped](#code-suggestions-stopped)\n1. [Code Suggestions vs, code generation](#code-suggestions-vs.-code-generation)\n    - [Start with a comment on top for code generation](#start-with-a-comment-on-top-for-code-generation)\n    - [Intent detection for code suggestions and generation](#intent-detection-for-code-suggestions-and-generation)\n    - [Tell a story for efficient code generation](#tell-a-story-for-efficient-code-generation)\n    - [Generate regular expressions](#generate-regular-expressions)\n    - [Iterate faster with code generation](#iterate-faster-with-code-generation)\n    - [Practical code generation: Cloud-native observability](#practical-code-generation-cloud-native-observability)\n1. [Take advantage of all GitLab Duo features](#take-advantage-of-all-gitlab-duo-features)\n    - [Combine Chat with Code Suggestions](#combine-chat-with-code-suggestions)\n    - [Use Chat to generate build configuration](#use-chat-to-generate-build-configuration)\n    - [Use Chat to explain potential vulnerabilities](#use-chat-to-explain-potential-vulnerabilities)\n    - [Combine vulnerability resolution with Code Suggestions](#combine-vulnerability-resolution-with-code-suggestions)\n1. [More tips](#more-tips)\n    - [Verify code quality and security](#verify-code-quality-and-security)\n    - [Learn as a team, and understand AI's impact](#learn-as-a-team-and-understand-ai-impact)    \n    - [Development is a marathon, not a sprint](#development-is-a-marathon-not-a-sprint)\n    - [Contribute using GitLab Duo](#contribute-using-gitlab-duo)\n1. [Share your feedback](#share-your-feedback)\n\n## Why use GitLab Duo Code Suggestions?\n\nConsider these two scenarios:\n\n1. As a senior developer, you have the confidence in your ability with various programming languages to write new source code, review existing code, design resilient architectures, and implement new projects. However, getting familiar with the latest programming language features requires time, research, and a change of habits. So how can you quickly learn about new language feature additions that could make your code even more robust or use resources more sustainably?\n\n    - As a personal example, I learned the C++03 standard, later C++11 and never really touched base on C++14/17/20/23 standards. Additionally, new languages such as [Rust](https://about.gitlab.com/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/) came around and offered better developer experiences. What now?\n\n2. As a new engineer, it can be challenging to navigate new projects, get familiar with a new programming language, understand specific algorithms, and find the documentation for structures, interfaces, and other technical components. New engineers are also learning under pressure, which often leads to errors and roadblocks along the way. There is no time for digging into best practices.\n\n    - I, myself, never really learned frontend engineering, just some self-taught HTML, CSS, and JavaScript. Adapting into frontend frameworks such as VueJS after a decade feels overwhelming, and I have little time to learn.\n\nThese scenarios show how hard it can be to keep up with the latest programming languages, best practices, and other key information. [GitLab Duo Code Suggestions](https://about.gitlab.com/solutions/code-suggestions/), which predictively completes code blocks, defines function logic, generates tests, and proposes common code like regex patterns – all in your coding environment. Code Suggestions provides the AI assistance necessary to learn what you need to know while staying in your development flow.\n\n> Live demo! Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Register today](https://about.gitlab.com/seventeen/)!\n\n## Start simple, refine prompts\n\nMy own GitLab Duo adoption journey started with single-line code comments, leading to not-so-great results at first. \n\n```\n# Generate a webserver\n\n// Create a database backend\n\n/* Use multi-threaded data access here */\n```\n\nAfter experimenting with different contexts, and writing styles, I found that code generation out of refined comments worked better. \n\n```\n# Generate a webserver, using the Flask framework. Implement the / URL endpoint with example output.\n\n// Create a database backend. Abstract data handlers and SQL queries into function calls.\n\n/* Use multi-threaded data access here. Create a shared locked resource, and focus on supporting Linux pthreads. */\n```\n\nCode comments alone won't do the trick, though. Let's explore more best practices.\n\n## Practice, practice, practice \n\nFind use cases and challenges for your daily workflows, and exclusively use GitLab Duo. It can be tempting to open browser search tabs, but you can also solve the challenge in your IDE by using GitLab Duo. Here are some examples:\n\n1. Fix missing dependencies (which always cause build/execution failures).\n1. If you're missing logging context, let Code Suggestions auto-complete started function calls, including `print` statements.\n1. Generate common methods and attributes for object-oriented design patterns (e.g. getter/setter methods, `toString()` and object comparison operators, object inheritance, etc.).\n1. Identify the function that generates random crashes. Use Code Suggestions to implement a new function with a different algorithm.\n1. If you encounter application cannot be compiled or executed, cryptic error, ask GitLab Duo Chat about it.\n1. Learn about existing (legacy) code, and strategies to document and refactor code into modern libraries. Start a v2 of an application with a new framework or programming language, helping solve technical debt.\n1. Prevent operations and security issues in Git history by detecting them before they occur (e.g. performance, crashes, security vulnerabilities).\n\nThink of the most boring - or most hated - coding task, and add it to the list above. My least favorite tasks are attribute getter/setter methods in C++ classes (as can be seen in the video below), immediately followed by regular expressions for email address format.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Z9EJh0J9358?si=QGvQ6mXxPPz4WpM0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIt can also help to use Code Suggestions in different programming languages, for example focusing on backend and frontend languages. If you are experienced in many languages, take a look into languages that you have not used in a while, or look into learning a new programming language such as [Python](https://about.gitlab.com/blog/learning-python-with-a-little-help-from-ai-code-suggestions/) or [Rust](https://about.gitlab.com/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/). \n\nWhen you adopt Code Suggestions into a fast auto-completion workflow, it can happen without any interruption. The suggested code is greyed out and optional, depending on the user interface – for example, VS Code. This means that it will not distract you from continuing to write source code. Try using Code Suggestions on your own by familiarizing yourself with how suggestions are shown, how you can fully or partially accept them, and soon they will become optional help to write better code. \n\n![Image with code suggestions greyed out](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_java_springboot_class_methods_tostring.png)\n\n### Fix missing dependencies\n\nAfter building or running source code, missing dependency errors might be logged and prevent further execution and testing. The following example in Go shows an error from `go build`, where the source code did not import any dependencies yet. A manual approach can be collecting all listed dependencies, running a unique sort on them, and adding them into the source code file, as shown below.\n\n![Go build failed - missing dependencies](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_build_failed_missing_deps.png)\n\nBut what if GitLab Duo knows about the file context and missing dependencies already? Navigate into the top section and add a comment, saying `// add missing imports` and wait for Code Suggestions.\n\n![GitLab Duo Code Suggestions - go build failed missing dependencies suggested fix](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_build_failed_missing_deps_suggested_fix.png)\n\nRunning `go build` again results in success, and the source code can be tested and run.\n\n![Go build failed - missing dependencies fixed](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_build_failed_missing_deps_fixed.png)\n\n### Boilerplate code: Optimized logging\n\n*Q: Logging – and more observability data with metrics and traces – can be hard and tedious to implement. What is the most efficient way to implement them that does not impact the application performance or cause bugs?*\n\n*A: Use Code Suggestions to generate logging function calls, and refactor the code into robust observability instrumentation library abstractions. This method can help to prepare the code for later integration with [OpenTelemetry](https://docs.gitlab.com/ee/development/stage_group_observability/gitlab_instrumentation_for_opentelemetry.html), for example.*\n\nExample for a logging class in Ruby:\n\n```ruby\n# Create Logging utility class\n# Define default log level as attribute\n# Add method for logging, inputs: level, app, message\n# Print the data with formatted date and time in syslog format\n\n# Potential AI-generated code below\nclass Logging\n  attr_accessor :log_level\n\n  def log(level, app, message)\n    time = Time.now.strftime(\"%b %d %H:%M:%S\")\n    puts \"#{time} #{app}[#{Process.pid}]: #{level} - #{message}\"\n  end\nend\n\n# Instantiate class and test the log method\n\n# Potential AI-generated code below\nlogger = Logging.new\nlogger.log_level = :debug\n\nlogger.log(:info, 'MyApp', 'Application started - info')\nlogger.log(:debug, 'MyApp', 'Application started - debug')\nlogger.log(:error, 'MyApp', 'Application started - error')\nlogger.log(:fatal, 'MyApp', 'Application started - fatal')\nlogger.log(:warn, 'MyApp', 'Application started - warn')\n```\n\n### Utility helper functions, well tested\n\n*Q: The programming language does not provide basic functions in the standard library. I'm tempted to open my browser to add string manipulation and regular expression parser functions.*\n\n*A: Create a new file called `utility.{language-suffix}` and add a code comment on top. Instruct Code Suggestions to generate a string manipulation function ().*\n\nExample for a string manipulation method in Python:\n\n```python\n# Create a function to search for a string in a string, return the index\n# Optionally remove search string, and return modified string\n# Test the function on the string \"Cool programming languages: C++, Rust, Python\" - Remove the string \"C++\"\n\n# Potential AI-generated code below\ndef search_and_remove(text, search):\n    index = text.find(search)\n    if index != -1:\n        return index, text[:index] + text[index+len(search):]\n    else:\n        return None, text\n\ntext = \"Cool programming languages: C++, Rust, Python\"\nindex, new_text = search_and_remove(text, \"C++\")\nprint(index, new_text)\n```\n\n**Async exercise:** Ask GitLab Duo Chat how to add tests in Python, select the source code, and use the `/tests` slash command. \n\nA similar example can be implemented in Go, creating utility functions for unique integer values in an array, or the sum of all even values. Start with defining the project structure through `go mod init gitlab.com/group/project` and create the `array.go` file. Define the `package` and start with the first code comment to generate the functions.\n\n```go\npackage array \n\n// Create a function that returns unique values from an integer array\n\n// Possible AI-generated code\nfunc unique(ints []int) []int {\n    occurred := map[int]bool{}\n    result := []int{}\n    for _, i := range ints {\n        if !occurred[i] {\n            occurred[i] = true\n            result = append(result, i)\n        }\n    }\n    return result\n}\n\n// Create a function that returns the sum of all even numbers in an integer array\n\n// Possible AI-generated code\nfunc sumEvens(ints []int) int {\n    var sum int\n    for _, i := range ints {\n        if i%2 == 0 {\n            sum += i\n        }\n    }\n    return sum\n}\n```\n\n**Async exercise**: Create more utility helper functions in dedicated libraries, and use Chat to select and generate `/tests`. For the Go example, you can inspect potential solutions in the `go/utility/array_test.go` file in the [GitLab Duo Prompts project](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts). Build and test the code using `go build && go test`.\n\n### Generate regular expressions\n\nDevelopers' favorite one liners, never touched again. `git blame` knows very well but might not be able to provide enough context. GitLab Duo can help with regular expressions creation, explanation, and refactoring, in the following example:\n\n*Q: My regular expressions for parsing IPv6 and IPv4 addresses do not work. What's the best approach to solve this?*\n\n*A: Use Code Suggestions comments to generate examples using these regex types. Combine the questions with Chat, and ask for more examples in different languages. You can also select the existing source, and use a refined prompt with `/refactor using regular expressions` in the Chat prompt.*\n\n**Async exercise**: Choose your favorite language, create a function stub that checks IPv6 and IPv4 address strings for their valid format. Trigger Code Suggestions to generate a parsing regular expression code for you. Optionally, ask Chat how to refine and refactor the regex for greater performance.\n\nI chose TypeScript, a language on my personal learning list for 2024: `// Generate a TypeScript function which parses IPv6 and IPv4 address formats. Use regular expressions`.\n\n![Code Suggestions - typescript utility parse ip address regex](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_typescript_utility_parse_ip_address_regex.png)\n\n![Code Suggestions typescript - utility parse ip address regex tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_typescript_utility_parse_ip_address_regex_tests.png)\n\n## Re-trigger Code Suggestions\n\nYou can trigger Code Suggestions by pressing the `enter` or `space` key, depending on the context. In VS Code and the GitLab Web IDE, the GitLab Duo icon will appear in the same line, and at the bottom of the window.\n\nIf you accepted a suggestion, but actually want to try a different suggestion path, select the code, delete the line(s) and start over.\n\n> **Tip:** Different keystrokes and strategies for Code Suggestions are recorded in this video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ORpRqp-A9hQ?si=CmA7PBJ9ckWsvjO3\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Common keyboard combinations to re-trigger Code Suggestions\n\nEspecially in the early adoption phase of Code Suggestions, you'll need to practice to get the best results from comments, existing code style, etc., put into context.\n\nA common keystroke pattern for triggering suggestions can be\n\n1. Press `Enter` and wait for the suggestion.\n1. Press `Space` followed by `Backspace` to immediately delete the whitespace again, or\n1. Press `Enter` to re-trigger the suggestion. `Backspace` to delete any leftover new lines.\n\nWhen a suggestion makes sense, or you want to see how far you can get:\n\n1. Continue pressing `Tab` to accept the suggestion.\n1. Add a space or press `Enter` to open a new scope for triggering a new suggestion.\n1. Continue accepting suggestions with `Tab`. \n\nNote that generative AI sometimes ends up in a loop of suggesting similar code paths over and over again. You can trigger this behavior by inserting test data into an array, using strings and numbers in a sorted order or by generating different API endpoints, as it tries to guess which other endpoints could be helpful. When this happens, break the acceptance flow, and continue writing code as normal.\n\n### Stuck in the middle of suggestions\n\nSometimes, the code suggestions may stop in the middle of a variable, function, etc. definition. If you are unsure about the syntax, or want to restart the code suggestions:\n\n1. Delete the last character(s) or the entire line, using `Backspace`.\n1. Alternatively, use `shift cursor left` (select characters) or `cmd shift cursor left` (select entire line), followed by `Backspace`.\n1. Move the cursor into the line above, and press `Enter` to force a Code Suggestions trigger again.\n\n### Code Suggestions stopped\n\nWhen Code Suggestions stops, there can be multiple reasons:\n\n1. The current file scope ends – for example, a `main()` function has been generated and closed.\n1. There could be connection problems to the GitLab instance (self-managed) or GitLab.com (SaaS, [Dedicated](https://about.gitlab.com/dedicated/)). Follow the [troubleshooting documentation](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/troubleshooting.html).\n\n## Code suggestions vs. code generation\n\nCode suggestions \"come as you go\" while writing code, and help with completing line(s). Code generation on the other hand requires more context to create entire code blocks, consisting of functions, algorithms, classes, etc. \n\nThe following sections discuss both methods, and how to get started with a practical example. \n\n### Code suggestions flow with comments\n\nUse your natural programming flow, and stop to adapt to adding code comments when helpful for context and better suggestions. You can accept code suggestions using the `Tab` key, or selectively accept words using the `cmd cursor right` keyboard shortcut.\n\nThe following new challenge implements a simple Linux statistics tool in C, mimicking the functionality of `iostat`, `vmstat` and `du` CLI commands on Linux. Sometimes, these low-level metrics come in handy for presenting application metrics, or otherwise help with debugging when requesting support data from customers.\n\nCreate a new application directory called `linux_stat` and `main.c` file, and let Code Suggestions complete everything else. First, start with a simple code comment block:\n\n```c\n// Create a Linux statistic tool\n// Collect IO, performance, disk usage, TCP latency\n// Print summaries\n```\n\nNext, press `Enter` to trigger the creation of the `main()` method. If not automatically created, force it through a new code comment.\n\n```c\n// Create main function to collect data\n```\n\nIn my attempts, generative AI did not immediately implement all functionality. Instead, it added a `TODO` comment into the following code block.\n\n```c\nint main() {\n    struct stat statbuf;\n\n    if (stat(\"/etc\", &statbuf) != 0) {\n        perror(\"stat\");\n        return 1;\n    }\n\n    printf(\"IO Block Size: %ld\\n\", statbuf.st_blksize);\n\n    // TODO: add CPU usage, disk usage, network latency measurements\n\n    return 0;\n}\n```\n\nMove the cursor after the `TODO` comment, and continue with a new comment to collect CPU usage:\n\n```c\n    // Collect CPU usage\n\n    // Example for AI-generated code below\n    double cpu_usage;\n\n    FILE* stat_file = fopen(\"/proc/stat\", \"r\");\n    if (stat_file == NULL) {\n        perror(\"fopen\");\n        return 1;\n    }\n\n    // Parse /proc/stat to get CPU usage\n    fscanf(stat_file, \"cpu %lf\", &cpu_usage);\n\n    printf(\"CPU Usage: %.2f%%\\n\", cpu_usage * 100);\n\n    fclose(stat_file);\n```\n\nThe generated code might not be 100% accurate, since measuring CPU usage on Linux requires taking samples over a defined time range. Thus, the caller needs to calculate the real CPU utilization from all values in `/proc/stat`, including [`system, nice, user, idle, iowait`, etc.](https://www.kernel.org/doc/Documentation/filesystems/proc.txt).\n\n**Async challenge:** Optimize the collection process with average calculation.\n\nRepeat the steps for disk usage and network latency. The code comment is written by you, the C source code is generated with GitLab Duo.\n\n```c\n    // Collect disk usage\n\n    // Collect network latency\n\n    // Example for AI-generated code below\n    int sockfd = socket(AF_INET, SOCK_STREAM, 0);\n\n    struct sockaddr_in servaddr;\n    servaddr.sin_family = AF_INET;\n    servaddr.sin_port = htons(80);\n    inet_pton(AF_INET, \"8.8.8.8\", &servaddr.sin_addr);\n```\n\nThe generated code may use public IP addresses to test network latency. Change the IPv4 address to GitLab.com's current address. \n\n```c\n    inet_pton(AF_INET, \"172.65.251.78\", &servaddr.sin_addr);\n```\n\nThe generated source code added more header dependencies. Navigate into the top section of the file, and add a comment to include all required headers:\n\n```c\n// Import required headers\n```\n\nBuild and run the application on Linux, example on Ubuntu 22 LTS:\n\n```shell\n# Install compiler\napt install gcc\n\n# Build\ngcc main.c -o linux_stat\n\n# Build: If the math.h header is included, linking against the library is needed, too\ngcc linux_stat.c -o linux_stat -lm\n\n# Run the tool\n./linux_stat\n```\n\n**Bonus:** Change the code to use IPv6, and check the GitLab.com IPv6 address again (`dig gitlab.com AAAA +short`).\n\n```c\n    // Collect network latency\n\n    // Use IPv6 \n\n    // Example for AI-generated code below\n    struct sockaddr_in6 servaddr;\n    servaddr.sin6_family = AF_INET6;\n    servaddr.sin6_port = htons(80);\n    //inet_pton(AF_INET6, \"2001:db8::1\", &servaddr.sin6_addr);\n    inet_pton(AF_INET6, \"2606:4700:90:0:f22e:fbec:5bed:a9b9\", &servaddr.sin6_addr);\n\n    int sockfd = socket(AF_INET6, SOCK_STREAM, 0);\n```\n\n![C Linux stat tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_c_linux_stat_tests.png)\n\nThe full working source code is available in the [GitLab Duo Prompts project](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts) in the directory for C code.\n\n**Async exercise:** Refactor the C code into Rust, using only GitLab Duo. Start by selecting the source code, and use the Duo Chat prompt `/refactor into Rust`. \n\n> **Tip:** Thoughtful code comments make the source code more readable, too. This helps new team members with onboarding, site reliability engineers with debugging production incidents, and open source contributors with [merging their first MRs](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#first-time-contributors).\n\n### Start with a comment on top for code generation\n\nSource code can be organized in multiple files. Whether you start with a new application architecture, or refactor existing source code, you can take advantage of code generation with GitLab Duo.\n\nStart with a comment block on top, and make it a step-by-step description. You can also break longer comments into multiple lines, revisiting the examples in this article. This pattern also helps to think about the requirements, and can help refining the prompts. \n\n```diff\n# Generate a webserver, using the Flask framework. \n# Implement the / URL endpoint with example output.\n+# Add an endpoint for Promtheus metrics\n\n// Create a database backend. \n// Abstract data handlers and SQL queries into function calls.\n+// Use PostgreSQL as default backend, and SQLite for developers as fallback.\n\n/* \nUse multi-threaded data access here.\nCreate a shared locked resource, and focus on supporting Linux pthreads. \n+Abstract the thread creation/wait procedures into object-oriented classes and methods.\n*/\n```\n\nMore code generation prompts for [supported programming languages](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html) are available in the [GitLab Duo Use Cases documentation](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#code-generation-prompts).\n\n### Intent detection for code suggestions and generation\n\nCode Suggestions, depending on the GitLab Language Server in your IDE, will parse and detect the intent and offer code completion suggestions in the same line or code generation.\n\nThe technology in the background uses TreeSitter to parse the code into an [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree), and determine whether the scope is inside a code comment block (generation), or inside the source code (completion). This detection needs to be executed fast on the client IDE, and proves to be a great use case for [WebAssembly](https://webassembly.org/). You can learn more in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/11568), and the following video, which provides a look into the GitLab Language Server powering Code Suggestions:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VQlWz6GZhrs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Tell a story for efficient code generation\n\nCode generation is art. Tell the story, and AI-powered GitLab Duo can assist you. \n\nThe following example aims to implement an in-memory key-value store in Go, similar to Redis. Start with a description comment, and trigger Code Suggestions by continuing with a new line and pressing `Enter`.\n\n```golang\n// Create an in-memory key value store, similar to Redis \n// Provide methods to\n// set/unset keys\n// update values\n// list/print with filters\n```\n\nWe can be more specific – which methods are required for data manipulation? Instruct Code Suggestions to generate methods for setting keys, updating values, and listing all contained data.\n\n```golang\n// Create an in-memory key value store, similar to Redis \n// Provide methods to\n// set/unset keys\n// update values\n// list/print with filters\n```\n\nAccept all suggestions using the `Tab` key. As a next step, instruct Code Suggestions to create a `main` function with test code.\n\n```golang\n// Create a main function and show how the code works\n```\n\nIf the test data is not enough, refine the generated code with a focus on extreme test cases.\n\n> **Tip:** You can use the same method for refined [Chat prompts and test generation](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide), `/tests focus on extreme test cases`.\n\n```golang\n// Add more random test data, focus on extreme test cases\n```\n\n![Code Suggestions - go kv more test data](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_kv_more_test_data.png)\n\nThe full example, including fixed dependencies, is located in the [gitlab-duo-prompts project](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts) in the `code-suggestions/go/key-value-store` directory. Update the `main.go` file, and build and run the code using the following command: \n\n```shell\ngo build\n./key-value-store\n```\n\nThe first iteration was to create a standalone binary and test different implementation strategies for key-value stores. Commit the working code and continue with your GitLab Duo adoption journey in the next step.\n\n> **Tip:** New projects can benefit from Code Generation, and require practice and more advanced techniques to use code comments for prompt engineering. This method can also make experienced development workflows more efficient. Proof of concepts, new library introductions, or otherwise fresh iterations might not always be possible in the existing project and framework. Experienced developers seek to create temporary projects, and isolate or scope down the functionality. For example, introducing a database backend layer, and benchmarking it for production performance. Or, a library causing security vulnerabilities or license incompatibilities should be replaced with a different library, or embedded code functionality.\n\n### Iterate faster with code generation\n\nExperienced developers will say, \"There must be a key-value library in Go, let us not reinvent the wheel.\" Fortunately, Go is a mature language with a rich ecosystem, and awesome-go collection projects, for example [avelino/awesome-go](https://github.com/avelino/awesome-go), provide plenty of example libraries. Note: This possibility might not be the case for other programming languages, and requires a case-by-case review.\n\nWe can also ask GitLab Duo Chat first, `Which Go libraries can I use for key-value storage?`:\n\n![Chat - ask golang libraries kv](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_chat_ask_golang_libs_kv.png)\n\nAnd then refine the Code Suggestions prompt to specifically use the suggested libraries, for example, BoltDB.\n\n```diff\n// Create an in-memory key value store, similar to Redis \n// Provide methods to\n// set/unset keys\n// update values\n// list/print with filters\n+// Use BoltDB as external library\n```\n\nRepeat the pattern from above: Generate the source code functions, then ask GitLab Duo to create a main function with test data, and build the code. The main difference is external libraries, which need to be pulled with the `go get` command first. \n\n```shell\ngo get\ngo build\n```\n\nIf the source code build fails with missing dependencies such as `fmt`, practice using GitLab Duo again: Move the cursor into the `import` statement, and wait for the suggestion to add the missing dependencies. Alternatively, add a comment saying `Import all libraries`.\n\n![Code Suggestions - go kv external lib boltdb fix dependencies](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_kv_external_lib_boltdb_fix_deps.png)\n\nYou can also add more test data again, and verify how the functions behave: `// Add more random test data, focus on extreme test cases`. In the following example, an empty key causes the program to panic.\n\n![Code Suggestions - Go kv external lib boltdb test extreme cases panic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_kv_external_lib_boltdb_test_extreme_cases_panic.png)\n\nThis example is a great preparation for test cases later on.\n\n### Practical code generation: Cloud-native observability\n\nThink of a client application in Go, which lists the current state of containers, pods, and services in a Kubernetes cluster, similar to the `kubectl get pods` command line. The Kubernetes project provides [Go libraries](https://pkg.go.dev/k8s.io/client-go/kubernetes) to programmatically interact with the Kubernetes APIs, interfaces, and object structures.\n\nOpen your IDE, and create a new Go project.\n\n> **Tip:** You can ask Chat how to do it - `How to start a Go project? Please show CLI command examples`. \n\nStart with a single comment on top of the `main.go` file, and describe the application purpose: Observability in Kubernetes.\n\n```golang\n// Create a client for Kubernetes observability\n```\n\nThink about the main requirements: Get access to Kubernetes, create context, namespace, and inspect the state. Additionally, instruct Code Suggestions to import packages and create a main package in the `main.go` file.\n\nFirst iteration:\n\n```golang\n// Create a client for Kubernetes observability\n// Inspect container, pod, service status and print an overview\n```\n\nThis might do unexpected things with hardcoding the access credentials, missing contexts, failing builds.\n\nSecond iteration:\n\n```golang\n// Create a client for Kubernetes observability\n// Create a function that\n// Read the kubernetes configuration file from the KUBECONFIG env var\n// Inspect container, pod, service status and print an overview\n```\n\nThis might not know about Kubernetes contexts and namespaces, thus leading to build errors or unexpected results.\n\nThird iteration:\n\n```golang\n// Create a client for Kubernetes observability\n// Create a function that\n// Read the kubernetes configuration file from the KUBECONFIG env var\n// Create kubernetes context, namespace default\n// Inspect container, pod, service status and print an overview\n```\n\nThis example hardcodes the Kubernetes context and default namespace to generate an initial foundation. Later iterations can read the namespace value from a command line parameter, or configuration file.\n\nThe final example can look like the following. In addition to the application functionality, it also instructs Code Suggestions to import all dependencies, and create a `main` package in `main.go`.\n\n```golang\n// Create a client for Kubernetes observability\n// Create a function that\n// Read the kubernetes configuration file from the KUBECONFIG env var\n// Create kubernetes context, namespace default\n// Inspect container, pod, service status and print an overview\n// Import necessary packages\n// Create main package\n```\n\n\u003Cdetails> Solution \n\u003Csummary>\n\n```golang\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"os\"\n\n\t\"k8s.io/client-go/kubernetes\"\n\t\"k8s.io/client-go/tools/clientcmd\"\n\tmetav1 \"k8s.io/apimachinery/pkg/apis/meta/v1\"\n)\n\nfunc main() {\n\tkubeconfig := os.Getenv(\"KUBECONFIG\")\n\tconfig, err := clientcmd.BuildConfigFromFlags(\"\", kubeconfig)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tclientset, err := kubernetes.NewForConfig(config)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tpods, err := clientset.CoreV1().Pods(\"\").List(context.TODO(), metav1.ListOptions{})\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tfmt.Printf(\"There are %d pods in the cluster\\n\", len(pods.Items))\n\n\t// Additional code to inspect services, containers, etc\n}\n```\n\n\u003C/summary>\n\u003C/details>\n\nExample output:\n\n![duo code suggestions - go k8s o11y output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_go_k8s_o11y_output.png)\n\n**Async exercise:** Complete the project with code for inspecting services, containers, etc., and export the findings to [OpenTelemetry](https://opentelemetry.io/).\n\n> **Tip:** Practice with the [GitLab Duo use cases: Code generation prompts](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#code-generation-prompts) in the documentation, and/or send merge requests with your working prompts.\n\nWhile recording a short video to highlight how code generation is working, another more refined source code was generated. You can inspect the differences in [this commit](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/commit/a1a46de9789d4791f04b4df9f1a35d05b8e67568), and benefit from both solutions.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ORpRqp-A9hQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Take advantage of all GitLab Duo features \n\n### Combine Chat with Code Suggestions\n\nIn combination with [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html), Code Suggestions becomes even more powerful. The following workflow illustrates the intersection of AI efficiency:\n\nWrite and generate new code using Code Suggestions. The source code will be verified through CI/CD automation, code quality tests, and security scanning. But what about the developer's knowledge?\n\n1. In your IDE, select the generated code portions and use the [`/explain` slash command](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide) in the Chat prompt. You can even refine the prompt to `/explain with focus on algorithms`, or otherwise helpful scopes such as potential security or performance problems, etc.\n\n    - Continue writing and maintaining source code, but at some point code quality decreases and refactoring gets challenging. Ask GitLab Duo Chat for help.\n\n2. In your IDE, select the source code, and use the [`/refactor` slash command](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide) in the Chat prompt. You can refine the prompt to focus on specific design patterns (functions, object-oriented classes, etc.), `/refactor into testable functions` for example._\n\n    - After ensuring more readable code, tests need to be written. What are potential extreme cases, or random data examples for unit tests? Research and implementation in various frameworks can take time.\n\n3. In your IDE, select the source code, and use the [`/tests` slash command](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide) in the Chat prompt. You can also refine the prompt to focus in specific test frameworks, scenarios, input methods, etc. \n\n    - Code quality and test coverage reports are green again. Focus on efficient DevSecOps workflows with Code Suggestions again. \n\nMore scenarios are described in the [GitLab Duo use cases documentation](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html).\n\n### Use Chat to generate build configuration\n\nThe time-intensive research on getting started with a new project can be exhausting. Especially with different paths to do it right, or alternative frameworks, this can lead to more work than anticipated. Newer programming languages like Rust propose one way (Cargo), while Java, C++, etc. offer multiple ways and additional configuration languages on top (Kotlin DSL, CMake DSL, etc.).\n\nTake advantage of asking GitLab Duo how to start a project, generate specific configuration examples for build tools (e.g. `Please show a gradle.build example for Spring Boot`), and reduce the time to start developing, building, and testing source code.\n\n1. Java, Gradle, Spring Boot: `Please show a gradle.build example for Spring Boot`\n1. C++, CMake, clang: `Please show a basic CMake configuration file for C++17, using clang as compiler.`\n1. Python: `Please show how to initialize and configure a Python project on the CLI`\n1. Rust: `Please show how to initialize and configure a Rust project.`, followed by a refinement question: `Explain the structure of Cargo.toml`.\n1. Go: `Please show how to initialize and configure a Go project`. \n\n### Use Chat to explain potential vulnerabilities\n\nLet us assume that some PHP code was generated to create a web form. The code might be vulnerable to security issues.\n\n```php\n\u003C?php \n// Create a feedback form for user name, email, and comments\n// Render a HTML form\n\n$name = $_POST['name'];\n$email = $_POST['email'];\n$comments = $_POST['comments'];\n\necho '\u003Cform method=\"post\">';\necho '\u003Clabel for=\"name\">Name:\u003C/label>';\necho '\u003Cinput type=\"text\" id=\"name\" name=\"name\">';\n\necho '\u003Clabel for=\"email\">Email:\u003C/label>';\necho '\u003Cinput type=\"email\" id=\"email\" name=\"email\">';\n\necho '\u003Clabel for=\"comments\">Comments:\u003C/label>';\necho '\u003Ctextarea id=\"comments\" name=\"comments\">\u003C/textarea>';\n\necho '\u003Cinput type=\"submit\" value=\"Submit\">'; \necho '\u003C/form>';\n\n?>\n```\n\nSelect the source code, and [ask Chat to explain](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide), using a refined prompt with `/explain why this code is vulnerable to bad security actors`. \n\n![Code Suggestions - Chat explains potential vulnerability](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_chat_explain_potential_vulnerability.png)\n\n> **Tip**: We are investigating and learning in the local developer environment. The vulnerable source code can be fixed before it reaches a Git push and merge request that trigger security scanning, which will unveil and track the problems, too. Learning about security vulnerabilities helps improve the developer experience.\n\n### Combine vulnerability resolution with Code Suggestions\n\nLets look into another example with an intentional [vulnerability resolution challenge](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/vulnerability-resolution/challenge-resolve-vulnerabilities), and see if we can use Code Suggestions in combination with vulnerability resolution. The linked project has been preconfigured with static application security testing (SAST) scanning. You can follow these steps to configure GitLab SAST by using the [SAST CI/CD component](https://gitlab.com/explore/catalog/components/sast) in the `.gitlab-ci.yml` CI/CD configuration file.\n\n```yaml\ninclude:\n  # Security: SAST (for vulnerability resolution)\n  - component: gitlab.com/components/sast/sast@1.1.0\n```\n\nAfter inspecting the vulnerability dashboard and details, you can use [vulnerability explanation](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) to better understand the context and potential problems. [Vulnerability resolution](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#vulnerability-resolution) creates a rerge request with a proposed source code fix for a detected security vulnerability. \n\nSometimes, it can be necessary to refine the suggested code. Navigate into the [created MR](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/vulnerability-resolution/challenge-resolve-vulnerabilities/-/merge_requests/1), and either copy the Git branch path for local Git fetch, or open the Web IDE from the `Edit` button to continue in the browser. Navigate into the source code sections with the fixed code portions, and modify the code with a comment:\n\n```\n// refactor using safe buffers, null byte termination\n```\n\n![duo code suggestions - with vulnerability resolution proposal](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_with_vulnerability_resolution_proposal.png)\n\nAlternatively, you can also open Chat, select the source code and use the `/refactor` slash command.\n\n![duo code suggestions - with vulnerability resolution add duo chat refactor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677063/Blog/Content%20Images/duo_code_suggestions_with_vulnerability_resolution_add_duo_chat_refactor.png)\n\nA full example is available in the [GitLab Duo use cases documentation](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#explain-and-resolve-vulnerabilities). \n\nHere is a recording of that example:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Ypwx4lFnHP0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## More tips \n\n### Verify code quality and security\n\nMore generated code requires quality assurance, testing, and security measures. Benefit from all features on a DevSecOps platform:\n\n1. [CI/CD components](https://docs.gitlab.com/ee/ci/components/) and [pipeline efficiency](https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html)\n1. [Code quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n1. [Code test coverage](https://docs.gitlab.com/ee/ci/testing/code_coverage.html)\n1. [Application security](https://docs.gitlab.com/ee/user/application_security/)\n1. [Observability](https://docs.gitlab.com/ee/operations/tracing.html)\n\n### Learn as a team, and understand AI impact\n\nAdapt and explore with dedicated team collaboration sessions, and record them for other teams to benefit from later. You can also follow the [GitLab Duo Coffee Chat playlist on YouTube](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp5uj_JgQiSvHw1jQu0mSVZ).\n\nRead about AI impact metrics, including [How to put generative AI to work in your DevSecOps environment](https://about.gitlab.com/the-source/ai/how-to-put-generative-ai-to-work-in-your-devsecops-environment/) and the [Developing GitLab Duo: AI Impact analytics dashboard measures the ROI of AI](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/). Visit the [AI Transparency Center](https://about.gitlab.com/ai-transparency-center/) to learn more about data usage, transparency, and AI ethics at GitLab.\n\n### Development is a marathon, not a sprint\n\nSometimes, code suggestions might take longer to load, compared to local auto-completion features. Take this time as an advantage, and think about the current algorithm or problem you are trying to solve. Often, a secondary thought can lead to more refined ideas. Or you can take a short break to take a sip from your preferred drink, and continue refreshed when the suggestions arrive.\n\nSome algorithms are super complex, or require code dependencies which cannot be resolved through auto-completion help. Proprietary and confidential code may provide less context to the large language models, and, therefore, require more context in the comments for Code Suggestions. Follow your own pace and strategy, and leverage Code Suggestions in situations where they help with boilerplate code, or helper functions. \n\n> **Tip:** Explore [Repository X-Ray](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/repository_xray.html) for more Code Suggestions context, and test experimental features, for example, [support for more languages in VS Code](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#add-support-for-more-languages-for-code-suggestions-in-vs-code). More insights can be found in the epic to [improve acceptance rate for Code Suggestions](https://gitlab.com/groups/gitlab-org/-/epics/13085).\n\n### Contribute using GitLab Duo\n\nYou can use GitLab Duo to contribute to open source projects, using Code Suggestions, code refactoring, documentation through explanations, or test generation.\n\nGitLab customers can [co-create GitLab using GitLab Duo](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html#use-gitlab-duo-to-contribute-to-gitlab), too. Follow the updated guidelines for [AI-generated contributions](https://about.gitlab.com/community/contribute/dco-cla/#ai-generated-contributions), and watch an example recording from the GitLab Duo Coffee Chat: Contribute to GitLab using Code Suggestions and Chat:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/TauP7soXj-E\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Share your feedback\n\nGitLab Duo Code Suggestions enables more efficient development workflows. It requires hands-on practice and exercise through tutorials, team workshops, and guided training. Automated workflows with code quality, security scanning, and observability help tackle challenges with newly introduced source code at a much higher frequency. Taking advantage of all GitLab Duo features, including Chat, greatly improves the developer experience on the most comprehensive AI-powered DevSecOps platform.\n\nUse the best practices in this tutorial to kickstart your journey, follow the [GitLab Duo documentation](https://docs.gitlab.com/ee/user/gitlab_duo/index.html), and [ask our teams for GitLab Duo AI workshops](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/) (I have already shadowed customer workshops, they are great!). Please share your Code Suggestions feedback in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/435783), including screenshots and videos (when possible).\n\n> [Try GitLab Duo for free today!](https://about.gitlab.com/gitlab-duo/#free-trial)",[786,9,746],{"slug":5970,"featured":90,"template":683},"top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo","content:en-us:blog:top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo.yml","Top Tips For Efficient Ai Powered Code Suggestions With Gitlab Duo","en-us/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo.yml","en-us/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo",{"_path":5976,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5977,"content":5982,"config":5988,"_id":5990,"_type":13,"title":5991,"_source":15,"_file":5992,"_stem":5993,"_extension":18},"/en-us/blog/track-machine-learning-model-experiments",{"title":5978,"description":5979,"ogTitle":5978,"ogDescription":5979,"noIndex":6,"ogImage":906,"ogUrl":5980,"ogSiteName":670,"ogType":671,"canonicalUrls":5980,"schema":5981},"Track ML model experiments with new GitLab MLFlow integration","Track the many versions of your machine learning models on GitLab using the MLFlow client.","https://about.gitlab.com/blog/track-machine-learning-model-experiments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Track ML model experiments with new GitLab MLFlow integration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eduardo Bonet\"}],\n        \"datePublished\": \"2023-05-11\",\n      }",{"title":5978,"description":5979,"authors":5983,"heroImage":906,"date":5985,"body":5986,"category":806,"tags":5987},[5984],"Eduardo Bonet","2023-05-11","\n\n\u003Ci>This blog is the latest post in an ongoing series about GitLab’s journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we’ll feature blogs from our product, engineering, and UX teams to showcase how we’re infusing AI/ML into GitLab.\u003C/i>\n\nThe GitLab DevSecOps platform now features [Machine Learning Model Experiments](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/), which is avaliable to all GitLab users, making GitLab a powerful tool for creating ML models. Organizations can now track the many versions of their ML models within the GitLab user interface, using the open source [MLFlow](https://github.com/mlflow/mlflow).\n\n\u003Cimg src=\"/images/blogimages/2023-05-11-gitlab-model-experiments/experiment.png\" alt=\"Model experiment\" style=\"border: 1px solid gray;\">\n\n## What is an ML model?\n\nAn ML model is the result of three components: code to extract the patterns from the data, the data where the \npatterns are extracted from, and the configuration used for both, often called \"hyperparameters\". Any change to any of these components can \nlead to changes in the model performance, and keeping track of all of these parts and the results can be challenging. \nExperiment tracking aims to make sense of this confusion by keeping a record of all of the variations created, \nalong with the artifacts and results of each trial.\n\n[MLFlow](https://github.com/mlflow/mlflow) is a popular open source solution for ML experiment tracking, \nproviding a client to log different model versions and their metadata. However, it puts the cost of deployment and managing \nits server onto the users.\n\nGitLab makes the tracking process easier not by deploying a managed MLFlow backend, but by \u003Ci>being an MLFlow backend itself\u003C/i>. This marries the best of both worlds: Data scientists don't need to learn yet another client as their code requires minimal to no changes, while GitLab provides everything else. There is no need to manage a server or to implement user management, so there is no need to configure your artifact storage –  this is all provided by the GitLab DevSecOps platform.\n\n## ML model experiment features in GitLab 16.0\n\nWatch this overview of the available features in 16.0:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uxweU4zT40c\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n- **Create experiments and candidates using the MLFlow client**: Simply point the MLFlow client to your GitLab project and experiments and runs will be recorded on GitLab, with no additional setup necessary and no need to create a server. Note that MLFlow runs are called \"candidates\" in GitLab, as each of them is a candidate to become a version of a model.\n\n- **User access management**: Experiments are tied to a GitLab project, making it easy to control which users have access to which models. \n\n- **Manage candidates directly on the GitLab UI**: Search and explore your logged experiments on GitLab, using the UI you already know.\n\n- **Download candidate data as a CSV**: Data scientists that want to explore or create reports on an experiment can download the necessary data as a CSV file.\n\nTo get started, refer to the [documentation](https://docs.gitlab.com/ee/user/project/ml/experiment_tracking/#machine-learning-model-experiments).\n\n### More to come\n\nGitLab wants to help you manage the entire lifecycle of your machine learning model from creation to packaging, deployment, and monitoring. \nFor more information on what we are working on, keep an eye on the MLOps Incubation Engineering [handbook page](/handbook/engineering/incubation/mlops/) and on our [YouTube playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0KpC6-JQy8lY4tNAZKXBaM_-).\n\nMachine Learning Model Experiments is an experimental feature available to all GitLab tiers, and we are looking for feedback so please [comment in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/381660).\n\nContinue reading our \"[AI/ML in DevSecOps](/blog/ai-ml-in-devsecops-series/)\" series.\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[786,478,230,9],{"slug":5989,"featured":6,"template":683},"track-machine-learning-model-experiments","content:en-us:blog:track-machine-learning-model-experiments.yml","Track Machine Learning Model Experiments","en-us/blog/track-machine-learning-model-experiments.yml","en-us/blog/track-machine-learning-model-experiments",{"_path":5995,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":5996,"content":6002,"config":6009,"_id":6011,"_type":13,"title":6012,"_source":15,"_file":6013,"_stem":6014,"_extension":18},"/en-us/blog/tracking-down-missing-tcp-keepalives",{"title":5997,"description":5998,"ogTitle":5997,"ogDescription":5998,"noIndex":6,"ogImage":5999,"ogUrl":6000,"ogSiteName":670,"ogType":671,"canonicalUrls":6000,"schema":6001},"Tracking TCP Keepalives: Lessons in Docker, Golang & GitLab","An in-depth recap of debugging a bug in the Docker client library.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680874/Blog/Hero%20Images/network.jpg","https://about.gitlab.com/blog/tracking-down-missing-tcp-keepalives","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What tracking down missing TCP Keepalives taught me about Docker, Golang, and GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n        \"datePublished\": \"2019-11-15\",\n      }",{"title":6003,"description":5998,"authors":6004,"heroImage":5999,"date":6006,"body":6007,"category":849,"tags":6008},"What tracking down missing TCP Keepalives taught me about Docker, Golang, and GitLab",[6005],"Stan Hu","2019-11-15","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2019-12-03.\n{: .alert .alert-info .note}\n\nWhat began as failure in a GitLab static analysis check led to a\ndizzying investigation that uncovered a subtle [bug in the Docker client\nlibrary code](https://github.com/docker/for-linux/issues/853) used by\nthe GitLab Runner. We ultimately worked around the problem by upgrading\nthe Go compiler, but in the process we uncovered an unexpected change in\nthe Go TCP keepalive defaults that fixed an issue with Docker and GitLab\nCI.\n\nThis investigation started on October 23, when backend engineer [Luke\nDuncalfe](/company/team/#.luke) mentioned, \"I'm seeing\n[`static-analysis` failures with no output](https://gitlab.com/gitlab-org/gitlab/-/jobs/331174397).\nIs there something wrong with this job?\" He opened [a GitLab\nissue](https://gitlab.com/gitlab-org/gitlab/issues/34951) to discuss.\n\nWhen Luke ran the static analysis check locally on his laptop, he saw\nuseful debugging output when the test failed. For example, an extraneous\nnewline would accurately be reported by Rubocop. However, when the same\ntest ran in GitLab's automated test infrastructure, the test failed\nquietly:\n\n![Failed job](https://about.gitlab.com/images/blogimages/docker-tcp-keepalive-debug/job-failure.png){: .shadow.center}\n\nNotice how the job log did not include any clues after the `bin/rake\nlint:all` step. This made it difficult to determine whether a real\nproblem existed, or whether this was just a flaky test.\n\nIn the ensuing days, numerous team members reported the same problem.\nNothing kills productivity like silent test failures.\n\n## Was something wrong with the test itself?\n\nIn the past, we had seen that if that specific test generated enough\nerrors, [the output buffer would fill up, and the continuous integration\n(CI) job would lock\nindefinitely](https://gitlab.com/gitlab-org/gitlab-foss/issues/61432). We\nthought we had [fixed that issue months\nago](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/28402). Upon\nfurther review, that fix seemed to eliminate any chance of a thread\ndeadlock.\n\nDid we have to flush the buffer? No, because the Linux kernel will do\nthat for an exiting process already.\n\n## Was there a change in how CI logs were handled?\n\nWhen a test runs in GitLab CI, the [GitLab\nRunner](https://gitlab.com/gitlab-org/gitlab-runner/) launches a Docker\ncontainer that runs commands specified by a `.gitlab-ci.yml` inside the\nproject repository. As the job runs, the runner streams the output to\nthe GitLab API via PATCH requests. The GitLab backend saves this data\ninto a file. The following sequence diagram shows how this works:\n\n```plantuml\n== Get a job! ==\nRunner -> GitLab: POST /api/v4/jobs/request\nGitLab -> Runner: 201 Job was scheduled\n\n== Job sends logs (1 of 2) ==\nRunner -> GitLab: PATCH /api/v4/job/:id/trace\nGitLab -> File: Save to disk\nGitLab -> Runner: 202 Accepted\n\n== Job sends logs (2 of 2) ==\nRunner -> GitLab: PATCH /api/v4/job/:id/trace\nGitLab -> File: Save to disk\nGitLab -> Runner: 202 Accepted\n```\n\n[Henrich Lee Yu](/company/team/#engwan) mentioned\nthat we had recently [disabled a feature flag that changed how GitLab\nhandled CI job\nlogs](https://docs.gitlab.com/ee/administration/job_logs.html#new-incremental-logging-architecture). [The\ntiming seemed to line\nup](https://gitlab.com/gitlab-org/gitlab/issues/34951#note_236723888).\n\nThis feature, called live CI traces, eliminates the need for a shared\nPOSIX filesystem (e.g., NFS) when saving job logs to disk by:\n\n1. Streaming data into memory via Redis\n2. Persisting the data in the database (PostgreSQL)\n3. Archiving the final data into object storage\n\nWhen this flag is enabled, the flow of CI job logs looks something like\nthe following:\n\n```plantuml\n== Get a job! ==\nRunner -> GitLab: POST /api/v4/jobs/request\nGitLab -> Runner: 201 Job was scheduled\n\n== Job sends logs ==\nRunner -> GitLab: PATCH /api/v4/job/:id/trace\nGitLab -> Redis: Save chunk\nGitLab -> Runner: 202 Accepted\n...\n== Copy 128 KB chunks from Redis to database ==\nGitLab -> Redis: GET gitlab:ci:trace:id:chunks:0\nGitLab -> PostgreSQL: INSERT INTO ci_build_trace_chunks\n...\n== Job finishes ==\n\nRunner -> GitLab: PUT /api/v4/job/:id\nGitLab -> Runner: 200 Job was updated\n\n== Archive trace to object storage ==\n```\n\nLooking at the flow diagram above, we see that this approach has more\nsteps. After receiving data from the runner, something could have gone\nwrong with handling a chunk of data. However, we still had many\nquestions:\n\n1. Did the runners send the right data in the first place?\n1. Did GitLab drop a chunk of data somewhere?\n1. Did this new feature actually have anything to do with the problem?\n1. Are they really making another Gremlins movie?\n\n## Reproducing the bug: Simplify the `.gitlab-ci.yml`\n\nTo help answer those questions, we simplified the `.gitlab-ci.yml` to\nrun only the `static-analysis` step. We inserted a known Rubocop error,\nreplacing a `eq` with `eql`. We first ran this test on a separate GitLab\ninstance with a private runner. No luck there – the job showed the right\noutput:\n\n```\nOffenses:\n\nee/spec/models/project_spec.rb:55:42: C: RSpec/BeEql: Prefer be over eql.\n        expect(described_class.count).to eql(2)\n                                         ^^^\n\n12669 files inspected, 1 offense detected\n```\n\nHowever, we repeated the test on our staging server and found that we\nreproduced the original problem. In addition, the live CI trace feature\nflag had been activated on staging. Since the problem occurred with and\nwithout the feature, we could eliminate that feature as a possible\ncause.\n\nPerhaps something with the GitLab server environment caused a\nproblem. For example, could the load balancers be rate-limiting the\nrunners? As an experiment, we pointed a private runner at the staging\nserver and re-ran the test. This time, it succeeded: the output was\nshown. That seemed to suggest that the problem had more to do with the\nrunner than with the server.\n\n## Docker Machine vs. Docker\n\nOne key difference between the two tests: One runner used a shared,\nautoscaled runner using a [Docker\nMachine](https://docs.docker.com/machine/overview/) executor, and the\nprivate runner used a [Docker\nexecutor](https://docs.gitlab.com/runner/executors/docker.html).\n\nWhat does Docker Machine do exactly? The following diagram may help\nillustrate:\n\n![Docker Machine](https://docs.docker.com/machine/img/machine.png){: .medium.center}\n\nThe top-left shows a local Docker instance. When you run Docker from the\ncommand-line interface (e.g., `docker attach my-container`), the program\njust makes [REST calls to the Docker Engine\nAPI](https://docs.docker.com/engine/api/v1.40/).\n\nThe rest of the diagram shows how Docker Machine fits into the\npicture. Docker Machine is an entirely separate program. The GitLab\nRunner shells out to `docker-machine` to create and destroy virtual\nmachines using cloud-specific (e.g. Amazon, Google, etc.) drivers. Once\na machine is running, the runner then uses the Docker Engine API to run,\nwatch, and stop containers.\n\nNote that this API is used securely over an HTTPS connection. This is an\nimportant difference between the Docker Machine executor and Docker\nexecutor: The former needs to communicate across the network, while the\nlatter can either use a local TCP socket or UNIX domain socket.\n\n## Google Cloud Platform timeouts\n\nWe've known for a while that Google Cloud [has a 10-minute idle\ntimeout](https://cloud.google.com/compute/docs/troubleshooting/general-tips),\nwhich has caused issues in the past:\n\n> Note that idle connections are tracked for a maximum of 10 minutes,\n> after which their traffic is subject to firewall rules, including the\n> implied deny ingress rule. If your instance initiates or accepts\n> long-lived connections with an external host, you should adjust TCP\n> keep-alive settings on your Compute Engine instances to less than 600\n> seconds to ensure that connections are refreshed before the timeout\n> occurs.\n\nWas the problem caused by this timeout? With the Docker Machine\nexecutor, we found that we could reproduce the problem with a simple\n`.gitlab-ci.yml`:\n\n```yaml\nimage: \"busybox:latest\"\n\ntest:\n  script:\n    - date\n    - sleep 601\n    - echo \"Hello world!\"\n    - date\n    - exit 1\n```\n\nThis would reproduce the failure, where we would never see the `Hello\nworld!` output. Changing the `sleep 601` to `sleep 599` would make the\nproblem go away. Hurrah! All we have to do is tweak the system TCP\nkeepalives, right? Google provided these sensible settings:\n\n```sh\nsudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5\n```\n\nHowever, enabling these kernel-level settings didn't solve the\nproblem. Were keepalives even being sent? Or was there some other issue?\nWe turned our attention to network traces.\n\n## Eavesdropping on Docker traffic\n\nIn order to understand what was happening, we needed to be able to\nmonitor the network communication between the runner and the Docker\ncontainer. But how exactly does the GitLab Runner stream data from a\nDocker container to the GitLab server?  The following diagram\nillustrates the flow:\n\n```plantuml\nRunner -> Docker: POST /containers/name/attach\nDocker -> Runner: \u003Ccontainer output>\nDocker -> Runner: \u003Ccontainer output>\nRunner -> GitLab: PATCH /api/v4/job/:id/trace\nGitLab -> File: Save to disk\nGitLab -> Runner: 202 Accepted\n```\n\nFirst, the runner makes a [POST request to attach to the container\noutput](https://docs.docker.com/engine/api/v1.40/#operation/ContainerAttach).\nAs soon as a process running in the container outputs some data, Docker\nwill transmit the data over this HTTPS stream. The runner then copies\nthis data to GitLab via the PATCH request.\n\nHowever, as mentioned earlier, traffic between a GitLab Runner and the\nremote Docker machine is encrypted over HTTPS on port 2376. Was there an\neasy way to disable HTTPS? Searching through the code of Docker Machine,\nwe found that it did not appear to be supported out of the box.\n\nSince we couldn't disable HTTPS, we had two ways to eavesdrop:\n\n1. Use a man-in-the-middle proxy (e.g. [mitmproxy](https://mitmproxy.org/))\n1. Record the traffic and decrypt the traffic later using the private keys\n\n## Ok, let's be the man-in-the-middle!\n\nThe first seemed more straightforward, since [we already had experience\ndoing this with the Docker\nclient](https://docs.gitlab.com/ee/administration/packages/container_registry.html#running-the-docker-daemon-with-a-proxy).\n\nHowever, after [defining the proxy variables for GitLab\nRunner](https://docs.gitlab.com/runner/configuration/proxy.html#adding-proxy-variables-to-the-runner-config),\nwe found we were only able to intercept the GitLab API calls with\n`mitmproxy`. The Docker API calls still went directly to the remote\nhost. Something wasn't obeying the proxy configuration, but we didn't\ninvestigate further. We tried the second approach.\n\n## Decrypting TLS data\n\nTo decrypt TLS data, we would need to obtain the encryption keys. Where\nwere these located for a newly-created system with `docker-machine`? It\nturns out `docker-machine` worked in the following way:\n\n1. Call the Google Cloud API to create a new machine\n1. Create a `/root/.docker/machine/machines/:machine_name` directory\n1. Generate a new SSH keypair\n1. Install the SSH key on the server\n1. Generate a new TLS certificate and key\n1. Install and configure Docker on the newly-created machine with TLS certificates\n\nAs long as the machine runs, the directory will contain the information\nneeded to decode this traffic. We ran `tcpdump` and saved the private keys.\n\nOur first attempt at decoding the traffic failed. Wireshark could not\ndecode the encrypted traffic, although general TCP traffic could still\nbe seen. Researching more, we found out why: If the encrypted traffic\nused a [Diffie-Hellman key\nexchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange),\nhaving the private keys would not suffice! This is by design, a property\ncalled [perfect forward\nsecrecy](https://en.m.wikipedia.org/wiki/Forward_secrecy).\n\nTo get around that limitation, we modified the GitLab Runner to disable\ncipher suites that used the Diffie-Hellman key exchange:\n\n```diff\ndiff --git a/vendor/github.com/docker/go-connections/tlsconfig/config_client_ciphers.go b/vendor/github.com/docker/go-connections/tlsconfig/config_client_ciphers.go\nindex 6b4c6a7c0..a3f86d756 100644\n",[266,3058,533,1396,1021,1396,872,1124,9],{"slug":6010,"featured":6,"template":683},"tracking-down-missing-tcp-keepalives","content:en-us:blog:tracking-down-missing-tcp-keepalives.yml","Tracking Down Missing Tcp Keepalives","en-us/blog/tracking-down-missing-tcp-keepalives.yml","en-us/blog/tracking-down-missing-tcp-keepalives",{"_path":6016,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6017,"content":6022,"config":6028,"_id":6030,"_type":13,"title":6031,"_source":15,"_file":6032,"_stem":6033,"_extension":18},"/en-us/blog/training-and-deploying-ai-models-with-gitlab-and-vertex-ai",{"title":6018,"description":6019,"ogTitle":6018,"ogDescription":6019,"noIndex":6,"ogImage":906,"ogUrl":6020,"ogSiteName":670,"ogType":671,"canonicalUrls":6020,"schema":6021},"Train and deploy AI models with GitLab and Google Cloud's Vertex AI","Demo of GitLab's DevSecOps capabilities combined with Vertex AI's scalable ML platform, designed with the aim of rapid and secure AI deployments.","https://about.gitlab.com/blog/training-and-deploying-ai-models-with-gitlab-and-vertex-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Train and deploy AI models with GitLab and Google Cloud's Vertex AI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2023-06-08\",\n      }",{"title":6018,"description":6019,"authors":6023,"heroImage":906,"date":6025,"body":6026,"category":806,"tags":6027},[6024],"Regnard Raquedan","2023-06-08","\n\u003Ci>This blog is the latest post in an ongoing series about GitLab's journey to \u003Ca href=\"/blog/ai-ml-in-devsecops-series/\">build and integrate AI/ML into our DevSecOps platform\u003C/a>. The first blog post can be found \u003Ca href=\"/blog/what-the-ml-ai/\">here\u003C/a>. Throughout the series, we'll feature blogs from our product, engineering, and UX teams to showcase how we're infusing AI/ML into GitLab.\u003C/i>\n\nMost development and engineering teams are now tasked with maintaining and deploying AI/ML-related code. In this context, the focus on security and efficiency becomes even more crucial. Companies are keen to capitalize on the benefits of AI swiftly while striving to decrease potential risks. GitLab can be used to orchestrate any AI/ML workloads, enabling teams to rapidly develop new generative AI capabilities. [GitLab recently announced a partnership with Google](https://about.gitlab.com/press/releases/2023-05-02-gitLab-and-google-cloud-partner-to-expand-ai-assisted-capabilities.html) to bring [generative AI on Google Cloud](https://cloud.google.com/ai/generative-ai) to our mutual customers.\n\nThis is a tutorial of how to use these tools to deploy an AI model with [Google Cloud's Vertex AI](https://cloud.google.com/vertex-ai) using GitLab to orchestrate the [ModelOps workload](https://about.gitlab.com/direction/modelops/). Our custom model training use case is simple introductory credit card fraud detection, a pertinent issue in the financial industry.\n\n## The solution\nOur solution is a Python-based credit card transaction fraud detection app. Once deployed, applications can use an API endpoint to make predictions on whether a submitted transaction is fraudulent or not.\n\n[Vertex AI](https://cloud.google.com/vertex-ai/docs) is Google Cloud's flagship AI/ML platform that lets users train and deploy machine learning models and AI applications. This is the platform where the API endpoint and model are hosted. While Vertex AI can handle training using prebuilt functions, this demo uses a custom training script written in Python.\n\nFor the demo’s purposes, GitLab hosts the [application source code](https://gitlab.com/gitlab-com/alliances/google/sandbox-projects/demos/vertex-ai) and helps to ensure quality and security by running the tests and scans automatically. We also use GitLab's CI/CD to execute the Python code, programmatically upload the resulting artifacts to Google Cloud Storage, and create the endpoint in Vertex AI.\n\nLet's take a high-level look at how the solution is designed and what it does:\n* Data preprocessing: To effectively detect fraudulent transactions, we address the initial imbalance in the raw transaction data. By employing the [Synthetic Minority Over-sampling Technique (SMOTE)](https://imbalanced-learn.org/stable/references/generated/imblearn.over_sampling.SMOTE.html), we duplicate instances of the minority class, enhancing the model's ability to identify patterns.\n* Model training: Using the balanced dataset, we train a [RandomForestClassifier](https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.RandomForestClassifier.html) model. This creates a 'forest' of decision trees, each based on a random subset of the training data. It outputs the mode of the classes determined by the individual trees, making it well-suited for binary outcomes, such as identifying fraudulent transactions. The trained model is stored in a Google Cloud Storage bucket for later use.\n* Model deployment: Leveraging GitLab's DevSecOps platform, model deployment becomes straightforward. By committing the code to GitLab, the trained model is automatically deployed to Vertex AI. Subsequently, the API endpoint is also established.\n\n## Prerequisites\nBefore we dive into the details, let's make sure you have everything you need to get started with deploying your AI model using GitLab and Vertex AI.\n\nHere are the requirements:\n1. Google Cloud project\n1. Google Cloud service account with these permissions:\n   1. AI Platform Admin\n   1. Service Account User\n   1. Storage Admin\n   1. Storage Object Admin\n   1. Vertex AI Administrator\n1. GitLab project\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube-nocookie.com/embed/p7GTsbSQWF4\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n## Demo walkthrough\nFollowing the [video walkthrough](https://youtu.be/p7GTsbSQWF4), here's a guide for setting up an AI pipeline with GitLab and Google Cloud's Vertex AI.\n\n### Step 1: GitLab and Google Cloud connection\nFirstly, we need GitLab to interact with Google Cloud. Insert your Google Cloud Service Account credentials into your GitLab project's environment variables (make sure they're Base64 encoded for security).\n\n### Step 2: Uploading data to Vertex AI\nMove to the Vertex AI section in Google Cloud. Here, [create and upload your dataset](https://cloud.google.com/vertex-ai/docs/tabular-data/forecasting/create-dataset). In our demo, we use a 'Tabular' dataset for 'Classification' as we're predicting credit card fraud.\n\n### Step 3: Creating the CI/CD pipeline\nBack to GitLab to structure our [CI/CD pipeline](https://gitlab.com/gitlab-com/alliances/google/sandbox-projects/demos/vertex-ai/-/ci/editor). It comprises three stages:\n\n**Test:** Quality and security checks.\n\n**Train:** Executes a Python script to train the model, outputting a .pkl  artifact.\n\n```\ntrain:\n stage: train\n script:\n   - apt-get update && apt-get install -y python3-pip python3-venv\n   - python3 -m venv venv\n   - source venv/bin/activate\n   - pip install --upgrade pip\n   - pip install pandas scikit-learn joblib imbalanced-learn google-cloud-storage\n   - python3 src/train.py\n artifacts:\n   paths:\n     - model.pkl\n```\n\n**Deploy:** Uses Google Cloud's Deep Learning platform container to deploy the trained model on Vertex AI.\n\n```\ndeploy:\n stage: deploy\n image:\n   name: us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-5\n   entrypoint: [\"\"]\n script:\n   - python src/deploy.py\n dependencies:\n   - train\n only:\n   - main\n```\n\n### Step 4: Model training\nThe [training code](https://gitlab.com/gitlab-com/alliances/google/sandbox-projects/demos/vertex-ai/-/blob/main/src/train.py), running on GitLab CI/CD, fetches data from Vertex AI, processes it, trains our RandomForestClassifier model, and saves the model to Google Cloud Storage.\n\n### Step 5: Model deployment\nThe [deployment script](https://gitlab.com/gitlab-com/alliances/google/sandbox-projects/demos/vertex-ai/-/blob/main/src/deploy.py) creates an endpoint on Vertex AI and deploys our trained model there, utilizing the service account credentials we set initially.\n\n### Step 6: Prediction testing\n\n![Screenshot of Vertex AI](https://about.gitlab.com/images/blogimages/vertex-ai-screenshot.png)\n\nFinally, within Vertex AI, navigate to your model and test its predictions using an input JSON request. If all goes well, you'll get a response from your model.\n\nThere you have it: an AI pipeline with GitLab and Google Cloud's Vertex AI. This combination of GitLab's DevSecOps capabilities with Vertex AI's scalable ML platform is designed with the aim of rapid and secure AI deployments.\n",[703,701,9,786],{"slug":6029,"featured":6,"template":683},"training-and-deploying-ai-models-with-gitlab-and-vertex-ai","content:en-us:blog:training-and-deploying-ai-models-with-gitlab-and-vertex-ai.yml","Training And Deploying Ai Models With Gitlab And Vertex Ai","en-us/blog/training-and-deploying-ai-models-with-gitlab-and-vertex-ai.yml","en-us/blog/training-and-deploying-ai-models-with-gitlab-and-vertex-ai",{"_path":6035,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6036,"content":6042,"config":6047,"_id":6049,"_type":13,"title":6050,"_source":15,"_file":6051,"_stem":6052,"_extension":18},"/en-us/blog/transform-code-quality-and-compliance-with-automated-processes",{"title":6037,"description":6038,"ogTitle":6037,"ogDescription":6038,"noIndex":6,"ogImage":6039,"ogUrl":6040,"ogSiteName":670,"ogType":671,"canonicalUrls":6040,"schema":6041},"Transform code quality and compliance with automated processes","Learn how GitLab Premium features address the technical debt and security vulnerability challenges that plague traditional approaches.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","https://about.gitlab.com/blog/transform-code-quality-and-compliance-with-automated-processes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Transform code quality and compliance with automated processes\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jessica Hurwitz\"}],\n        \"datePublished\": \"2024-12-13\",\n      }",{"title":6037,"description":6038,"authors":6043,"heroImage":6039,"date":6044,"body":6045,"category":701,"tags":6046},[951],"2024-12-13","While manual code review processes may suffice for a small team, as DevSecOps teams scale, the processes create significant bottlenecks that impede software development velocity and quality. Often slow, inconsistent, and frequently failing to catch critical vulnerabilities, the manual approach leads to technical debt and increased security risks.\n\nTo mitigate risks and drive innovation, organizations must prioritize automated code quality and compliance systems. The financial implications of poor code management are substantial, with technical debt consuming up to 40% of IT budgets ([McKinsey Digital: Tech Debt Report](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity)) and software vulnerabilities costing an average of $4.88 million per security breach ([IBM Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach)). \n\nModern software development requires a strategic approach to code management and compliance that goes beyond traditional review processes. With more robust review systems and compliance controls, organizations can innovate and secure software faster than their competitors.\n\n## The power of code review and approval processes\n\nAccording to the [GitLab 2024 Global DevSecOps Report](https://about.gitlab.com/developer-survey/), C-level executives rank code quality as one of the top benefits of DevSecOps. With executives recognizing code quality as a strategic priority, systematic review processes have emerged as a cornerstone of modern development practices. \n\n[Code review](https://about.gitlab.com/topics/version-control/what-is-code-review/) processes benefit developers through knowledge sharing, the discovery of bugs earlier in the process, and improved security. However, developers say the top changes that could be made to improve job satisfaction are increasing automation and collaboration, according to our survey.\n\nAs code quality and code review processes are embedded into the software development lifecycle, focusing on systems that remove manual code review and enhance collaboration across teams will help keep developer workflows running smoothly. \n\n### Code review processes increase collaboration and development speed\n\nThe improvement in organizational efficiency can be seen in this example with [Airbus Intelligence](https://about.gitlab.com/customers/airbus/), a leader in the geospatial industry. The development teams at Airbus struggled with inefficient processes and needed tools that could help their team collaborate efficiently across the globe. After adopting GitLab Premium, Airbus quickly noticed the improvement in code quality. \n\nGitLab CI’s built-in security testing meant developers could identify bugs and vulnerabilities before they reached production. Instead of spending a full day setting up for production and doing manual tests, those simple tasks are now automated. \n\nAirbus’ release time dramatically decreased from 24 hours to just 10 minutes. \n\n“What used to happen is we would touch one part of the code and it would break another part. Now, each time a developer pushes code, we can immediately identify problems,” said Logan Weber, Software Automation Engineer at Airbus Defense and Space, Intelligence.\n\n### Features that enable higher code quality\n\nPowerful GitLab Premium features like [Multiple Approvers for Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html), [Code Quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html) checks integration with third-party code quality solutions, and [Protected Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html), enable companies to innovate faster than their competitors. \n\nBy reducing review cycle times while strengthening code integrity and compliance, DevSecOps teams address both the technical debt and security vulnerability challenges that plague traditional approaches. These security benefits help teams like AirBus Intelligence develop faster, more secure solutions.  \n\n## Why enhanced compliance controls matter\n\nThe implementation of effective code compliance strategies is constantly evolving due to [changing regulations](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), and keeping up with these regulations is a challenge for most companies. \n\nBy developing code compliance strategies and automated control mechanisms, companies ensure that quality and compliance policies are met. \n\nFor Airbus Intelligence, security and vulnerability scans built into integration testing enabled teams to catch security and compliance issues earlier in the process.\n\n[Continuous integration](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-integration-ci) gives teams visibility into more projects and allows all team members to manage deployments. Expanded access controls improve cross-team collaboration and accountability. \n\n### Features that increase accountability \n\nGitLab Premium's [advanced compliance controls](https://about.gitlab.com/solutions/security-compliance/) create an unbroken chain of accountability throughout the development process, enabling organizations to systematically track and validate every code change.\n\nUsers have greater auditability of any change and can track commits. This is in addition to strict [access controls](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html) that provide specific people with the ability to push and merge changes. With [audit logs](https://docs.gitlab.com/ee/user/compliance/audit_event_types.html), users can track and review changes and activities within the repository.\n\n## Ship software faster with GitLab Premium\n\n“It’s simple. All teams operate around this one tool. Instantly, that made communication easier. We wouldn’t be where we are today if we didn’t have GitLab in our stack,” according to Airbus' Weber.\n\nGitLab Premium represents more than just a tool — it's a comprehensive approach to software engineering that empowers development teams to deliver high-quality, secure, and efficient software solutions. \n\n> #### Discover why [customers are upgrading to GitLab Premium](https://about.gitlab.com/pricing/premium/why-upgrade/).",[1396,871,478,701,704,9],{"slug":6048,"featured":6,"template":683},"transform-code-quality-and-compliance-with-automated-processes","content:en-us:blog:transform-code-quality-and-compliance-with-automated-processes.yml","Transform Code Quality And Compliance With Automated Processes","en-us/blog/transform-code-quality-and-compliance-with-automated-processes.yml","en-us/blog/transform-code-quality-and-compliance-with-automated-processes",{"_path":6054,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6055,"content":6061,"config":6066,"_id":6068,"_type":13,"title":6069,"_source":15,"_file":6070,"_stem":6071,"_extension":18},"/en-us/blog/troubleshoot-delays-with-code-review-analytics",{"title":6056,"description":6057,"ogTitle":6056,"ogDescription":6057,"noIndex":6,"ogImage":6058,"ogUrl":6059,"ogSiteName":670,"ogType":671,"canonicalUrls":6059,"schema":6060},"Troubleshoot delays with our Code Review Analytics tool","Introduced in GitLab 12.7, Code Review Analytics can help you dig deeper into slow-moving merge requests.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681140/Blog/Hero%20Images/code_review_analytics.png","https://about.gitlab.com/blog/troubleshoot-delays-with-code-review-analytics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Troubleshoot delays with our Code Review Analytics tool\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Ward\"}],\n        \"datePublished\": \"2020-03-18\",\n      }",{"title":6056,"description":6057,"authors":6062,"heroImage":6058,"date":6063,"body":6064,"category":678,"tags":6065},[1080],"2020-03-18","\n\nModern software development moves fast. Development teams can fix issues and have a release deployed to customers within minutes, all fed through a continuous testing, build, and deployment process. Thanks to containerization, development teams can experiment with new techniques and technologies for particular application services, without affecting an application as a whole.\n\nBut with this speed and potential pace of change, it's easy to lose sight of what matters: Are any of these changes important for customers and their needs, or do they bring any business value? This is what [Value Stream Analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html) hopes to answer.\n\nDrawing on lessons learned from the lean movement, delivery teams, engineering managers, and directors are applying \"[value stream mapping](https://en.wikipedia.org/wiki/Value-stream_mapping)\" to understand and optimize delivery of value, from the time an idea is born to its impact on the business in production. GitLab's analytics capabilities provide near real-time insights into the flow of value through the team's value stream without requiring complex system integrations, configuration, or add-on tools.\n\nAt the highest project overview level Value Stream Analytics ([since GitLab 12.3](/releases/2019/09/22/gitlab-12-3-released/#analytics-workspace), and previously called \"cycle analytics\") helps measure the velocity of development cycles in your team, and the time it takes them from planning to monitoring for each project. Currently, it tracks the seven stages to make calculations, and the associated feature:\n\n-   **Issue (Tracker)**: Time to schedule an issue (by milestone or by adding it to an issue board)\n-   **Plan (Board)**: Time to first commit\n-   **Code (IDE)**: Time to create a merge request\n-   **Test (CI)**: Time it takes GitLab CI/CD to test your code\n-   **Review (Merge Request/MR)**: Time spent on code review. Measures the median time taken to review the merge request that has the closing issue pattern, between its creation and until it's merged.\n-   **Staging (Continuous Deployment)**: Time between merging and deploying to production\n-   **Total (Total)**: Total lifecycle time. That is the velocity of the project or team. Previously known as production.\n\nIf the Value Stream Analytics feature shows that reviews are your team's most time-consuming step or your team agrees that code review is moving too slowly, then it's time to dig deeper. [GitLab 12.7](/releases/2020/01/22/gitlab-12-7-released/#code-review-analytics) introduced [Code Review Analytics](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html) to help you dig deeper into slow-moving merge requests and understand what is causing delays. \n\nIn our 2019 and 2020 [developer surveys](/developer-survey/), delays in code review featured near the top of developer process painpoints. Code review is not as time consuming as testing (the unanimous winner in 2019 and 2020), but respondents aknowledged they need more help to speed up the code reviews. This initial release of Code Review Analytics is a first step toward providing greater insight into delays and bottlenecks during the code review process.\n\nYou can find the Code Review dashboard under the menu for your project, then _Project Analytics > Code Review_. The view is a table of open merge requests with at least one non-author comment, and review time is measured from the first non-author comment. You can also see a summary of the changes introduced by the merge request, the number of comments, commits, and the approvers needed. The default sort order is from the oldest merge request, but you can filter results using the search box above the table. By highlighting aged Code Reviews, teams are encouraged to complete work-in-process rather than picking up new items from the backlog and to dispose of the \"inventory\" waste of unmerged commits.\n\n![Code analytics dashboard](https://about.gitlab.com/images/blogimages/code_review_analytics.png){: .shadow.medium.center}\n\nClicking the title of the merge request takes you to a normal merge request view where you can recap the discussions and activity so far to debug problems such as:\n\n-   If there are many comments or commits, perhaps the code is too complex.\n-   If a particular author is involved, maybe more training is required.\n-   If no or few comments and approvers appear, your team may be understaffed or may be in the habit of starting new work instead of assisting teammates to close MRs and deliver features.\n\nWe will be bringing improvements and more features to code review analytics over the coming months, and in the meantime we welcome your feedback.\n\n### About the guest author\n\n_Chris is a freelance technical communicator for numerous developer-focused companies. Happy creating text, videos, courses, and interactive learning experiences, in his spare time he writes games and interactive fiction._\n",[871,9,680],{"slug":6067,"featured":6,"template":683},"troubleshoot-delays-with-code-review-analytics","content:en-us:blog:troubleshoot-delays-with-code-review-analytics.yml","Troubleshoot Delays With Code Review Analytics","en-us/blog/troubleshoot-delays-with-code-review-analytics.yml","en-us/blog/troubleshoot-delays-with-code-review-analytics",{"_path":6073,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6074,"content":6080,"config":6085,"_id":6087,"_type":13,"title":6088,"_source":15,"_file":6089,"_stem":6090,"_extension":18},"/en-us/blog/try-dependency-scanning",{"title":6075,"description":6076,"ogTitle":6075,"ogDescription":6076,"noIndex":6,"ogImage":6077,"ogUrl":6078,"ogSiteName":670,"ogType":671,"canonicalUrls":6078,"schema":6079},"A quick guide to GitLab Dependency Scanning","A walk through of creating a quick example project in order to see Dependency Scanning in action.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681849/Blog/Hero%20Images/iceberg_header.jpg","https://about.gitlab.com/blog/try-dependency-scanning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A quick guide to GitLab Dependency Scanning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n        \"datePublished\": \"2021-01-14\",\n      }",{"title":6075,"description":6076,"authors":6081,"heroImage":6077,"date":6082,"body":6083,"category":1353,"tags":6084},[1589],"2021-01-14","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAre you curious about our Secure offerings? They are easy, and free, to try out!\n\nI suggest you create a free demo project to check them out and see if it's something you might want. \n\nDid you know? If you have a public project on GitLab.com you can enable our Secure scanning functionality. Please note that [educational institutions](https://about.gitlab.com/solutions/education/) and [open-source projects](https://about.gitlab.com/solutions/open-source/join/) can also request free licenses.\n\nIn this blog I will walk you through creating a new demo project, adding Dependency Scanning, and reviewing the results of the scan. Following the steps below should take you 15 minutes.\n\n### Create a test project\n\nLet's grab a test project and enable Dependency Scanning.\n\n1. [Sign in](https://gitlab.com/users/sign_in) to your GitLab account.\n1. Create a new project by clicking \"New project\" on your [project list](https://gitlab.com/dashboard/projects).\n![New project](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/01_new_project.png){: .shadow.center}\n1. Select the \"Create from template\" option.\n1. Select a project template. Be sure to choose one that is written in one of our [supported languages and package managers](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers). I have chosen a [Ruby on Rails template](https://gitlab.com/gitlab-org/project-templates/rails).\n![Project from template](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/02_from_template.png){: .shadow.center}\n1. Click the \"Use template\" button.\n1. You need to name your project. I named mine \"mytestrubyonrails\". **Be sure to set the Visibility level to \"Public\"**.\n![Template settings](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/03_template_settings.png){: .shadow.center}\n1. You now have a new project.\n![Your new project](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/04_new_project.png){: .shadow.center}\n\n### Configure Dependency Scanning to run in the pipeline\n\n#### Create a new file in your project\n\n1. Click \"New file\".\n![Add a new file](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/05_new_file.png){: .shadow.center}\n1. You have two choices to populate the file - Template or Advanced.\n\n#### Use the template to fill `.gitlab-ci.yml`\n\n1. On the `New file` page choose \"Select a template type > .gitlab-ci.yml\".\n![pick yml as file template](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/06_yml_template.png){: .shadow.center}\n1. Select \"Apply a template > Dependency-Scanning\".\n![dependency scanning template yml](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/07_yml_ds.png){: .shadow.center}\n\n#### Advanced - manually enter data into `.gitlab-ci.yml`\n\n1. On the `New file` page name the file `.gitlab-ci.yml`.\n1. Insert the necessary lines of code per our [user documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration).\n\n```\n   stages:\n   - test\n   - qa\n\n   include:\n   - template: Dependency-Scanning.gitlab-ci.yml\n\n   dependency_scanning:\n   stage: test\n   variables:\n     CI_DEBUG_TRACE: \"true\"\n```\n\n![advanced yml](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/08_yml_advanced.png){: .shadow.center}\n\n#### Commit the file\n\n1. Add a commit message if you want.\n1. Change the \"Target Branch\" from \"master\" to something else - for example \"add-ds\", and leave the \"Start a new merge request with these changes\" box checked.\n![dependency scanning template rename target](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/07_yml_template_rename.png){: .shadow.center}\n1. Click \"Commit changes\".\n1. A \"New Merge Request\" page will load. Scroll to the bottom and click \"Submit merge request\".\n![dependency scanning template merge request part 1](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/07_yml_template_mr_01.png){: .shadow.center}\n![dependency scanning template merge request part 2](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/07_yml_template_mr_02.png){: .shadow.center}\n1. The pipeline will now run.\n\n### View pipeline results\n\nNow that you have your first pipeline, this and any future pipeline will run the Dependency Scanning jobs. You can review the results after a pipeline completes by:\n  1. View the Merge request - look at the security MR report area.\n![merge request security report](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/09_mr_report.png){: .shadow.center}\n  1. Click expand to see the details.\n![expanded merge request security report](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/10_mr_report_expanded.png){: .shadow.center}\n  1. You can also view the Security tab in the pipeline.\n![security tab in the pipeline](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/11_pipeline_security_tab.png){: .shadow.center}\n\nNote: For this example we are going to decide not to act on the findings as part of the merge request, and we have not configured [security merge request approvals](https://docs.gitlab.com/ee/user/application_security/index.html#security-approvals-in-merge-requests) so findings do not require additional approvers before you are permitted to merge.\n\nYou can see [my example merge request](https://gitlab.com/NicoleSchwartz/mytestrubyonrails/-/merge_requests/1).\n\n### View results outside of the merge request\n\nFirst, merge this request in to master for your test project. The results will not show outside of the merge request until this is done.\n\nNow you can see the findings by navigating to the [Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n![navigate to the security dashboard](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/navigate_dashboard.png){: .shadow.center}\n![the security dashboard](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/dashboard.png){: .shadow.center}\n\nYou can view just the dependencies and their found issues by viewing the [Dependency List](https://docs.gitlab.com/ee/user/application_security/dependency_list/).\n![navigate to the dependency list](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/navigate_d_list.png){: .shadow.center}\n![the dependency list](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/dependency_list.png){: .shadow.center}\n![expand a row in the dependency list](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/dependency_list_expanded.png){: .shadow.center}\nYou can see [my dependency list](https://gitlab.com/NicoleSchwartz/mytestrubyonrails/-/dependencies).\n\nYou can click on a finding in the dashboard to see more details. This takes you to the vulnerability's page.\n![stand alone vulnerability's page](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/stand_alone_vuln.png){: .shadow.center}\n\nOn the vulnerability's page you can decide to set the status (dismiss, confirm, resolve) after triaging.\n![stand alone vulnerabilities status](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/stand_alone_vuln_status.png){: .shadow.center}\nYou can [see my example finding](https://gitlab.com/NicoleSchwartz/mytestrubyonrails/-/security/vulnerabilities/4085028).\n\nYou can create an issue from a vulnerability.\n![stand alone vulnerabilities created issue](https://about.gitlab.com/images/blogimages/2020-unfiltered-try-dependency-scanning/issue_created.png){: .shadow.center}\nYou can [see my example issue](https://gitlab.com/NicoleSchwartz/mytestrubyonrails/-/issues/1).\n\nNow go on and try it yourself!\n\nIf the above blog walkthrough of creating a demo project and running Dependency Scanning got you curious you can [read more about Dependency Scanning in our user documentation](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/).\n\nIf you would rather try a different type of Secure scanner - they are all just as easy to set up [read more about our Secure scanning tools in our user documentation](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools).\n\n[Cover image](https://flic.kr/p/4SyNQi) by [Alan Light](https://www.flickr.com/people/alan-light/), licensed under [Attribution 2.0 Generic (CC BY 2.0)](https://creativecommons.org/licenses/by/2.0/)\n{: .note}\n",[9,704,976],{"slug":6086,"featured":6,"template":683},"try-dependency-scanning","content:en-us:blog:try-dependency-scanning.yml","Try Dependency Scanning","en-us/blog/try-dependency-scanning.yml","en-us/blog/try-dependency-scanning",{"_path":6092,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6093,"content":6099,"config":6105,"_id":6107,"_type":13,"title":6108,"_source":15,"_file":6109,"_stem":6110,"_extension":18},"/en-us/blog/try-out-new-way-to-migrate-projects",{"title":6094,"description":6095,"ogTitle":6094,"ogDescription":6095,"noIndex":6,"ogImage":6096,"ogUrl":6097,"ogSiteName":670,"ogType":671,"canonicalUrls":6097,"schema":6098},"Moving projects easily: GitLab migration automation benefits","Learn how our new direct transfer feature, in beta, is speeding migrations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668857/Blog/Hero%20Images/migration.jpg","https://about.gitlab.com/blog/try-out-new-way-to-migrate-projects","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab project migration and automation - a perfect pair for faster, easier transfers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n        \"datePublished\": \"2023-01-18\",\n      }",{"title":6100,"description":6095,"authors":6101,"heroImage":6096,"date":6102,"body":6103,"category":1513,"tags":6104},"GitLab project migration and automation - a perfect pair for faster, easier transfers",[3330],"2023-01-18","\n\nSince Version 14.3, GitLab has supported [migrating GitLab groups by direct transfer](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended), where, rather than manually uploading export files, data is transferred directly from the source instance to the destination instance. We have been working to extend this functionality to projects and are including the ability to migrate projects by direct transfer as a beta in GitLab 15.8.\n\nThis beta feature is **available to everyone**, enabled by default on GitLab.com and with [some configuration](#availability-of-the-feature)\non self-managed GitLab instances.\n\n## Benefits of the direct transfer method\n\nMigrating by direct transfer enables you to easily migrate GitLab group and project resources between GitLab instances and within the same GitLab\ninstance, using either the UI or API.\n\nThis is a major improvement from migrating [groups](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-uploading-an-export-file-deprecated) and [projects using file exports](https://docs.gitlab.com/ee/user/project/settings/import_export.html) because:\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 any top-level group you have the Owner role for (plus subgroups when using API) and all its projects can be migrated automatically, making your work more efficient.\n- When migrating from GitLab Self-Managed to GitLab.com, user associations (such as comment author) previously were linked to the user who ran the import. Migration using direct transfer maps users and their contributions correctly, provided [a few conditions are met](https://docs.gitlab.com/ee/user/group/import/#preparation).\n\n## Availability of the feature\n\nThe beta release for migrating GitLab projects with top-level groups by direct transfer is available on GitLab.com. You can migrate from a self-managed GitLab instance to GitLab.com or within GitLab.com right now!\n\nGitLab Self-Managed users have access to migrating projects by direct transfer beta, too. Administrators need to enable:\n\n- an [application setting](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#enable-migration-of-groups-and-projects-by-direct-transfer) for migrating groups\n~~- the `bulk_import_projects` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html), for migrating projects in the groups~~\n\nWe have removed that feature flag in GitLab 15.10, so only the application setting needs to be enabled.\n\nThis change enables GitLab Dedicated instances to take advantage of the feature.\n\nWe recommend upgrading self-managed instances to the latest version possible before migrating groups and projects.\n\n## Trying the new feature out\n\nTo get started with the new feature, you can either [read the documentation](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended) or follow the\nsteps below.\n\n1. Make sure the [feature is available](#availability-of-the-feature) to you.\n1. Generate or copy a [personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) with the `api` scope on your source GitLab instance. Both `api` and `read_repository` scopes are required when migrating from GitLab 15.0 and earlier.\n1. On the top navigation, select **+**, then **New group**, and then **Import group**.\n1. Enter the URL of your source GitLab instance.\n1. Enter the personal access token for your source GitLab instance and select **Connect instance**.\n  ![Screenshot of connecting the source instance](https://about.gitlab.com/images/blogimages/migrate-gitlab-projects-images/connect-source-instance.png){: .shadow}\n1. Select the groups to import from the top-level groups on the connected source instance you have the Owner role for. All the projects within chosen groups can be migrated too! Choose from the dropdown the group you want to migrate to for each group you have selected. Adjust the newly created group name, if needed.\n  ![Screenshot of choosing groups to import](https://about.gitlab.com/images/blogimages/migrate-gitlab-projects-images/choose-groups-to-import.png){: .shadow}\n1. Next to the groups you want to import, select **Import with projects**. The **Status** column shows the import status of each group. If you leave the page open, it updates in real time.\n1. After a group has been imported, select its GitLab path to open the imported group.\n\nFor more information about migrating by direct transfer (for example, what resources are migrated and [group import history](https://docs.gitlab.com/ee/user/group/import/index.html#group-import-history)), see our [documentation](https://docs.gitlab.com/ee/user/group/import/index.html).\n\n## What about migrating projects using file exports? \n\nOnce the migrating projects by direct transfer feature is ready for production use at any scale, migrating groups and projects using file exports\nwill be disabled by a feature flag and only migrating groups and projects by direct transfer will be available in the UI and API.\n\nBecause migrating by direct transfer requires network connection between instances or GitLab.com, customers that are using air-gapped networks with no\nnetwork connectivity between their GitLab instances will need to reenable migrating using file exports. They will be able to use migrating groups and\nprojects by direct transfer after we extend this solution to [also support offline instances](https://gitlab.com/groups/gitlab-org/-/epics/8985).\n\nWe will not fully remove migrating using file exports until we support all our customers with a new solution.\n\n## What's next for migrating by direct transfer method \n\nOf course, we're not done yet! We will be improving the direct transfer method before we come out of beta. We're working on:\n\n- Making the migration [efficient](https://gitlab.com/groups/gitlab-org/-/epics/8983) and [reliable](https://gitlab.com/groups/gitlab-org/-/epics/8927)\n  for large projects.\n- Improving [feedback during migration and when migration is finished](https://gitlab.com/groups/gitlab-org/-/epics/8984).\n\nNext, we will be focusing on:\n\n- Enabling more granular imports, where you'll be able to:\n  - Migrate any group in the UI, not only top-level ones. Migrating subgroups is currently limited to the API.\n  - Choose which projects within a group you want to migrate.\n- Importing [project relations not yet included in migration](https://gitlab.com/groups/gitlab-org/-/epics/9319).\n- Automatically [migrating users](https://gitlab.com/groups/gitlab-org/-/epics/4616).\n\nDetails about the migrating by direct transfer roadmap can be found on our [direction page](https://about.gitlab.com/direction/manage/import_and_integrate/importers/).\n\nWe are excited about this roadmap 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 [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495) and we'll keep iterating!\n\n**Disclaimer:** This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.\n\n_Cover photo by [Chris Briggs](https://unsplash.com/@cgbriggs19?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://www.unsplash.com)_\n",[9,678,701,894],{"slug":6106,"featured":6,"template":683},"try-out-new-way-to-migrate-projects","content:en-us:blog:try-out-new-way-to-migrate-projects.yml","Try Out New Way To Migrate Projects","en-us/blog/try-out-new-way-to-migrate-projects.yml","en-us/blog/try-out-new-way-to-migrate-projects",{"_path":6112,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6113,"content":6119,"config":6124,"_id":6126,"_type":13,"title":6127,"_source":15,"_file":6128,"_stem":6129,"_extension":18},"/en-us/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies",{"title":6114,"description":6115,"ogTitle":6114,"ogDescription":6115,"noIndex":6,"ogImage":6116,"ogUrl":6117,"ogSiteName":670,"ogType":671,"canonicalUrls":6117,"schema":6118},"Tutorial: Advanced use case for GitLab Pipeline Execution Policies","Learn how new GitLab Ultimate functionality can enforce a standardized pipeline across an organization for improved compliance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098083/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750098083312.jpg","https://about.gitlab.com/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Advanced use case for GitLab Pipeline Execution Policies\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dan Rabinovitz\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":6114,"description":6115,"authors":6120,"heroImage":6116,"date":3428,"body":6122,"category":704,"tags":6123},[6121],"Dan Rabinovitz","[Pipeline execution policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html) are a newer addition to the GitLab DevSecOps platform and a powerful mechanism to enforce CI/CD jobs across applicable projects. They enable platform engineering or security teams to inject jobs into developers’ YAML pipeline definition files, guaranteeing that certain CI/CD jobs will execute no matter what a developer defines in their \\`.gitlab-ci.yml\\` file. \n\nThis article will explain how to utilize pipeline execution policies to create guardrails around the stages or jobs that a developer can use in their pipeline definition. In regulated environments, this may be necessary to ensure developers adhere to a standard set of jobs or stages in their GitLab pipeline. Any job or stage that a developer adds to their pipeline that does not adhere to a corporate standard will cause the pipeline to fail. \n\nOne example use case for pipeline execution policies is ensuring a security scanner job runs. Let’s say an organization has made an investment in a third-party security scanner and they have a requirement that the external scan runs before any merge is made into the main branch. Without a pipeline execution policy, a developer could easily skip this step by not including the required code in their `.gitlab-ci.yml` file.  With a pipeline execution policy in place, a security team can guarantee the external security scanning job executes regardless of how a developer defines their pipeline.\n\nTo use pipeline execution policies to enforce these restrictions requires two parts: a shell script to make calls to the GitLab API and the policy itself. This tutorial uses a bash script; if your runner uses a different scripting language, it is easy to adapt to other languages.\n\nHere is the example shell script I will use for this exercise:\n\n``` \n#!/bin/bash\n\necho \"Checking pipeline stages and jobs...\"\n\n# Pull the group access token from the environment variable\nGROUP_ACCESS_TOKEN=\"$PIPELINE_TOKEN\"\n\necho \"PROJECT_ID: $PROJECT_ID\"\necho \"PIPELINE_ID: $PIPELINE_ID\"\n\nif [ -z \"$GROUP_ACCESS_TOKEN\" ]; then  \n  echo \"GROUP_ACCESS_TOKEN (MR_GENERATOR) is not set\"\n  exit 1\nfi\n\nif [ -z \"$PROJECT_ID\" ]; then\n  echo \"PROJECT_ID is not set\"\n  exit 1\nfi\n\nif [ -z \"$PIPELINE_ID\" ]; then\n  echo \"PIPELINE_ID is not set\"\n  exit 1\nfi\n\n# Use the group access token for the API request\napi_url=\"$GITLAB_API_URL/projects/$PROJECT_ID/pipelines/$PIPELINE_ID/jobs\"\necho \"API URL: $api_url\"\n\n# Fetch pipeline jobs using the group access token\njobs=$(curl --silent --header \"PRIVATE-TOKEN: $GROUP_ACCESS_TOKEN\" \"$api_url\")\necho \"Fetched Jobs: $jobs\"\n\nif [[ \"$jobs\" == *\"404 Project Not Found\"* ]]; then\n  echo \"Failed to authenticate with GitLab API: Project not found\"\n  exit 1\nfi\n\n# Extract stages and jobs\npipeline_stages=$(echo \"$jobs\" | grep -o '\"stage\":\"[^\"]*\"' | cut -d '\"' -f 4 | sort | uniq | tr '\\n' ',')\npipeline_jobs=$(echo \"$jobs\" | grep -o '\"name\":\"[^\"]*\"' | cut -d '\"' -f 4 | sort | uniq | tr '\\n' ',')\n\necho \"Pipeline Stages: $pipeline_stages\"  \necho \"Pipeline Jobs: $pipeline_jobs\"\n\n# Check if pipeline stages are approved\nfor stage in $(echo $pipeline_stages | tr ',' ' '); do \n  echo \"Checking stage: $stage\"\n  if ! [[ \",$APPROVED_STAGES,\" =~ \",$stage,\" ]]; then\n    echo \"Stage $stage is not approved.\"\n    exit 1\n  fi\ndone\n\n# Check if pipeline jobs are approved \nfor job in $(echo $pipeline_jobs | tr ',' ' '); do\n  echo \"Checking job: $job\"\n  if ! [[ \",$APPROVED_JOBS,\" =~ \",$job,\" ]]; then\n    echo \"Job $job is not approve\n```\n\nLet’s break this down a bit. \n\nThe first few lines of this code perform some sanity checks, ensuring that a pipeline ID, project ID, and group access token exist.\n\n* A GitLab pipeline ID is a unique numerical identifier that GitLab automatically assigns to each pipeline run.\n* A GitLab project ID is a unique numerical identifier assigned to each project in GitLab.\n* A GitLab group access token is a token that authenticates and authorizes access to resources at the group level in GitLab. This is in contrast to a GitLab personal access token (PAT), which is unique to each user.  \n\nThe bulk of the work comes from the [GitLab Projects API](https://docs.gitlab.com/ee/api/projects.html) call where the script requests the jobs for the specified pipeline. Once you have job information for the currently running pipeline, you can use a simple grep command to parse out stage and job names, and store them in variables for comparison. The last portion of the script checks to see if pipeline stages and jobs are on the approved list. Where do these parameters come from?\n\nThis is where [GitLab Pipeline Execution Policies](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html) come into play. They enable injection of YAML code into a pipeline. How can we leverage injected YAML to execute this shell script?  Here’s a code snippet showing how to do this.\n\n```\n## With this config, the goal is to create a pre-check job that evaluates the pipeline and fails the job/pipeline if any checks do not pass\n\nvariables:\n  GITLAB_API_URL: \"https://gitlab.com/api/v4\"\n  PROJECT_ID: $CI_PROJECT_ID\n  PIPELINE_ID: $CI_PIPELINE_ID\n  APPROVED_STAGES: \".pipeline-policy-pre,pre_check,build,test,deploy\"\n  APPROVED_JOBS: \"pre_check,build_job,test_job,deploy_job\"\n\npre_check:\n  stage: .pipeline-policy-pre\n  script:\n    - curl -H \"PRIVATE-TOKEN:${REPO_ACCESS_TOKEN}\" --url \"https://\u003Cgitlab_URL>/api/v4/projects/\u003Cproject_id>/repository/files/check_settings.sh/raw\" -o pre-check.sh\n    - ls -l\n    - chmod +x pre-check.sh\n    - DEBUG_MODE=false ./pre-check.sh  # Set DEBUG_MODE to true or false\n  allow_failure: true\n```\n\nIn this YAML snippet, we set a few variables used in the shell script. Most importantly, this is where approved stages and approved jobs are defined. After the `variables` section, we then add a new job to the `.pipeline-policy-pre` stage. This is a reserved stage for pipeline execution policies and is guaranteed to execute before any stages defined in a `.gitlab-ci.yml` file.  There is a corresponding `.pipeline-policy-post` stage as well, though we will not be using it in this scenario.  \n\nThe script portion of the job does the actual work. Here, we leverage a curl command to execute the shell script defined above. This example includes authentication if it’s located in a private repository. However, if it’s publicly accessible, you can forgo this authentication. The last line controls whether or not the pipeline will fail. In this example, the pipeline will continue. This is useful for testing – in practice, you would likely set `allow_failure: false` to cause the pipeline to fail. This is desired as the goal of this exercise is to not allow pipelines to continue execution if a developer adds a rogue job or stage.\n\nTo utilize this YAML, save it to a `.yml` file in a repository of your choice. We’ll see how to connect it to a policy shortly.\n\nNow, we have our script and our YAML to inject into a developer’s pipeline. Next, let’s see how to put this together using a pipeline execution policy.\n\nLike creating other policies in GitLab, start by creating a new Pipeline Execution Policy by navigating to **Secure > Policies** in the left hand navigation menu. Then, choose **New Policy** at the top right, and select **Pipeline Execution Policy** from the policy creation options.  \n\nFor this exercise, you can leave the **Policy Scope** set to the default options. In the **Actions** section, be sure to choose **Inject** and select the project and file where you’ve saved your YAML code snippet. Click on **Update via Merge Request** at the very bottom to create an MR that you can then merge into your project.\n\nIf this is your first security policy, clicking on **Merge** in the MR will create a [Security Policy Project](https://docs.gitlab.com/ee/user/application_security/policies/vulnerability_management_policy.html), which is a project to store all security policies. When implementing any type of security policy in a production environment, [access to this project should be restricted](https://docs.gitlab.com/ee/user/project/members/) so developers cannot make changes to security policies. In fact, you may also want to consider storing YAML code that’s used by pipeline execution policies in this project to restrict access as well, though this is not a requirement.  \nExecuting a pipeline where this pipeline execution policy is enabled should result in the following output when you attempt to add an invalid stage to the project `.gitlab-ci.yml` file.\n\n![Output of attempting an invalid stage to project gitlab-ci.yml file](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098102/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098102394.png)\n\nWhile this use case is very focused on one aspect of security and compliance in your organization, this opens the door to other use cases. For example, you may want to make group-level variables accessible to every project within a group; this is possible with pipeline execution policies. Or, you may want to create a golden pipeline and have developers add to it. The possibilities are endless. GitLab customers are finding new and exciting ways to use this new functionality every day.\n\nIf you’re a GitLab Ultimate customer, try this out today and let us know how you’re using pipeline execution policies. Not a GitLab Ultimate customer? [Sign up for a free 60-day trial](https://about.gitlab.com/free-trial/devsecops/) to get started.\n\n## Read more\n- [How to integrate custom security scanners into GitLab](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)\n- [Integrate external security scanners into your DevSecOps workflow](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)\n- [Why GitLab is deprecating compliance pipelines in favor of security policies](https://about.gitlab.com/blog/why-gitlab-is-deprecating-compliance-pipelines-in-favor-of-security-policies/)\n",[704,746,183,478,108,9],{"slug":6125,"featured":6,"template":683},"tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies","content:en-us:blog:tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies.yml","Tutorial Advanced Use Case For Gitlab Pipeline Execution Policies","en-us/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies.yml","en-us/blog/tutorial-advanced-use-case-for-gitlab-pipeline-execution-policies",{"_path":6131,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6132,"content":6138,"config":6144,"_id":6146,"_type":13,"title":6147,"_source":15,"_file":6148,"_stem":6149,"_extension":18},"/en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems",{"title":6133,"description":6134,"ogTitle":6133,"ogDescription":6134,"noIndex":6,"ogImage":6135,"ogUrl":6136,"ogSiteName":670,"ogType":671,"canonicalUrls":6136,"schema":6137},"Tutorial: Integrate GitLab Merge Request approvals with external systems","Learn how to improve GitLab extensibility and integration with external applications in this demo. The result: a seamless integration that provides more control over merge requests.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676011/Blog/Hero%20Images/blog-image-template-1800x945.svg","https://about.gitlab.com/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Integrate GitLab Merge Request approvals with external systems\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"}],\n        \"datePublished\": \"2024-10-08\",\n      }",{"title":6133,"description":6134,"authors":6139,"heroImage":6135,"date":6141,"body":6142,"category":701,"tags":6143},[6140],"Samer Akkoub","2024-10-08","GitLab customers often ask how to connect merge requests to external applications, such as ServiceNow or custom-built applications, to control approvals for the merging of code into a target branch from these external systems. To address this need, GitLab offers [External Status Check](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html), a powerful feature that allows the sending of API calls to external systems to request the status of an external requirement, providing seamless integration and control over your merge requests.\n\nIn this article, I'll demonstrate this feature by explaining how to deploy an application I developed. The application is designed to receive status check requests from GitLab Merge Requests, list them, and enable external users to approve/reject these requests without logging in to the GitLab console. As a result, GitLab platform architects will better understand GitLab extensibility and integration with external systems.\n\nThe provided sample application can:\n1. Receive API requests from merge requests.\n2. Store the requests in AlchemyDB running on the same instance.\n3. Show Approve/Reject buttons for each row to approve or reject the corresponding merge request status check.\n\n## How to deploy the status review demo application\n1. Import this [GitLab repo project](https://gitlab.com/sakkoub-publicgroup/external-approval-app) to your GitLab account.\n2. The project pipeline will deploy the application to a Kubernetes cluster. To achieve this, define a [GitLab Agent](https://docs.gitlab.com/ee/user/clusters/agent/install/index.html) for Kubernetes in a separate project and include a path to the cloned project under the “[user_access](https://docs.gitlab.com/ee/user/clusters/agent/user_access.html)” section in the agent configuration.\n3. Add a new environment variable `KUBE_CONTEXT`, with the value equal to the used agent path:name, similar to the following structure `path/to/agent/project:agent-name`.\n4. The status check application will be deployed to the `approval-app` namespace by default.\n5. Create the `approval-app` namespace in the target Kubernetes cluster.\n6. In the created namespace, add a secret named `gitlab-token` with the value set to the personal access token (PAT) of the user who will be approving the requests. The approval application will use this PAT to communicate back to the GitLab instance.\n7. Run the status check application pipeline on the main branch.\n8. Once deployed, the application will be exposed behind a load balancer. Use this command to grab the public IP address of the load balancer: `kubectl get services -n approval-app`.\n9. The application can then be accessed using this URL: http://EXTERNAL-IP/approval-apps/. Replace the `EXTERNAL-IP` with the value of the external IP address from the previous step. The resulting page should look like below (the table would be empty as we have not added any new merge requests yet).\n\n![Table showing IP address](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752507534/v0pgvobf09eh9yqxqzrk.png)\n\n## Configure status check in GitLab\n\n1. In the GitLab project where the external status check needs to be configured, from the left menu, navigate under settings **-\\> Merge Request** and scroll down to **Status checks**.\n2. Click on **Add status check**.\n3. Add a service name.\n4. For the API to check enter: `[http://EXTERNAL-IP[/approval-apps/status_check`. Replace the `EXTERNAL-IP` with the external IP address found in the previous steps.\n5. Leave the `Target Branch` to the default, or select branch if you want this check to be triggered only for merge requests against certain branches.\n6. Leave `HMAC Shared Secret` as it is and click **Add status check**.\n\n![How to configure status check](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752507426/jal2hw9ef3pydbetbp7p.png)\n\n## Test everything together\n\n1. In the project where you have configured the external check, create a new merge request from any branch targeting the main branch (assuming the main branch was selected when the external check was configured in the previous section).\n2. In the merge request details, look for the **Status checks** section and it should show `1 Pending`.\n3. Now, in a new tab, open the deployed external check application using this URL (replace `EXTERNAL-IP` with the value of the external IP address from the previous steps): `http://EXTERNAL-IP/approval-apps/`.\n4. A new entry should show in the list for the request external check from the merge request just created. Click on **Approve**.\n5. Switch back to the merge request's details screen and notice how the merge request is showing an approved status now.\n\n## Debugging tips\n\nUse the following notes to debug if something does not go as planned:\n\nIt is always helpful to view the logs for the external status check application. To do so: \n   1. Extract the name of the application pod using this command: `kubectl get pods -n approval-app`.\n   2. View the pod logs `kubectl logs [THE NAME OF THE POD] -n approval-app`.\n\nYou can SSH into the application pod and view the database (Alchemydb), which is used for the application. \n   1. `kubectl exec -it \\[POD-NAME\\] -n approval-app -- /bin/sh` \n   2. `cd instance`\n   3. `sqlite3 gitlab_status_checks.db` \n   4. To view the database tables, type `.tables`.\n   5. To describe the table structure, type `PRAGMA table_info('status_check');`.\n   6. To view all the records in the `status_check` table, type `select * from status_check`.\n\n> Discover more about [GitLab External Status Check](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html) and how to gain more control over merge requests.\n",[746,701,9,108],{"slug":6145,"featured":6,"template":683},"tutorial-integrate-gitlab-merge-request-approvals-with-external-systems","content:en-us:blog:tutorial-integrate-gitlab-merge-request-approvals-with-external-systems.yml","Tutorial Integrate Gitlab Merge Request Approvals With External Systems","en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems.yml","en-us/blog/tutorial-integrate-gitlab-merge-request-approvals-with-external-systems",{"_path":6151,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6152,"content":6158,"config":6162,"_id":6164,"_type":13,"title":6165,"_source":15,"_file":6166,"_stem":6167,"_extension":18},"/en-us/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"title":6153,"description":6154,"ogTitle":6153,"ogDescription":6154,"noIndex":6,"ogImage":6155,"ogUrl":6156,"ogSiteName":670,"ogType":671,"canonicalUrls":6156,"schema":6157},"Tutorial: Secure and optimize your Maven Repository in GitLab","Learn the best practices, advanced techniques, and upcoming features that improve the efficiency of your DevSecOps workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","https://about.gitlab.com/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Secure and optimize your Maven Repository in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-05-22\",\n      }",{"title":6153,"description":6154,"authors":6159,"heroImage":6155,"date":4205,"body":6160,"category":704,"tags":6161},[1040],"As a GitLab product manager, I'm excited to share insights on securing and optimizing your Maven repository. We're passionate about providing a complete DevSecOps platform, and the Maven repository is part of this ecosystem. Explore best practices, advanced techniques, and upcoming features that will transform your Maven workflow.\n\n## Securing your Maven repository: A comprehensive approach\n\nSecuring your software supply chain is more critical than ever so let's dive into strategies to fortify your Maven packages in GitLab.\n\n### Implement strong authentication\n\n**Personal access tokens:** Use PATs for fine-grained access control.\n\nFor example:\n\n```bash\nmvn deploy -s settings.xml\n```\n\nWhere `settings.xml` contains:\n\n```xml\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_PERSONAL_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\n**Deploy tokens:** Ideal for CI/CD pipelines. Generate these in your GitLab project settings and use them in your `.gitlab-ci.yml`.\n\n```yaml\ndeploy:\n  script:\n    - 'mvn deploy -s ci_settings.xml'\n  variables:\n    MAVEN_CLI_OPTS: \"-s ci_settings.xml --batch-mode\"\n    MAVEN_OPTS: \"-Dmaven.repo.local=.m2/repository\"\n  only:\n    - main\n```\n\nThe corresponding `ci_settings.xml` file:\n\n```xml\n\u003Csettings xmlns=\"http://maven.apache.org/SETTINGS/1.1.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n  xsi:schemaLocation=\"http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd\">\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Deploy-Token\u003C/name>\n            \u003Cvalue>${env.CI_DEPLOY_PASSWORD}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nIn this setup:\n\n* The `CI_DEPLOY_PASSWORD` should be set as a CI/CD variable in your GitLab project settings containing the deploy token.\n* The `\u003Cid>` should match the repository ID in your project's `pom.xml` file.\n\n**Token rotation:** Implement a token rotation policy using GitLab's API. For example, you could create a scheduled pipeline that rotates tokens monthly:\n\n```yaml\nrotate_tokens:\n  script:\n    - curl --request POST \"https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/deploy_tokens\" --header \"PRIVATE-TOKEN: ${ADMIN_TOKEN}\" --form \"name=maven-deploy-${CI_PIPELINE_ID}\" --form \"scopes[]=read_registry\" --form \"scopes[]=write_registry\"\n  only:\n    - schedules\n```\n\n### Leverage GitLab's built-in security features\n\n**Dependency Scanning:** Enable it in your `.gitlab-ci.yml`.\n\n```yaml\ninclude:\n  - template: Security/Dependency-Scanning.gitlab-ci.yml\n\nvariables:\n  DS_JAVA_VERSION: 11\n```\n\n**Container Scanning:** If you're containerizing your Maven applications.\n\n```yaml\ninclude:\n  - template: Security/Container-Scanning.gitlab-ci.yml\n\nvariables:\n  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\n```\n\n**License Compliance:** Ensure all dependencies comply with your project's licensing requirements.\n\n```yaml\ninclude:\n  - template: Security/License-Scanning.gitlab-ci.yml\n```\n\n### Secure your CI/CD pipeline\n\n* **CI/CD variables:** Store sensitive information securely.\n\n  ```yaml\n  variables:\n    MAVEN_REPO_USER: ${CI_DEPLOY_USER}\n    MAVEN_REPO_PASS: ${CI_DEPLOY_PASSWORD}\n  ```\n* **Masked variables:** Prevent exposure in job logs. Set these in your GitLab CI/CD settings.\n* **Protected branches and tags:** Configure these in your GitLab project settings to control who can trigger package publishing.\n\n### Implement package signing\n\n* Use the Maven GPG plugin to sign your artifacts.\n\n  ```xml\n  \u003Cplugin>\n    \u003CgroupId>org.apache.maven.plugins\u003C/groupId>\n    \u003CartifactId>maven-gpg-plugin\u003C/artifactId>\n    \u003Cversion>1.6\u003C/version>\n    \u003Cexecutions>\n      \u003Cexecution>\n        \u003Cid>sign-artifacts\u003C/id>\n        \u003Cphase>verify\u003C/phase>\n        \u003Cgoals>\n          \u003Cgoal>sign\u003C/goal>\n        \u003C/goals>\n      \u003C/execution>\n    \u003C/executions>\n  \u003C/plugin>\n  ```\n\n* Store your GPG key securely using GitLab CI/CD variables.\n\n### Control package access\n\n* Use GitLab's project and group-level package registry settings to restrict access.\n* Implement IP allowlists for network-level access control in your GitLab instance settings.\n\n## Optimize performance: Streamline your Maven workflow\n\nEfficiency is crucial when working with large projects or numerous dependencies. Here are advanced techniques to optimize your Maven package usage in GitLab.\n\n### Utilize dependency management\n\n* Use the `\u003CdependencyManagement>` section in your parent POM.\n\n  ```xml\n  \u003CdependencyManagement>\n    \u003Cdependencies>\n      \u003Cdependency>\n        \u003CgroupId>org.springframework.boot\u003C/groupId>\n        \u003CartifactId>spring-boot-dependencies\u003C/artifactId>\n        \u003Cversion>${spring-boot.version}\u003C/version>\n        \u003Ctype>pom\u003C/type>\n        \u003Cscope>import\u003C/scope>\n      \u003C/dependency>\n    \u003C/dependencies>\n  \u003C/dependencyManagement>\n  ```\n### Leverage multi-module projects\n\n  * Structure your project with a parent POM and multiple modules:\n\n    ```\n    my-project/\n    ├── pom.xml\n    ├── module1/\n    │   └── pom.xml\n    ├── module2/\n    │   └── pom.xml\n    └── module3/\n        └── pom.xml\n    ```\n  * Use Maven's reactor to build modules in the optimal order:\n\n    ```bash\n    mvn clean install\n    ```\n\n### Implement parallel builds\n\n* Use Maven's parallel build feature:\n\n  ```bash\n  mvn -T 4C clean install\n  ```\n\n### Optimize for CI/CD\n\n* In `.gitlab-ci.yml`, use caching to speed up builds:\n\n  ```yaml\n  cache:\n    paths:\n      - .m2/repository\n\n  build:\n    script:\n      - mvn clean package -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository\n  ```\n* Implement incremental builds:\n\n  ```yaml\n  build:\n    script:\n      - mvn clean install -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -am -amd -fae\n  ```\n\n### Utilize build caching\n\n* Use the Gradle Enterprise Maven Extension for build caching:\n\n  ```xml\n  \u003Cbuild>\n    \u003Cplugins>\n      \u003Cplugin>\n        \u003CgroupId>com.gradle\u003C/groupId>\n        \u003CartifactId>gradle-enterprise-maven-plugin\u003C/artifactId>\n        \u003Cversion>1.9\u003C/version>\n        \u003Cconfiguration>\n          \u003CgradleEnterprise>\n            \u003Cserver>https://ge.example.com\u003C/server>\n            \u003CallowUntrusted>false\u003C/allowUntrusted>\n          \u003C/gradleEnterprise>\n        \u003C/configuration>\n      \u003C/plugin>\n    \u003C/plugins>\n  \u003C/build>\n  ```\n\n## Introducing the Maven Virtual Registry beta program\n\nI'm thrilled to announce the launch of our beta program for the upcoming Maven virtual registry feature. This addition to our package ecosystem will change how you manage Maven repositories in GitLab.\n\n### Key features of Maven Virtual Registry\n\n1. **Repository aggregation:** Combine multiple Maven repositories (both internal and external) into a single virtual repository.\n2. **Smart proxy and caching:** Improve build times by caching artifacts and intelligently routing requests.\n3. **Centralized Access Control:** Enhance security by managing access to all repositories from a single point.\n\n### How it works\n\n1. **Configuration:** Configure Maven authentication in your `settings.xml`:\n\n```\n\u003Csettings>\n  \u003Cservers>\n    \u003Cserver>\n      \u003Cid>gitlab-maven\u003C/id>\n      \u003Cconfiguration>\n        \u003ChttpHeaders>\n          \u003Cproperty>\n            \u003Cname>Private-Token\u003C/name>\n            \u003Cvalue>${env.GITLAB_TOKEN}\u003C/value>\n          \u003C/property>\n        \u003C/httpHeaders>\n      \u003C/configuration>\n    \u003C/server>\n  \u003C/servers>\n\u003C/settings>\n```\n\nAuthentication options:\n\n- Personal access token: Use `Private-Token` as the name and `${env.GITLAB_TOKEN}` as the value.\n\n-  Group deploy token: Use `Deploy-Token` as the name and `${env.GITLAB_DEPLOY_TOKEN}` as the value.\n\n- Group access token: Use `Private-Token` as the name and `${env.GITLAB_ACCESS_TOKEN}` as the value.\n\n- CI job token: Use `Job-Token` as the name and `${CI_JOB_TOKEN}` as the value.\n\n- Configure the virtual registry in your `pom.xml`.\n\nOption 1: As an additional registry:\n\n```\n\u003Crepositories>\n  \u003Crepository>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n  \u003C/repository>\n\u003C/repositories>\n```\n\nOption 2: As a replacement for Maven Central (in your `settings.xml`):\n\n```\n\u003Cmirrors>\n  \u003Cmirror>\n    \u003Cid>gitlab-maven\u003C/id>\n    \u003Cname>GitLab virtual registry for Maven Central\u003C/name>\n    \u003Curl>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/\u003Cvirtual registry id>\u003C/url>\n    \u003CmirrorOf>central\u003C/mirrorOf>\n  \u003C/mirror>\n\u003C/mirrors>\n```\n\n2. **Usage:** Now all your Maven operations will use the virtual repository.\n\n```\n# For personal access tokens\nexport GITLAB_TOKEN=your_personal_access_token\n\n# For group deploy tokens\nexport GITLAB_DEPLOY_TOKEN=your_deploy_token\n\n# For group access tokens\nexport GITLAB_ACCESS_TOKEN=your_access_token\n\n# Then run Maven commands normally\nmvn package\n\n```\n\n3. Benefits\n\n- Simplified dependency management\n- Improved build times\n- Enhanced security and compliance\n- Better control over third-party dependencies\n\n### Join the beta program\n\nWe're actively seeking participants for our beta program. As a beta tester, you'll have the opportunity to:\n\n* Get early access to the Maven Virtual Registry feature.\n* Provide direct feedback to our development team.\n* Shape the future of Maven package management in GitLab.\n* Participate in exclusive webinars and Q&A sessions with our product team.\n\n> To join the beta program or learn more about the Maven Virtual Registry, please visit the [GitLab Maven Virtual Registry Beta Program](https://gitlab.com/gitlab-org/gitlab/-/issues/498139) (**Note:** This is a placeholder link).\n\n## Summary\n\nAt GitLab, we're committed to providing cutting-edge tools for secure, efficient, and scalable software development. The Maven Virtual Registry is just one example of how we're continuously innovating to meet the evolving needs of developers and platform engineers.\n\nImplementing the security measures and optimization techniques discussed in this post and leveraging upcoming features like the Maven Virtual Registry can improve your Maven workflow within GitLab.\n\nWe're excited about the future of package management in GitLab and can't wait to see how you'll use these features to take your development process to the next level. Stay tuned for more updates and happy coding!",[704,478,9,701,894],{"slug":6163,"featured":90,"template":683},"tutorial-secure-and-optimize-your-maven-repository-in-gitlab","content:en-us:blog:tutorial-secure-and-optimize-your-maven-repository-in-gitlab.yml","Tutorial Secure And Optimize Your Maven Repository In Gitlab","en-us/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab.yml","en-us/blog/tutorial-secure-and-optimize-your-maven-repository-in-gitlab",{"_path":6169,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6170,"content":6176,"config":6181,"_id":6183,"_type":13,"title":6184,"_source":15,"_file":6185,"_stem":6186,"_extension":18},"/en-us/blog/tutorial-security-scanning-in-air-gapped-environments",{"title":6171,"description":6172,"ogTitle":6171,"ogDescription":6172,"noIndex":6,"ogImage":6173,"ogUrl":6174,"ogSiteName":670,"ogType":671,"canonicalUrls":6174,"schema":6175},"Tutorial: Security scanning in air-gapped environments","Security scanning remains crucial even in air-gapped environments to detect internal threats, prevent data exfiltration, and maintain operational integrity. Learn how GitLab can help get air-gapped environments secure.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099301/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750099300786.jpg","https://about.gitlab.com/blog/tutorial-security-scanning-in-air-gapped-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Security scanning in air-gapped environments\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-02-05\",\n      }",{"title":6171,"description":6172,"authors":6177,"heroImage":6173,"date":6178,"body":6179,"category":704,"tags":6180},[2234],"2025-02-05","Air-gapped environments are computer networks or systems that are physically isolated from unsecured networks, such as the public internet or unsecured local area networks. This isolation is implemented as a security measure to protect sensitive data and critical systems from external cyber threats by providing:\n\n* Enhanced security: By physically isolating systems from external networks, air-gapped environments help prevent remote attacks, malware infections, and unauthorized data access. This is crucial for highly sensitive data and critical systems.\n* Data protection: Air-gapping provides the strongest protection against data exfiltration since there's no direct connection that attackers could use to steal information.\n* Critical infrastructure protection: For systems that control vital infrastructure (like power plants, water treatment facilities, or military systems), air-gapping helps prevent potentially catastrophic cyber attacks.\n* Compliance requirements: Many regulatory frameworks require air-gapping for certain types of sensitive data or critical systems, particularly in government, healthcare, and financial sectors.\n* Malware protection: Without network connectivity, systems are protected from network-based malware infections and ransomware attacks.\n\nEven though air-gapped systems are isolated, they can still have vulnerabilities. Regular security scanning helps identify these weaknesses before they can be exploited. In this article, you will learn the different security scanners GitLab provides and how they can be added/updated in a limited-connectivity environment.\n\n## GitLab security scanners in air-gapped environments\n\nGitLab provides a variety of different security scanners for the complete application lifecycle. The scanners that support air-gapped environments include:\n\n* [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/index.html#running-sast-in-an-offline-environment)  \n* [Dynamic Application Security Testing (DAST](https://docs.gitlab.com/ee/user/application_security/dast/browser/configuration/offline_configuration.html))  \n* [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/index.html#offline-configuration)  \n* [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html#running-container-scanning-in-an-offline-environment)  \n* [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html#offline-environment)  \n* [API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/configuration/offline_configuration.html)  \n* [License Scanning](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/index.html#running-in-an-offline-environment)\n\nBy default, GitLab Self-Managed instances pull security scanner images from the public GitLab container registry (registry.gitlab.com) and store them within the [built-in local GitLab container registry](https://docs.gitlab.com/ee/user/packages/container_registry/). I will demonstrate this flow below by running the following pipeline that scans for secrets on a [sample project](https://gitlab.com/gitlab-da/tutorials/security-and-governance/owasp/juice-shop): \n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nWhen running the job in an internet-connected GitLab instance the job passes:\n\n![GitLab Runner with internet access successfully pulling from external registry\n](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/pass-1_aHR0cHM6_1750099328577.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner with internet access successfully pulling from external registry\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\nHowever, If I disable internet access to the VM running GitLab, the `secret-detection` job will fail to download the container image, causing the job to fail:\n\n![GitLab Runner without internet access failing to pull from external registry](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/fail-1_aHR0cHM6_1750099328577.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access failing to pull from external registry\u003C/i>\u003C/center>\n\u003Cbr>\u003C/br>\n\nAlternatively, if I set my GitLab Runners’ pull image policy to `if-not-present` from `always`, I can load the cached version of the scanner if it was run before on the internet by using the image stored in our local docker:\n\n![GitLab Runner without internet access successfully pulling from internal registry cache](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099329/Blog/Content%20Images/Blog/Content%20Images/pass-2_aHR0cHM6_1750099328579.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access successfully pulling from internal registry cache\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\n### Setting up offline scanning prerequisites\n\nRunning these security scanners in an air-gapped environment requires the following:\n\n* [GitLab Ultimate subscription](https://about.gitlab.com/pricing/ultimate/)  \n* [Offline cloud license](https://about.gitlab.com/pricing/licensing-faq/cloud-licensing/#offline-cloud-licensing)  \n* GitLab Self-Managed cluster\n\nYou can follow along with this tutorial in any GitLab Self-Managed EE instance (even those that are not air-gapped) to learn how to transfer and run images in an air-gapped environment. In this tutorial, I will demonstrate how to load scanner images onto a GitLab-EE instance running in a Google Compute VM where I cut off the `EGRESS` to everything by implementing firewall rules:\n\n```bash\n# egress firewall rule to block all outbound traffic to the internet\n$ gcloud compute firewall-rules create deny-internet-egress \\\n    --direction=EGRESS \\\n    --priority=1000 \\\n    --network=default \\\n    --action=DENY \\\n    --rules=all \\\n    --destination-ranges=0.0.0.0/0 \\\n    --target-tags=no-internet\n\n# Create an allow rule for internal traffic with higher priority\n$ gcloud compute firewall-rules create allow-internal-egress \\\n    --direction=EGRESS \\\n    --priority=900 \\\n    --network=default \\\n    --action=ALLOW \\\n    --rules=all \\\n    --destination-ranges=10.0.0.0/8,192.168.0.0/16,172.16.0.0/12 \\\n    --target-tags=no-internet\n\n# Apply tag to VM\n$ gcloud compute instances add-tags YOUR_VM_NAME \\\n    --zone=YOUR_ZONE \\\n    --tags=no-internet\n```\n\nThen, once I SSH into my VM, you can see we cannot connect to registry.gitlab.com:\n\n```bash\n# showing I can’t access the gitlab container registry\n$ ping registry.gitlab.com\nPING registry.gitlab.com (35.227.35.254) 56(84) bytes of data.\n^C\n--- registry.gitlab.com ping statistics ---\n3 packets transmitted, 0 received, 100% packet loss, time 2031ms\n```\n\n**Note:** I am still allowing ingress so I can copy files and SSH into the machine.\n\n## Load security scanners in air-gapped environments\n\nTo use the various security scanners on air-gapped environments, the GitLab Runner must be able to fetch the scanner container images from GitLab’s built-in container registry. This means that the container images for the security scanners must be downloaded and packaged in a separate environment with access to the public internet. The process of loading security scanners onto an air-gapped environment includes the following:\n\n1. Download and package container images from the public internet.\n2. Transfer images to offline environment.\n3. Load transferred images into offline container registry.\n\nNow let’s go over how we can implement GitLab Secret Detection in an air-gapped environment.\n\n### Download and package container images from public internet\n\nLet’s download the container image for secret detection and store it within our local container registry. Other scanner images can be found in the [offline deployments documentation](https://docs.gitlab.com/ee/user/application_security/offline_deployments/). I will be using Podman desktop to download these images, but you can use Docker desktop or other alternatives.\n\n1. Pull the GitLab Secret Detection image.\n\n```bash\n$ podman pull registry.gitlab.com/security-products/secrets:6\nTrying to pull registry.gitlab.com/security-products/secrets:6...\nGetting image source signatures\nCopying blob sha256:999745130ac045f2b1c29ecce088b43fc4a95bbb82b7960fb7b8abe0e3801bf8\nCopying blob sha256:a4f7c013bb259c146cd8455b7c3943df7ed84b157e42a2348eef16546d8179b1\nCopying blob sha256:1f3e46996e2966e4faa5846e56e76e3748b7315e2ded61476c24403d592134f0\nCopying blob sha256:400a41f248eb3c870bd2b07073632c49f1e164c8efad56ea3b24098a657ec625\nCopying blob sha256:9090f17a5a1bb80bcc6f393b0715210568dd0a7749286e3334a1a08fb32d34e6\nCopying blob sha256:c7569783959081164164780f6c1b0bbe1271ee8d291d3e07b2749ae741621ea3\nCopying blob sha256:20c7ca6108f808ad5905f6db4f7e3c02b21b69abdea8b45abfa34c0a2ba8bdb5\nCopying blob sha256:e8645a00be64d77c6ff301593ce34cd8c17ffb2b36252ca0f2588009a7918d2e\nCopying config sha256:0235ed43fc7fb2852c76e2d6196601968ae0375c72a517bef714cd712600f894\nWriting manifest to image destination\nWARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)\n0235ed43fc7fb2852c76e2d6196601968ae0375c72a517bef714cd712600f894\n\n$ podman images\nREPOSITORY                                                  TAG         IMAGE ID      CREATED      SIZE\nregistry.gitlab.com/security-products/secrets               6           0235ed43fc7f  4 hours ago  85.3 MB\n```\n\n2. Save the image as a tarball.\n\n```bash\n$ podman save -o secret-detection.tar registry.gitlab.com/security-products/secrets:6\n$ chmod +r secret-detection.tar\n$ ls -al secret-detection.tar\n-rw-r--r--@ 1 fern  staff  85324800 Jan 10 10:25 secret-detection.tar\n```\n\nAlternatively, you can use the [official GitLab template](https://docs.gitlab.com/ee/user/application_security/offline_deployments/#using-the-official-gitlab-template) on an environment with internet access to download the container images needed for the security scanners and save them as job artifacts or push them to the container registry of the project where the pipeline is executed. \n\n### Transfer images to offline environment\n\nNext, let's transfer the tarball to our air-gapped environment. This can be done in several ways, depending on your needs, such as:\n\n* Physical media transfer  \n* Data diodes  \n* Guard systems  \n* Cross-domain solutions (CDS) \n\nI will SCP (Secure Copy Protocol) the tarball directly to my VM that does not have egress access, but does allow ingress. As this is just for demonstration purposes, make sure to consult your organization's security policies and transfer procedures for air-gapped environments.\n\n#### Verify the image is not cached\n\nBefore transferring the file, I’ll delete the Docker images on my GitLab instance pertaining to secret detection to make sure they aren't cached:\n\n```bash\n$ docker images\nREPOSITORY                                                          TAG              IMAGE ID       CREATED        SIZE\nregistry.gitlab.com/security-products/secrets                       6                0235ed43fc7f   9 hours ago    84.8MB\nregistry.gitlab.com/security-products/secrets                       \u003Cnone>           16d88433af61   17 hours ago   74.9MB\n\n$ docker image rmi 16d88433af61 -f\nUntagged: registry.gitlab.com/security-products/secrets@sha256:f331da6631d791fcd58d3f23d868475a520f50b02d64000e2faf1def66c75d48\nDeleted: sha256:16d88433af618f0b405945031de39fe40b3e8ef1bddb91ca036de0f5b32399d7\nDeleted: sha256:1bb06f72f06810e95a70039e797481736e492201f51a03b02d27db055248ab6f\nDeleted: sha256:a5ef2325ce4be9b39993ce301f8ed7aad1c854d7ee66f26a56a96967c6606510\nDeleted: sha256:f7cdac818a36d6c023763b76a6589c0db7609ca883306af4f38b819e62f29471\nDeleted: sha256:5eabf4d47287dee9887b9692d55c8b5f848b50b3b7248f67913036014e74a0e9\nDeleted: sha256:51b7cb600604c0737356f17bc02c22bac3a63697f0bf95ba7bacb5b421fdb7da\nDeleted: sha256:1546193b011d192aa769a15d3fdd55eb4e187f201f5ff7506243abb02525dc06\nDeleted: sha256:1ea72408d0484c3059cc0008539e6f494dc829caa1a97d156795687d42d9cb57\nDeleted: sha256:1313ee9da7716d85f63cfdd1129f715e9bbb6c9c0306e4708ee73672b3e40f26\nDeleted: sha256:954ebfd83406f0dfed93eb5157ba841af5426aa95d4054174fff45095fd873a1\n\n$ docker image rmi 0235ed43fc7f -f\nUntagged: registry.gitlab.com/security-products/secrets:6\nDeleted: sha256:0235ed43fc7fb2852c76e2d6196601968ae0375c72a517bef714cd712600f894\nDeleted: sha256:f05f85850cf4fac79e279d93afb6645c026de0223d07b396fce86c2f76096c1f\nDeleted: sha256:7432b0766b885144990edd3166fbabed081be71d28d186f4d525e52729f06b1f\nDeleted: sha256:2c6e3361c2ee2f43bd75fb9c7c12d981ce06df2d51a134965fa47754760efff0\nDeleted: sha256:7ad7f7245b45fbe758ebd5788e0ba268a56829715527a9a4bc51708c21af1c7f\nDeleted: sha256:3b73a621115a59564979f41552181dce07f3baa17e27428f7fff2155042a1901\nDeleted: sha256:78648c2606a7c4c76885806ed976b13e4d008940bd3d7a18b52948a6be71b60d\nDeleted: sha256:383d4a6dc5be9914878700809b4a3925379c80ab792dfe9e79d14b0c1d6b5fad\n```\n\nThen I'll rerun the job to show the failure:\n\n![GitLab Runner without internet access fails to pull an image from internal registry cache](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099328580.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access fails to pull an image from internal registry cache\u003C/i>\u003C/center>\n\n#### SCP file to GitLab instance\n\nNow, from my local machine, I will SCP the file to my GitLab instance as follows:\n\n```bash\n$ gcloud compute scp secret-detection.tar INSTANCE:~ --zone=ZONE\nsecret-detection.tar                                                          100%   81MB  21.5MB/s   00:03\n```\n\n### Load transferred images into offline container registry\n\nNext, I'll SSH into my VM and load the Docker image:\n\n```bash\n$ gcloud compute ssh INSTANCE --zone=ZONE\n\n$ sudo docker load -i secret-detection.tar\nc3c8e454c212: Loading layer [==================================================>]  2.521MB/2.521MB\n51e93afaeedc: Loading layer [==================================================>]  32.55MB/32.55MB\ne8a25e39bb30: Loading layer [==================================================>]  221.2kB/221.2kB\n390704968493: Loading layer [==================================================>]  225.8kB/225.8kB\n76cf57e75f63: Loading layer [==================================================>]  17.64MB/17.64MB\nc4c7a681fd10: Loading layer [==================================================>]  4.608kB/4.608kB\nf0690f406157: Loading layer [==================================================>]  24.01MB/24.01MB\nLoaded image: registry.gitlab.com/security-products/secrets:6\n```\n\n### Run the scanners\n\nI'll [re-run the pipeline manually](https://docs.gitlab.com/ee/ci/pipelines/#run-a-pipeline-manually) and the scanner will be pulled from the cache. Once the pipeline completes, we can see the secret detection job is successful:\n\n![GitLab Runner without internet access successfully pulling from internal registry cache after image loaded](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099328581.png)\n\n\u003Ccenter>\u003Ci>GitLab Runner without internet access successfully pulling from internal registry cache after image loaded\u003C/center>\u003C/i>\n\nIf you want to pull the image from a different location or you tag your images in a different way, you can edit the config as follows:\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nvariables:\n  SECURE_ANALYZERS_PREFIX: \"localhost:5000/analyzers\"\n```\n\nSee the [offline environments documentation](https://docs.gitlab.com/ee/user/application_security/offline_deployments/) for more information.\n\n### View scanner results\n\nOnce the scanner completes on the default branch, a vulnerability report is populated with all the findings. The vulnerability report provides information about vulnerabilities from scans of the default branch.\n\nYou can access the vulnerability report by navigating to the side tab and selecting **Secure > Vulnerability Report**:\n\n![GitLab Vulnerability Report with secret detection findings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099328/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099328581.png)\n\n\u003Ccenter>\u003Ci>GitLab Vulnerability Report with secret detection findings\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nThe project’s vulnerability report provides:\n- totals of vulnerabilities per severity level\n- filters for common vulnerability attributes\n- details of each vulnerability, presented in tabular layout\n- a timestamp showing when it was updated, including a link to the latest pipeline\n\nWe can see that two vulnerabilities were detected by the Secret Detection scanner. If we click on a vulnerability, we will be transported to its vulnerability page:\n\n![GitLab Vulnerability Page showing detailed insights](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099329/Blog/Content%20Images/Blog/Content%20Images/insights_aHR0cHM6_1750099328582.png)\n\n\u003Ccenter>\u003Ci>GitLab Vulnerability Page showing detailed insights\u003C/center>\u003C/i>\n\n\u003Cbr>\u003C/br>\n\nThe vulnerability page provides details of the vulnerability, which can be used to triage and find a path to remediation. These vulnerability details include:\n- description\n- when it was detected\n- current status\n- available actions\n- linked issues\n- actions log\n- filename and line number of the vulnerability (if available)\n- severity\n\n## Read more\n\nTo learn more about GitLab and running security scanners in air-gapped environments, check out the following resources:\n\n* [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/)  \n* [GitLab Security and Compliance Solutions](https://about.gitlab.com/solutions/security-compliance/)  \n* [GitLab Offline Deployments Documentation](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)  \n* [GitLab Application Security Documentation](https://docs.gitlab.com/ee/user/application_security/)\n",[746,704,183,478,9],{"slug":6182,"featured":90,"template":683},"tutorial-security-scanning-in-air-gapped-environments","content:en-us:blog:tutorial-security-scanning-in-air-gapped-environments.yml","Tutorial Security Scanning In Air Gapped Environments","en-us/blog/tutorial-security-scanning-in-air-gapped-environments.yml","en-us/blog/tutorial-security-scanning-in-air-gapped-environments",{"_path":6188,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6189,"content":6195,"config":6200,"_id":6202,"_type":13,"title":6203,"_source":15,"_file":6204,"_stem":6205,"_extension":18},"/en-us/blog/ultimate-git-guide",{"title":6190,"description":6191,"ogTitle":6190,"ogDescription":6191,"noIndex":6,"ogImage":6192,"ogUrl":6193,"ogSiteName":670,"ogType":671,"canonicalUrls":6193,"schema":6194},"Our ultimate guide to Git","Open source pioneer Git is 15 years old. Here is our guide to making the most of it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681222/Blog/Hero%20Images/git-15th-anniversary-cover.png","https://about.gitlab.com/blog/ultimate-git-guide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Our ultimate guide to Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2020-04-20\",\n      }",{"title":6190,"description":6191,"authors":6196,"heroImage":6192,"date":6197,"body":6198,"category":827,"tags":6199},[1246],"2020-04-20","\n\n_Git, a [source code management](/solutions/source-code-management/) tool and arguably the most famous open source software project, turned 15 in April 2020. That’s a milestone no matter how you look at it, and not surprisingly our team has a lot to say about Git. From a look back at the past to newbie-friendly explanations, we’ve pulled together the ultimate guide to Git (as told by GitLab)._\n\n## Meet Git\n\nIf you’re just getting started with software development, you’ll have questions. Luckily, we have answers including background on developer Linus Torvalds in [\"A beginner’s guide to Git\"](/blog/beginner-git-guide/).\n\n![Linus Torvalds](https://about.gitlab.com/images/blogimages/linustorvalds.png){: .shadow.small.center}\n\nThe godfather of Git, Linus Torvalds.\n{: .note.text-center}\n\n## Get more out of Git\n\nWe all spend a ton of time working with Git so it makes sense to polish up your workflow so it shines. We’ve [got the lowdown](/blog/15-git-tips-improve-workflow/) on Git blame, .gitignore, how to pull frequently, and more.\n\n## Missed Git Merge?\n\nNot everyone was lucky enough to attend the actual, in-person Git birthday party. Here’s our [first-person account](/blog/git-merge-fifteen-year-git-party/) of the festivities, complete with lots of pictures.\n\n![birthday balloons](https://about.gitlab.com/images/blogimages/balloons.jpg){: .shadow.small.center}\n\n## Why Git flow doesn’t always go with the flow\n\nYou can have too much of a good thing, and if you doubt that, perhaps it’s because you haven’t yet encountered Git flow. Although designed to streamline development it ends up creating extra effort – too many branches and too much task switching. Never fear, though, [we have a solution](/blog/what-is-gitlab-flow/).\n\n## Git goes (really) big\n\nWhen Git was invented 15 years ago, video streaming (and gaming) weren’t even on the horizon. Git can handle those huge files but there’s one hiccup: You can’t just download the one you need, Git insists you download all of them. Enter Git Partial Clone which speeds up the process so you can just grab the file you need. [Here’s how it works](/blog/partial-clone-for-massive-repositories/).\n\n## GitLab and GitHub on Git\n\nOur senior developer evangelist [Brendan O’Leary](/company/team/#brendan) did a bit of a point counter-point about Git and its past and future with GitHub’s distinguished software engineer [Jeff King](https://www.linkedin.com/in/pefflinkedin/) on [infoq.com](https://www.infoq.com/news/2020/04/git-fifteen-anniversary-qa/).\n\n## Never say never\n\nBrendan also admitted that 15 years ago, he was never ever going to use Git. Ahem. Feel free to enjoy [his mea culpa](https://www.computerweekly.com/blog/Open-Source-Insider/GitLab-guru-15-years-later-were-still-learning).\n\n## Dive into GitOps\n\nYou’ve heard the term, now is the time to understand what [GitOps](/solutions/gitops/) means and how it can work – well – in real world applications. Here’s what you need to know about [continuous delivery to production](/blog/why-gitops-should-be-workflow-of-choice/).\n\nImage by [Adi Gold](https://unsplash.com/@adigold1) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[3058,1187,9],{"slug":6201,"featured":6,"template":683},"ultimate-git-guide","content:en-us:blog:ultimate-git-guide.yml","Ultimate Git Guide","en-us/blog/ultimate-git-guide.yml","en-us/blog/ultimate-git-guide",{"_path":6207,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6208,"content":6214,"config":6219,"_id":6221,"_type":13,"title":6222,"_source":15,"_file":6223,"_stem":6224,"_extension":18},"/en-us/blog/unifylogsmetrics",{"title":6209,"description":6210,"ogTitle":6209,"ogDescription":6210,"noIndex":6,"ogImage":6211,"ogUrl":6212,"ogSiteName":670,"ogType":671,"canonicalUrls":6212,"schema":6213},"How to integrate operation logs and metrics in GitLab","We've added Elasticsearch to our monitoring solution so you can see all your logs and metrics in one view. Here's a first look at this new feature, released in GitLab 12.8.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666923/Blog/Hero%20Images/logs.png","https://about.gitlab.com/blog/unifylogsmetrics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to integrate operation logs and metrics in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-03-03\",\n      }",{"title":6209,"description":6210,"authors":6215,"heroImage":6211,"date":6216,"body":6217,"category":849,"tags":6218},[1454],"2020-03-03","\nLogging is one of the most powerful tools we have when trying to understand an application problem. It is a common practice – when things go wrong in production, one of the first requests is often, \"Please send me the logs!\" Raw logs contain useful information which can help pinpoint the root cause(s) of problems.\n\nBut using raw logs isn’t always a straightforward process. This is especially true, in a modern, distributed, and often ephemeral architecture. Ideally logs should be available across the entire application, be searchable and offer at least some access to past history. Historically aggregated logging solutions, if they existed, were only piecemeal. This forced developers to spend time and energy tracking down important log data which ultimately resulted in logs being far less useful than they could be.\n\nWith the [12.8 release](/releases/2020/02/22/gitlab-12-8-released/), to ease navigating through logs, we added [Elastic log Stack](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html) as our log aggregation tool and [Log Explorer](/releases/2020/02/22/gitlab-12-8-released/#explore-aggregated-logs) so you can interact with all your logs in one place.\n\nBut before we look at the logging capabilities, let’s take a step back and look at the big picture.\n\n##  Why monitoring matters\n\nAt GitLab, we aim to provide users with a complete [DevSecOps platform](/solutions/security-compliance/), delivered as a single application. To do so, we have divided the DevSecOps lifecycle into [ten different stages](/stages-devops-lifecycle/). The final Ops stage of the [DevOps](/topics/devops/) loop, [Monitor](/direction/monitor/), should occur right after the production environment is configured and the application deployed. This is a critical stage that should not be ignored.\n\nIn fact, it’s commonly believed in the DevOps world that no developer should ship code into production without monitoring, as it will help ensure an application behaves as expected. If something isn’t right, you will be alerted, (hopefully before your users start to complain). If you are thinking about ignoring monitoring, always remember _customers_ are the most expensive monitoring solution you can have.\n\n### Chasing Observability\n\nObservability is the ability to infer internal states of a system based on the system’s external outputs. Monitoring, on the other hand is the activity of observing the state of a system over time. To achieve observability, your system’s telemetries, including metrics, traces, and logs should all be available to enable proactive introspection and enable greater operational visibility. We believe that DevOps practitioners should have observability as a goal.\n\nGitLab’s vision for the Monitor category is to build a consolidated and integrated observability tool which will, over time, displace today's front-runner in modern observability. In pursuit of this vision and to focus our efforts, we are building our solutions with a cloud native first principle to solve the cloud native problem by selecting the open source products which are cloud native compatible. And, in fact, as part of GitLab’s [New Year’s gift for 2020](/blog/observability/) we're moving a big portion of the observability features – custom metrics, logging, tracing and alerting – from our proprietary codebase to the open source codebase this year.\n\n### Metrics & Traces\n\nToday, if you use GitLab to deploy your application into a Kubernetes cluster, with a push of a button you can deploy monitoring (via a Prometheus instance) into that cluster. [Prometheus](https://prometheus.io/) will automatically start collecting key metrics from your deployed application (such as latency, error rate, and throughput), and send it directly into GitLab UI. In addition to the out-of-the-box metrics and dashboard, it is possible to customize Prometheus directly from the GitLab UI (using PromQL) to collect any metric you desire and present it on a dashboard. You can set up a threshold, create an alert on it, and open an issue as a part of an incident management solution, all without leaving the GitLab UI.\n\nAs a developer, when there is an issue - you want to drill down to the exact function or micro service that is causing the trouble. GitLab uses [Jaeger](https://www.jaegertracing.io/), an end-to-end distributed tracing system for microservices-based distributed systems.\n\n## Get started with logs\n\nBefore the 12.8 release, existing Monitor stage users already had the ability to view pod logs directly from within the GitLab UI. However, this was done only through the available Kubernetes APIs. Viewing logs with the Kubernetes APIs is limited to allowing a log-tailing experience on a specific pod from multiple environments only.\n\nWith the 12.8 release any user can deploy Elastic stack - a specific flavor of Elasticsearch alongside a component called [Filebeat](https://www.elastic.co/beats/filebeat) - to a Kubernetes cluster with the push of a button, (similar to the way we deploy Prometheus). Once deployed, it automatically starts collecting all logs that are coming from the cluster and applications across the available environments (production, staging, testing, etc.) and they will be surfaced in the GitLab UI. In addition users can also navigate directly from the metric chart to the log explorer while preserving the context.\n\nThis is extremely critical when triaging an incident or validating the status of your service. In the cloud-native world aggregation of logs for observability becomes critical as logs are distributed across multiple pods and services. Using our new solution you will be able to get an aggregated view of all logs across multiple services and infrastructures, go back in time, search through logs, and more.\n\n##  What's next\n\nI hope you found this overview useful. To get started, download GitLab and read its documentation for more in-depth coverage of the functionality. One of the fastest ways to experience GitLab features is to use the .com version — which is a hosted GitLab.\n\nIf you would like to get in touch with the Monitoring team please comment and contribute to the linked [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aapm&label_name[]=Category%3ALogging) and [epics](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aapm&label_name[]=Category%3ALogging) on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.\n\nIf you're a GitLab user and have direct knowledge of your logging usage, we'd especially love to hear your use case(s).\n\nWatch my entire YouTube video on logging:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/hWclZHA7Dgw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[1936,1187,9],{"slug":6220,"featured":6,"template":683},"unifylogsmetrics","content:en-us:blog:unifylogsmetrics.yml","Unifylogsmetrics","en-us/blog/unifylogsmetrics.yml","en-us/blog/unifylogsmetrics",{"_path":6226,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6227,"content":6233,"config":6238,"_id":6240,"_type":13,"title":6241,"_source":15,"_file":6242,"_stem":6243,"_extension":18},"/en-us/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"title":6228,"description":6229,"ogTitle":6228,"ogDescription":6229,"noIndex":6,"ogImage":6230,"ogUrl":6231,"ogSiteName":670,"ogType":671,"canonicalUrls":6231,"schema":6232},"Unveiling a new epic experience for improved Agile planning","Explore the update for GitLab epics that enhances planning and improves workflows – all with seamless migration for better project management.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660011/Blog/Hero%20Images/blog-image-template-1800x945__21_.png","https://about.gitlab.com/blog/unveiling-a-new-epic-experience-for-improved-agile-planning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unveiling a new epic experience for improved Agile planning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-03\",\n      }",{"title":6228,"description":6229,"authors":6234,"heroImage":6230,"date":6235,"body":6236,"category":1228,"tags":6237},[1225],"2024-07-03","In our ongoing journey to enhance the Agile planning experience in GitLab, we [recently unveiled a new look](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/). This update marks a significant step toward creating a unified and flexible planning tool tailored to your needs. This article explores a crucial part of that initiative: the new epic experience. You'll learn about upcoming epic features and the motivations behind these changes, which are designed to elevate your project management capabilities.\n\n## Why the new epic experience?\n\n### Addressing user feedback\nAs part of our mission to provide a comprehensive Agile planning experience, we've listened closely to your feedback. Users have highlighted challenges with the current epic implementation, such as inconsistent features between epics and issues and a lack of flexibility to support diverse workflows. Some pain points focused on workflow tools, including the absence of assignees on epics and a lack of reusable templates. The new epic experience addresses these pain points and makes Agile planning more intuitive and efficient.\n\n### Unified Work Items framework\nTo tackle these issues, we've introduced a unified Work Items framework. This new architecture ensures consistency across all planning objects — epics, issues, and tasks — simplifying the user experience and enhancing functionality. By consolidating the underlying code, we can deliver new features and improvements faster, ensuring a smoother and more reliable planning process.\n\n> Read more about [what is to come with GitLab Agile planning](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/).\n\n## Key features of the new epic experience\n\n### Enhanced detail page\nOne of the most notable changes is the revamped epic detail page. The new design offers a cleaner, more intuitive interface, making it easier to manage and track your epics.\n\nHere are some new key features:\n* **Assignees** - assign epics to team members, improving accountability and oversight.\n* **Health status** - quickly gauge the status of your epics with new health indicators.\n* **Time tracking** - create better visibility over time spent and ensure efficient use of resources across your projects.\n* **Ancestry** - view the entire hierarchy lineage of the epic.\n* **Condensed description** - easily view long work item descriptions without having to scroll excessively. Descriptions are truncated by default, with a \"Show more\" link to expand the full text on demand. This streamlines your workflow by allowing you to quickly scan descriptions and only expand them when needed, reducing clutter and improving readability.\n* **Custom color** - customize the color related to epics viewed on the roadmap now with the ability to define a custom color, use HEX or RGB codes, or choose from an expanded predefined palette. \n\n![new epic experience screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674437/Blog/Content%20Images/Screenshot_2024-07-10_at_4.22.45_p.m..png)\n\n### Consistency across planning objects\nThe new epic experience aligns closely with the new issues experience coming soon (spoiler alert!) and tasks, providing a seamless and cohesive user experience. This consistency helps streamline workflows and reduces the learning curve for new users.\n\n### Additional functionality\nWe plan to iteratively add exciting new features that will enhance your planning capabilities. Our goal is to allow you to tailor planning processes within GitLab to best fit your organization’s unique needs. Once we’ve released the new epics experience, you can expect to see additional functionality with every release! There are many great features to come – here are some of my favorites:\n- [Templates](https://gitlab.com/gitlab-org/gitlab/-/issues/428690)\n- [Custom fields](https://gitlab.com/groups/gitlab-org/-/epics/235)\n- [Configurable statuses](https://gitlab.com/groups/gitlab-org/-/epics/5099)\n- [Project-level epics](https://gitlab.com/gitlab-org/gitlab/-/issues/31840)\n- [Cloning](https://gitlab.com/gitlab-org/gitlab/-/issues/339768)\n- [Moving to another group/project](https://gitlab.com/gitlab-org/gitlab/-/issues/339766)\n- [Milestones](https://gitlab.com/groups/gitlab-org/-/epics/329)\n\n## Migration expectations\nWe understand that any change can be disruptive, so we've designed the migration to the new epic experience to be as seamless as possible. All existing epic data, APIs, and URLs will continue to function as expected. Users do not need to take any action to prepare for this transition. For our self-managed customers, learn how you can preview the new experience in a test environment ahead of general availability [here](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html).\n\n## Community feedback and engagement\nWe value your input and encourage you to share your experiences with the new epic experience. Your feedback is essential to help refine and improve our tools. Please visit our [epic experience feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/494462) to provide your thoughts and suggestions.\n\n## What's next\nThe new epic experience in GitLab represents a significant leap forward in our Agile planning capabilities. With enhanced features, improved consistency, and a user-centric approach, we are confident that these changes will greatly benefit your project management processes. We invite you to explore the new features, provide feedback, and stay tuned for more updates as we continue to innovate and improve.\n\n> [Bookmark this page](https://about.gitlab.com/blog/categories/agile-planning/) to keep up with our Agile planning news.",[1164,478,9,701,894],{"slug":6239,"featured":6,"template":683},"unveiling-a-new-epic-experience-for-improved-agile-planning","content:en-us:blog:unveiling-a-new-epic-experience-for-improved-agile-planning.yml","Unveiling A New Epic Experience For Improved Agile Planning","en-us/blog/unveiling-a-new-epic-experience-for-improved-agile-planning.yml","en-us/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"_path":6245,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6246,"content":6252,"config":6258,"_id":6260,"_type":13,"title":6261,"_source":15,"_file":6262,"_stem":6263,"_extension":18},"/en-us/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab",{"title":6247,"description":6248,"ogTitle":6247,"ogDescription":6248,"noIndex":6,"ogImage":6249,"ogUrl":6250,"ogSiteName":670,"ogType":671,"canonicalUrls":6250,"schema":6251},"Unveiling the GUARD framework to automate security detections at GitLab","The GitLab Universal Automated Response and Detection (GUARD) framework spans creation, maintenance, alert routing and handling, rich metrics collection, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659684/Blog/Hero%20Images/AdobeStock_479904468__1_.jpg","https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unveiling the GUARD framework to automate security detections at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Harjeet Sharma\"},{\"@type\":\"Person\",\"name\":\"Valentine Mairet\"},{\"@type\":\"Person\",\"name\":\"Matt Coons\"}],\n        \"datePublished\": \"2024-11-26\",\n      }",{"title":6247,"description":6248,"authors":6253,"heroImage":6249,"date":6255,"body":6256,"category":704,"tags":6257,"updatedDate":6255},[6254,3680,4204],"Harjeet Sharma","2024-11-26","[GitLab Security Operations](https://handbook.gitlab.com/handbook/security/security-operations/) leverages automation as a guiding principle to ensure our security engineers have the time to focus on what matters, not manual mundane tasks that can be standardized and automated. We applied this principle to securing the GitLab.com SaaS platform, which generates terabytes of log data daily and requires the GitLab Security team to standardize, automate, and scale security workflows for enhanced protection and efficiency. The result: a new framework we call GitLab Universal Automated Detection and Response, or GUARD – a collaboration between the GitLab [Security Incident Response Team (SIRT)](https://handbook.gitlab.com/handbook/security/security-operations/sirt/) and the [Signals Engineering Team](https://handbook.gitlab.com/handbook/security/security-operations/signals-engineering/).\n\nGUARD covers all aspects of security detection, including:\n* creation\n* maintenance\n* alert routing and handling\n* rich metrics collection\n* alert closure or incident escalation workflow \n\n## The goals of GUARD  \n\nGUARD was created and designed with a set of key goals: \n\n1. **Standardization of SIRT’s detection and alerting pipeline** to produce high-quality detections using a peer reviewed and automation-first focus  \n2. **Reduction of alert fatigue** through alert consolidation, deduplication, risk scoring, and automated feedback  \n3. **Metrics** to measure response efficiency and identify problems early  \n4. **GitLab at the core** by leveraging GitLab as a single source of truth for detection definitions\n\n## GUARD's design principles\n\nGUARD was created out of necessity, with a clear vision of the intended state. Before GUARD, detections did not follow a standard format, alerting metrics were not available, and detection creation and maintenance were ad-hoc. Building a framework that was scalable, GitLab-centric, and able to automate manual tasks was core to the success of GUARD. Due to time efficiencies realized by GUARD, SecOps engineers have more time to solve difficult problems and handle complex incidents. \n\n## GUARD components \n\nThe GUARD framework consists of multiple modules. At the center of GUARD is the GitLab platform itself, acting as a single source of truth for detection rules and providing SIRT the ability to automatically deploy detections as code using GitLab CI/CD. \n\nGUARD includes the following components: \n\n- Detection as Code (DaC) - Deploys detections through the GitLab CI/CD pipeline.  \n- User Attestation Module - Allows GitLab team members to attest to activities flagged as potentially malicious.  \n- Enrichments - Polling historical and contextual information to enrich alerts to make alert triage easier.  \n- Alert Triage and Response - Providing a standard alert triage format and templated escalation actions.  \n- Metrics Generation - Gathering insights on alert handling. \n\nEach GUARD module works together to standardize, automate, and iteratively improve GitLab’s security detections and alerting pipeline. \n\n## GitLab at the core\n\nGitLab is core to critical components of GUARD, acting as a single source for threat detections, automating GUARD’s DaC pipeline through GitLab CI/CD, and acting as a “front end” for GUARD, through which security engineers can add, edit and delete threat detections. \n\nHow GitLab features use GUARD: \n\n- [GitLab projects](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html): GUARD utilizes a GitLab project repository as the single source for GUARD threat detections, stored in JSON format.   \n- [GitLab MRs](https://docs.gitlab.com/ee/user/project/merge_requests/): Any changes to GUARD detections, including new detections utilize GitLab MRs against the main GUARD project. A detailed MR template is utilized in which we validate and record details about the detection being added, edited, or deleted. MR approval rules, including the use of CodeOwners and protected branches, are used to ensure proper detection reviews are completed before merging.   \n- [GitLab issues](https://docs.gitlab.com/ee/user/project/issues/): Bug submissions or other engineering efforts related to GUARD are recorded in GitLab issues.   \n- [GitLab labels](https://docs.gitlab.com/ee/user/project/labels.html): A set of standardized labels ensure security engineers document GUARD changes in a way that is easy to track.   \n- [GitLab CI/CD](https://docs.gitlab.com/ee/ci/): GUARD uses a GitLab CI pipeline to automate the deployment of new/changed/deleted detections to GitLab’s security incident and event management (SIEM). GUARD’s CI pipeline performs a number of validation, testing, and quality checks before successfully passing the pipeline and committing the changes to GitLab’s SIEM platform. \n\n## Metrics generation\n\nInteractions with the alert handling UI are recorded to generate key performance metrics, such as Time to Respond, Time to Resolve, and insights into alerts like true/false positive rates. Additional metadata collected includes an emoji-based sentiment analysis. Engineers handling alerts provide ‘feedback’ about the alerts handled in the form of emojis, so we can take that feedback into account upon iterating on detection rules. \n\nAlert handling metrics are stored in a separate database to create visualizations consulted by engineers and management. These are key to understanding team performance in alert resolution and alert fidelity so that we can always improve.  \n\n## Iterate with us\n\nUsing GitLab as a single source of truth for threat detection code allowed GUARD to extract processes from a specific SIEM technology, supporting greater flexibility, ease of use, modularization, and auditability. \n\n[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is a core GitLab value – we start with the smallest valuable thing to get fast feedback and efficiently reach a desired end goal. GUARD is no different, and we hope sharing GUARD will help readers iterate towards their own automation improvements. \n\n*This article is the first in a series on GitLab GUARD. Next, we will share details about various aspects of our iterative journey to implement GUARD at GitLab.*",[704,9,478],{"slug":6259,"featured":90,"template":683},"unveiling-the-guard-framework-to-automate-security-detections-at-gitlab","content:en-us:blog:unveiling-the-guard-framework-to-automate-security-detections-at-gitlab.yml","Unveiling The Guard Framework To Automate Security Detections At Gitlab","en-us/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab.yml","en-us/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab",{"_path":6265,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6266,"content":6272,"config":6278,"_id":6280,"_type":13,"title":6281,"_source":15,"_file":6282,"_stem":6283,"_extension":18},"/en-us/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace",{"title":6267,"description":6268,"ogTitle":6267,"ogDescription":6268,"noIndex":6,"ogImage":6269,"ogUrl":6270,"ogSiteName":670,"ogType":671,"canonicalUrls":6270,"schema":6271},"Use GitLab AI features out-of-the-box in a GitLab Workspace","GitLab Workspaces now ships with the GitLab workflow extension preinstalled, providing access to powerful AI features like GitLab Duo Chat and Code Suggestions for increased productivity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098843/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750098843047.png","https://about.gitlab.com/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Use GitLab AI features out-of-the-box in a GitLab Workspace\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Safwan Ahmed\"}],\n        \"datePublished\": \"2024-07-24\",\n      }",{"title":6267,"description":6268,"authors":6273,"heroImage":6269,"date":6275,"body":6276,"category":806,"tags":6277},[6274],"Safwan Ahmed","2024-07-24","AI is transforming the way we get work done, from helping automate mundane tasks to optimizing aspects of our day-to-day workflow. Of particular relevance has been [generative AI’s ability](https://about.gitlab.com/the-source/ai/how-to-put-generative-ai-to-work-in-your-devsecops-environment/) to support developers in getting the job done, from code snippet suggestions to concise summaries of technical questions. These AI tools have been embedded in the development lifecycle through integrations with existing software like code editors and CI/CD platforms. Thanks to these integrations, particularly in the case of code editors, developers can have an AI assistant that complements their skills within their development environment.\n\nWhile these AI tools can help boost productivity, setting them up in an existing development environment may not be preferable. For example, you may not want to install a new dependency on your local workstation that could affect your setup, you may have security or privacy concerns about running AI tools on your computer, or you may find it hard to give the tooling context on your existing workflow. GitLab resolves these issues by providing a suite of tools that allow you to leverage the power of AI in [a remote development workspace](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) right out of the box. In this blog, you'll learn about the GitLab features that make this possible and how to set up your [workspace environment](https://docs.gitlab.com/ee/user/workspace/) to get started.\n\n## GitLab workflow extension for VS Code\n\nGitLab workflow extension for VS Code integrates GitLab into the VS Code editor. It brings into scope key elements of your GitLab workflow such as issues, merge requests, and pipeline status. For more information, visit [the GitLab workflow extension documentation](https://docs.gitlab.com/ee/editor_extensions/visual_studio_code/).\n\n## GitLab Workspaces\n\nGitLab Workspaces provide an isolated development environment to make changes to your GitLab projects. Workspaces offer a platform to work on your projects without the complexity of setting up local dependencies. Workspaces also provide reproducible development setups, as a workspace environment configuration created by one developer can be shared with others. GitLab Workspaces are configured to use the VS Code editor and ship with the workflow extension preinstalled. To learn more, visit the [GitLab Workspaces documentation](https://docs.gitlab.com/ee/user/workspace/).\n\n## GitLab Duo Chat and Code Suggestions\n\n[GitLab Duo Chat](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available) and [GitLab Duo Code Suggestions](https://about.gitlab.com/blog/gitlab-duo-code-suggestions-is-generally-available/) are part of the GitLab Duo suite of AI features enhancing developer productivity. Chat and Code Suggestions are integrated into the workflow extension and are GitLab context-aware. This allows you to ask GitLab Duo questions about items like issues and merge requests and to automatically have access to code suggestions and code completion. This integration requires [a GitLab Duo license](https://about.gitlab.com/gitlab-duo/). See the [GitLab Duo Chat documentation](https://docs.gitlab.com/ee/user/gitlab_duo_chat/) and [GitLab Duo Code Suggestions documentation](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/) for more information.\n\n## How to set up the Workflow extension, Workspaces, and GitLab Duo to work together\n\nWhile these features are impressive on their own, when combined they deliver on the promise of an easy-to-spin-up, isolated, AI-driven development environment. Here are the steps to get this powerhouse up and running.\n\n## Create a workspace\n\nFollow this [comprehensive but easy-to-follow tutorial](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) to create a remote development workspace.\n\n## Validate GitLab Workflow is active\n\nAfter your workspace is up and running, you should see a GitLab icon on the side of your editor like the following:\n\n![Arrow pointing to GitLab tanuki icon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098853/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098853108.png)\n\nYou can then use the workflow extension to bring up merge requests assigned to you in the current project in GitLab. To do this, access the command palette by hitting `command + shift + P` and entering `GitLab: Show Merge Requests Assigned to Me`. This will redirect you to GitLab and show your assigned MRs.\n\n![Arrow pointing to 'GitLab: Show Merge Requests Assigned to Me'](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098853/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098853109.png)\n\nFor more tips and tricks, read [Visual Studio code editor: Eight tips for using GitLab VS Code](https://about.gitlab.com/blog/vscode-workflows-for-working-with-gitlab/).\n\n## Use GitLab Duo Chat\n\nYou should also see a second, smaller GitLab icon on your sidebar. This gives you access to GitLab Duo Chat. Feel free to ask it a question.\n\n![Arrow pointing to GitLab tanuki icon with sparkles around it](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098853/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098853111.png)\n\n## Use GitLab Duo Code Suggestions\n\nOpen up any source file in your directory. You can begin typing code and have predictive suggestions, powered by GitLab Duo Code Suggestions, pop up –  you can insert them by hitting the tab key. The example below shows my attempt to write a string processing function. Code Suggestions has inferred I would want to split the passed string into spaces, which is indeed my intention.\n\n![Code Suggestions suggesting that the passed string into spaces](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098853/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098853112.png)\n\nSuppose I have completed my string processing function above and would like to generate unit tests for it but want to avoid the chore of writing boilerplate code. You can provide a comment in your editor and have Code Suggestions generate code for you like the following:\n\n![Shows boilerplate code for generating unit tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098853/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098853115.png)\n\nCode Suggestions implements a whole unit test for my function, covering happy and sad paths.\n\nFor more exciting uses of the GitLab Duo suite, check out these articles:\n* [10 best practices for using AI-powered GitLab Duo Chat](https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/)\n* [Top tips for efficient AI-powered Code Suggestions with GitLab Duo](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/)\n* [\"Developing GitLab Duo\" blog series](https://about.gitlab.com/blog/developing-gitlab-duo-series/)\n\n# Next steps\n\nGitLab Workspaces is coming up with more exciting integrations and features that will enhance your remote development experience, be sure to check out the [category epic](https://gitlab.com/groups/gitlab-org/-/epics/7419) to know what’s coming next!\n\n> Sign up for [a free trial of GitLab Duo](https://about.gitlab.com/gitlab-duo/) today!\n",[786,894,230,9],{"slug":6279,"featured":90,"template":683},"use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace","content:en-us:blog:use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace.yml","Use Gitlab Ai Features Out Of The Box In A Gitlab Workspace","en-us/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace.yml","en-us/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace",{"_path":6285,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6286,"content":6292,"config":6296,"_id":6298,"_type":13,"title":6299,"_source":15,"_file":6300,"_stem":6301,"_extension":18},"/en-us/blog/use-gitlab-duo-to-build-and-deploy-a-simple-quarkus-native-project",{"title":6287,"description":6288,"ogTitle":6287,"ogDescription":6288,"noIndex":6,"ogImage":6289,"ogUrl":6290,"ogSiteName":670,"ogType":671,"canonicalUrls":6290,"schema":6291},"Use GitLab Duo to build and deploy a simple Quarkus-native project","This tutorial shows how a Java application is compiled to machine code and deployed to a Kubernetes cluster using a CI/CD pipeline. See how AI makes the process faster and more efficient.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666069/Blog/Hero%20Images/AdobeStock_639935439.jpg","https://about.gitlab.com/blog/use-gitlab-duo-to-build-and-deploy-a-simple-quarkus-native-project","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Use GitLab Duo to build and deploy a simple Quarkus-native project\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2024-10-17\",\n      }",{"title":6287,"description":6288,"authors":6293,"heroImage":6289,"date":5131,"body":6294,"category":806,"tags":6295},[803],"In [“How to automate software delivery using Quarkus and GitLab,”](https://about.gitlab.com/blog/how-to-automate-software-delivery-using-quarkus-and-gitlab/) you learned how to develop and deploy a simple Quarkus-JVM application to a Kubernetes cluster using [GitLab Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/). Now, you'll learn how to use Quarkus-native to compile a Java application to machine code and deploy it to a Kubernetes cluster using a CI/CD pipeline. Follow our journey from development to deployment leveraging [GitLab Duo](https://about.gitlab.com/gitlab-duo/) as our AI companion, including the specific prompts we used.\n\n## What is Quarkus?\n\n[Quarkus](https://quarkus.io/), also known as the Supersonic Subatomic Java, is an open source, Kubernetes-native Java stack tailored to OpenJDK HotSpot and GraalVM. The Quarkus project recently moved to the [Commonhaus Foundation](https://www.commonhaus.org/), a nonprofit organization dedicated to the sustainability of open source libraries and frameworks that provides a balanced approach to governance and support.\n\n## Prerequisites\n\nThis tutorial assumes:\n\n- You have a running Kubernetes cluster, e.g. GKE.\n- You have access to the Kubernetes cluster from your local laptop via the `kubectl` command.\n- The cluster is connected to your GitLab project.\n- You have [Maven (Version 3.9.6 or later)](https://maven.apache.org/) installed on your local laptop.\n- You have Visual Studio Code installed on your local laptop.\n\nIf you’d like to set up a Kubernetes cluster connected to your GitLab project, you can follow the instructions in this [tutorial](https://about.gitlab.com/blog/eliminate-risk-with-feature-flags-tutorial/), up to but not including the “Creating an instance of MySQL database in your cluster via Flux” section (you do not need a database for this tutorial).\n\nYou will also need to install an nginx ingress in your Kubernetes cluster. Here are two ways to do this:\n1. You can follow the instructions in [“Creating and importing projects”](https://about.gitlab.com/blog/eliminate-risk-with-feature-flags-tutorial/#creating-and-importing-projects), up to the creation of the variable `KUBE_INGRESS_BASE_DOMAIN`.\n2. Or, just create an ingress in your Kubernetes cluster by following the instructions in our [Auto DevOps with GKE documentation](https://docs.gitlab.com/ee/topics/autodevops/cloud_deployments/auto_devops_with_gke.html#install-ingress).\n\n**NOTE:** For this article, we used the first method above to install an ingress and cert-manager in the Kubernetes cluster.\n\n## Creating necessary project files using GitLab Duo Chat\n\nWe started our endeavor from VS Code and an empty project called `quarkus-native`, which we had previously created in GitLab and had already cloned to our local laptop.\n\n1. We opened GitLab Duo Chat, within VS Code, and entered the following prompt:\n\n**_Create a “Hello World” Quarkus application that can be natively compiled_**\n\n![hello-world-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/hello-world-prompt.png)\n\nChat replied with the prerequisites and process of what to do to create a simple “Hello World” Quarkus application. At this point, we were after the generated body of the class `HelloResource.java`:\n\n```\npackage org.acme;\n\nimport javax.ws.rs.GET;\nimport javax.ws.rs.Path;\nimport javax.ws.rs.Produces;\nimport javax.ws.rs.core.MediaType;\n\n@Path(\"/hello\")\npublic class HelloResource {\n\n    @GET\n    @Produces(MediaType.TEXT_PLAIN)\n    public String hello() {\n        return \"Hello World\";\n    }\n}\n```\n\n2. We knew that for Quarkus we needed a special Dockerfile, named `Dockerfile.native`, as part of the creation of the image for the application executable. We then entered the following prompt in Chat:\n\n**_Create the Dockerfile.native file for the sample application above_**\n\n![create-dockerfile-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675941/Blog/Content%20Images/create-dockerfile-prompt.png)\n\nChat replied with a very thorough answer about this file, its contents, and the containerization process. At this point, we were just after the generated body of the file `Dockerfile.native`:\n\n```\n####\n# This Dockerfile is used in order to build a container that runs the Quarkus application in native (no JVM) mode\n####\nFROM registry.access.redhat.com/ubi8/ubi-minimal:8.6\nWORKDIR /work/\nRUN chown 1001 /work \\\n    && chmod \"g+rwX\" /work \\\n    && chown 1001:root /work\nCOPY --chown=1001:root target/*-runner /work/application\n\nEXPOSE 8080\nUSER 1001\n\nCMD [\"./application\", \"-Dquarkus.http.host=0.0.0.0\"]\n```\n\n3. Next, we asked Chat to generate the `pom.xml` for this application by entering the following prompt:\n\n**_Create the pom.xml file for the sample application above_**\n\n![create-pom-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/create-pom-prompt.png)\n\nChat provided the content of the `pom.xml` file, an explanation of its contents, and how to use it. At this point, we were after the generated body of the file `pom.xml`:\n\n```\n\u003C?xml version=\"1.0\"?>\n\u003Cproject xsi:schemaLocation=\"http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd\" xmlns=\"http://maven.apache.org/POM/4.0.0\"\n    xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n  \u003CmodelVersion>4.0.0\u003C/modelVersion>\n  \u003CgroupId>org.acme\u003C/groupId>\n  \u003CartifactId>hello-world-quarkus\u003C/artifactId>\n  \u003Cversion>1.0.0-SNAPSHOT\u003C/version>\n  \u003Cproperties>\n    \u003Ccompiler-plugin.version>3.10.1\u003C/compiler-plugin.version>\n    \u003Cmaven.compiler.release>11\u003C/maven.compiler.release>\n    \u003Cproject.build.sourceEncoding>UTF-8\u003C/project.build.sourceEncoding>\n    \u003Cproject.reporting.outputEncoding>UTF-8\u003C/project.reporting.outputEncoding>\n    \u003Cquarkus.platform.artifact-id>quarkus-bom\u003C/quarkus.platform.artifact-id>\n    \u003Cquarkus.platform.group-id>io.quarkus.platform\u003C/quarkus.platform.group-id>\n    \u003Cquarkus.platform.version>2.16.5.Final\u003C/quarkus.platform.version>\n    \u003CskipITs>true\u003C/skipITs>\n    \u003Csurefire-plugin.version>3.0.0-M7\u003C/surefire-plugin.version>\n  \u003C/properties>\n  \u003CdependencyManagement>\n    \u003Cdependencies>\n      \u003Cdependency>\n        \u003CgroupId>${quarkus.platform.group-id}\u003C/groupId>\n        \u003CartifactId>${quarkus.platform.artifact-id}\u003C/artifactId>\n        \u003Cversion>${quarkus.platform.version}\u003C/version>\n        \u003Ctype>pom\u003C/type>\n        \u003Cscope>import\u003C/scope>\n      \u003C/dependency>\n    \u003C/dependencies>\n  \u003C/dependencyManagement>\n  \u003Cdependencies>\n    \u003Cdependency>\n      \u003CgroupId>io.quarkus\u003C/groupId>\n      \u003CartifactId>quarkus-arc\u003C/artifactId>\n    \u003C/dependency>\n    \u003Cdependency>\n      \u003CgroupId>io.quarkus\u003C/groupId>\n      \u003CartifactId>quarkus-resteasy\u003C/artifactId>\n    \u003C/dependency>\n    \u003Cdependency>\n      \u003CgroupId>io.quarkus\u003C/groupId>\n      \u003CartifactId>quarkus-junit5\u003C/artifactId>\n      \u003Cscope>test\u003C/scope>\n    \u003C/dependency>\n    \u003Cdependency>\n      \u003CgroupId>io.rest-assured\u003C/groupId>\n      \u003CartifactId>rest-assured\u003C/artifactId>\n      \u003Cscope>test\u003C/scope>\n    \u003C/dependency>\n  \u003C/dependencies>\n  \u003Cbuild>\n    \u003Cplugins>\n      \u003Cplugin>\n        \u003CgroupId>${quarkus.platform.group-id}\u003C/groupId>\n        \u003CartifactId>quarkus-maven-plugin\u003C/artifactId>\n        \u003Cversion>${quarkus.platform.version}\u003C/version>\n        \u003Cextensions>true\u003C/extensions>\n        \u003Cexecutions>\n          \u003Cexecution>\n            \u003Cgoals>\n              \u003Cgoal>build\u003C/goal>\n              \u003Cgoal>generate-code\u003C/goal>\n              \u003Cgoal>generate-code-tests\u003C/goal>\n            \u003C/goals>\n          \u003C/execution>\n        \u003C/executions>\n      \u003C/plugin>\n      \u003Cplugin>\n        \u003CartifactId>maven-compiler-plugin\u003C/artifactId>\n        \u003Cversion>${compiler-plugin.version}\u003C/version>\n        \u003Cconfiguration>\n          \u003CcompilerArgs>\n            \u003Carg>-parameters\u003C/arg>\n          \u003C/compilerArgs>\n        \u003C/configuration>\n      \u003C/plugin>\n      \u003Cplugin>\n        \u003CartifactId>maven-surefire-plugin\u003C/artifactId>\n        \u003Cversion>${surefire-plugin.version}\u003C/version>\n        \u003Cconfiguration>\n          \u003CsystemPropertyVariables>\n            \u003Cjava.util.logging.manager>org.jboss.logmanager.LogManager\u003C/java.util.logging.manager>\n            \u003Cmaven.home>${maven.home}\u003C/maven.home>\n          \u003C/systemPropertyVariables>\n        \u003C/configuration>\n      \u003C/plugin>\n      \u003Cplugin>\n        \u003CartifactId>maven-failsafe-plugin\u003C/artifactId>\n        \u003Cversion>${surefire-plugin.version}\u003C/version>\n        \u003Cexecutions>\n          \u003Cexecution>\n            \u003Cgoals>\n              \u003Cgoal>integration-test\u003C/goal>\n              \u003Cgoal>verify\u003C/goal>\n            \u003C/goals>\n            \u003Cconfiguration>\n              \u003CsystemPropertyVariables>\n                \u003Cnative.image.path>${project.build.directory}/${project.build.finalName}-runner\u003C/native.image.path>\n                \u003Cjava.util.logging.manager>org.jboss.logmanager.LogManager\u003C/java.util.logging.manager>\n                \u003Cmaven.home>${maven.home}\u003C/maven.home>\n              \u003C/systemPropertyVariables>\n            \u003C/configuration>\n          \u003C/execution>\n        \u003C/executions>\n      \u003C/plugin>\n    \u003C/plugins>\n  \u003C/build>\n  \u003Cprofiles>\n    \u003Cprofile>\n      \u003Cid>native\u003C/id>\n      \u003Cactivation>\n        \u003Cproperty>\n          \u003Cname>native\u003C/name>\n        \u003C/property>\n      \u003C/activation>\n      \u003Cproperties>\n        \u003CskipITs>false\u003C/skipITs>\n        \u003Cquarkus.package.type>native\u003C/quarkus.package.type>\n      \u003C/properties>\n    \u003C/profile>\n  \u003C/profiles>\n\u003C/project>\n```\n\n4. We then asked Chat to generate the Quarkus test file for this application by entering the following prompt:\n\n**_Create the content for the Quarkus test for the application above_**\n\n![create-quarkus-test-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/create-quarkus-test-prompt.png)\n\nChat returned the body for the Quarkus test, how to use it, and the body of the Java class for the test needed for its native compilation. At this point, we were after the generated bodies of the file `HelloResourceTest.java` and `HelloResourceIT.java`.\n\nHere is the generated body for `HelloResourceTest.java`:\n\n```\npackage org.acme;\n\nimport io.quarkus.test.junit.QuarkusTest;\nimport org.junit.jupiter.api.Test;\n\nimport static io.restassured.RestAssured.given;\nimport static org.hamcrest.CoreMatchers.is;\n\n@QuarkusTest\npublic class HelloResourceTest {\n\n    @Test\n    public void testHelloEndpoint() {\n        given()\n          .when().get(\"/hello\")\n          .then()\n             .statusCode(200)\n             .body(is(\"Hello World\"));\n    }\n\n}\n```\n\nHere is the generated body for `HelloResourceIT.java`:\n\n```\npackage org.acme;\n\nimport io.quarkus.test.junit.QuarkusIntegrationTest;\n\n@QuarkusIntegrationTest\npublic class HelloResourceIT extends HelloResourceTest {\n    // Execute the same tests but in native mode.\n}\n```\n\n5. We needed to know how to organize these files in the GitLab project, so we asked about the directory structure for all these files by entering the following prompt in Chat:\n\n**_Give me the entire directory structure for this project including the location of each file, e.g. pom.xml, Dockerfile.native, application.properties, HelloResource.java, HelloResourceTest.java, and the location of the target directory_**\n\n![create-dir-struct-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/create-dir-struct-prompt.png)\n\nChat replied with a detailed diagram about the entire directory structure for the project and where all these files should be located as well as a description of the purpose of each of them. It even mentioned that the directory `target/` and its contents should not be version controlled since it was generated by the build process. Another interesting aspect of the reply was the existence of a file called `resources/application.properties` in the directory structure.\n\n![dir-struct-chat-response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/dir-struct-chat-response.png)\n\nWith all this information in our hands, we were ready to start creating these files in our GitLab project.\n\n## Populating our project with the generated content for each file\n\nWe created each of the following files in their corresponding location and their generated content as provided by Chat:\n\n- `src/main/java/org/acme/HelloResource.java`\n- `resources/application.properties`\n- `src/test/java/org/acme/HelloResourceTest.java`\n- `src/test/java/org/acme/HelloResourceIT.java`\n- `pom.xml`\n- `Dockerfile.native`\n\n**NOTE:** We considered using GitLab Auto Deploy for this endeavor but later realized that it would not be a supported option. We are mentioning this because in the video at the end of this tutorial, you will see that we asked Chat: `How to set the service internalPort to 8080 for auto deploy`. Then we created a file named `.gitlab/auto-deploy-values.yaml` with the generated content from Chat. The creation of this file is not necessary for this tutorial.\n\nBefore we started tackling the pipeline to build, containerize, and deploy the application to our Kubernetes cluster, we decided to generate the executable locally on our Mac and test the application locally.\n\n## Testing the application locally\n\nHere is the process we went through to test the application on our local machine.\n\n1. To build the application on the local Mac laptop, from a Terminal window, we entered the following command:\n\n```\nmvn clean package -Pnative\n```\n\n![first-build](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/first-build.png)\n\nThe native compilation failed with the error message:\n\n`Cannot find the ‘native-image’ in the GRAALVM_HOME, JAVA_HOME and System PATH. Install it using ‘gu install native-image’`\n\n2. So, we used our trusty GitLab Duo Chat again and asked it the following:\n\n**_The command “mvn clean package -Pnative” is failing with error “java.lang.RuntimeException: Cannot find the ‘native-image’ in the GRAALVM_HOME, JAVA_HOME and System PATH. Install it using gu install native-image”. I’m using a MacOS Sonoma. How do I fix this error on my Mac?_**\n\n![how-to-fix-build-failure-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/how-to-fix-build-failure-prompt.png)\n\nChat replied with a detailed set of steps on how to install the necessary software and set the appropriate environment variables.\n\n3. We copied and pasted the following commands from the Chat window to a Terminal window:\n\n```\nbrew install –cask graalvm/tap/graalvm-ce-java17\nexport JAVA_HOME=/Library/Java/JavaVIrtualMachines/graalvm-ce-java17-22.3.1\nexport GRAALVM_HOME=${JAVA_HOME}\nexport PATH=${GRAALVM_HOME}/bin:$PATH\nxattr -r -d com.apple.quarantine ${GRAALVM_HOME}/../..\ngu install native-image\n```\n\nThe commands above installed the community edition of GraalVM Version 22.3.1 that supported Java 17. We noticed, during the brew install, that the version of the GraalVM being installed was `java17-22.3.1`, so we had to update the pasted value for `JAVA_HOME` from `graalvm-ce-java17-22.3.0` to `graalvm-ce-java17-22.3.1`.\n\nWe also had to run the `xattr` command to get the GraalVM, which we had downloaded and installed on our Mac, out of quarantine so that it could run locally. Lastly, we installed the GraalVM native-image.\n\n4. At this point, we again, from a Terminal window, entered the following command to build the application on the local Mac laptop:\n\n```\nmvn clean package -Pnative\n```\n\nThis time the compilation was successful and an executable was generated in the `target` directory.\n\n![successful-local-compilation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/successful-local-compilation.png)\n\n5. We ran the executable by entering the following commands from a Terminal window:\n\n```\ncd target\n./quarkus-native-1.0.0-SNAPSHOT-runner “-Dquarkus.http.host=0.0.0.0”\n```\n\n![executable-local-run](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/executable-local-run.png)\n\n6. With the application running, we opened a browser window, and in the URL field, we entered:\n\n```\nhttp://localhost:8080/hello\n```\n\n![app-running-locally](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/app-running-locally.png)\n\nThe application returned the string `Hello World`, which was displayed in the browser window.\n\nAt this point, we committed and pushed all the changes to our GitLab project and started working on creating a CI/CD pipeline that would build and deploy the application to a Kubernetes cluster running on the cloud.\n\nBut before continuing, we remembered to add, commit, and push a `.gitignore` file to our project that included the path `target/`, since this was the directory where the executable would be created and we didn’t need to keep it - or its contents - under version control.\n\n## Creating the pipeline with GitLab Duo Chat\n\nNow that we had already successfully tested the application locally on our Mac, we needed to create the CI/CD pipeline that would compile the application, containerize it, and deploy it to our Kubernetes cluster. We wanted to keep the pipeline simple, brief, and have a single environment in which to deploy it. To this end, the pipeline would not tackle multiple environments or feature branches, for example.\n\n1. To avoid manually creating a pipeline from scratch, we decided to once again leverage Chat. We entered the following prompt\n\n**_Create a .gitlab-ci.yml file with 3 stages: build, containerize, and deploy. Each of these stages should have a single job with the same name. The build job should compile the application natively using the -Pnative maven option and the builder image for mandrel jdk-22 for java17 and store the application executable and its Dockerfile as artifacts. The containerize job should use docker to build and push the image to the built-in container registry. The deploy job should rollout the containerized application, named quarkus-app, to the production environment in the Kubernetes cluster by creating a deployment resource, a service resource and an ingress rule with host ${KUBE_INGRESS_BASE_DOMAIN} and /hello prefix. The deploy job should also include the url for the production environment. When setting the Kubernetes context, use ${KUBE_CONTEXT}, and for application namespace, use ${KUBE_NAMESPACE}_**\n\n![create-pipeline-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/create-pipeline-prompt.png)\n\nThe prompt above provided some points that we thought would be useful and necessary for a good outcome. The requirements listed by the prompt were:\n\n- It specified that the pipeline needed to have three stages: build, containerize, and deploy.\n- Each stage would have a single job.\n- The build job should natively compile (not build) the application using the -Pnative option.\n- The build job should use the open source software `mandrel` and use the version that would support jdk-22 for Java 17. Remember that these were the versions that we tested on our local machine.\n- The build job would also need to pass the resulting executable and the project Dockerfile to the next job, i.e. containerize, in the pipeline.\n- The containerize job should build a docker image with the executable using the Dockerfile, both of which were passed as artifacts.\n- The containerize job should push the image to the GitLab container registry.\n- The deploy job should use the image from the GitLab container registry, name it `quarkus-app`, and deploy it to the Kubernetes cluster using deployment, service and ingress rule resources.\n- The deploy job should use the environment variables `${KUBE_INGRESS_BASE_DOMAIN}`, `${KUBE_CONTEXT}`, and `${KUBE_NAMESPACE}`, which had been defined as group/project variables, accordingly.\n\nChat responded with the following `.gitlab-ci.yml` example:\n\n```\n# Define the stages for the pipeline\nstages:\n  - build\n  - containerize\n  - deploy\n\n# Variables section to use GitLab CI/CD variables\nvariables:\n  MAVEN_OPTS: \"-Dmaven.repo.local=.m2/repository\"\n  MAVEN_CLI_OPTS: \"--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true\"\n  CONTAINER_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}\n\n# Cache configuration for Maven dependencies\ncache:\n  paths:\n    - .m2/repository\n\n# Build stage: Compile the application natively\nbuild:\n  stage: build\n  image:\n    name: quay.io/quarkus/ubi-quarkus-mandrel-builder-image:22.3-java17\n    entrypoint:\n      - \"\"\n  script:\n    - ./mvnw ${MAVEN_CLI_OPTS} clean package -Pnative\n  artifacts:\n    paths:\n      - target/*-runner\n      - src/main/docker/Dockerfile.native-micro\n  # This job runs only on the main branch\n  only:\n      - main\n\n# Containerize stage: Build and push Docker image\ncontainerize:\n  stage: containerize\n  image: docker:20.10.16\n  services:\n    - docker:20.10.16-dind\n  variables:\n    DOCKER_TLS_CERTDIR: \"/certs\"\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker build -f src/main/docker/Dockerfile.native-micro -t ${CONTAINER_IMAGE} .\n    - docker push ${CONTAINER_IMAGE}\n  # This job runs only on the main branch\n  only:\n      - main\n\n# Deploy stage: Deploy to Kubernetes\ndeploy:\n  stage: deploy\n  image: \n    name: bitnami/kubectl:latest\n    entrypoint: ['']\n  script:\n    - kubectl config use-context ${KUBE_CONTEXT}\n    - kubectl config set-context --current --namespace=${KUBE_NAMESPACE}\n    - |\n      cat \u003C\u003CEOF | kubectl apply -f -\n      apiVersion: apps/v1\n      kind: Deployment\n      metadata:\n        name: quarkus-app\n      spec:\n        replicas: 1\n        selector:\n          matchLabels:\n            app: quarkus-app\n        template:\n          metadata:\n            labels:\n              app: quarkus-app\n          spec:\n            containers:\n            - name: quarkus-app\n              image: ${CONTAINER_IMAGE}\n              ports:\n              - containerPort: 8080\n      ---\n      apiVersion: v1\n      kind: Service\n      metadata:\n        name: quarkus-app\n      spec:\n        selector:\n          app: quarkus-app\n        ports:\n        - port: 80\n          targetPort: 8080\n      ---\n      apiVersion: networking.k8s.io/v1\n      kind: Ingress\n      metadata:\n        name: quarkus-app\n      spec:\n        rules:\n        - host: ${KUBE_INGRESS_BASE_DOMAIN}\n          http:\n            paths:\n            - path: /hello\n              pathType: Prefix\n              backend:\n                service:\n                  name: quarkus-app\n                  port: \n                    number: 80\n      EOF\n    - echo \"Application deployed to https://${KUBE_INGRESS_BASE_DOMAIN}/hello\"\n  # This job runs only on the main branch\n  only:\n      - main\n```\n\n2. There were some things we needed to adjust in the sample `.gitlab-ci.yml` file above before we could commit it to our `main` branch. These are the updates we made to the file:\n\n- We deleted all occurrences of `only: -main` because we wanted to keep of pipeline definition file simple and with no branch-related rules.\n- We fixed the name of the file `Dockerfile.native-micro` to `Dockerfile.native`.\n\n3. At this point, we wanted to ensure that the deployment would be to the `production` environment so we asked Chat the following prompt:\n\n**_What is the syntax to specify an environment with its url in a pipeline?_**\n\n![how-to-add-env-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/how-to-add-env-prompt.png)\n\nThe response from Chat included an example of how to do this so we used this information to add the following environment block to our pipeline:\n\n```\n  environment:\n       name: production\n       url: http://${KUBE_INGRESS_BASE_DOMAIN}/hello\n```\n\n4. The example provided by Chat includes a URL that started with `https` and we modified that to `http` since we didn’t really need a secure connection for this simple application.\n\n5. Lastly, we noticed that in the `build` job, there was a script `mvnw` that we didn’t have in our project. So, we asked Chat the following:\n\n**_How can I get the mvnw script for Quarkus?_**\n\n![how-to-add-mvnw-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/how-to-add-mvnw-prompt.png)\n\nChat responded with the command to execute to bootstrap and create this script. We executed this command from a Terminal window:\n\n```\nmvn wrapper:wrapper\n```\n\nWe were now ready to commit all of our changes to the `main` branch and have the pipeline executed. However, on our first attempt, our first pipeline failed at the build job.\n\n## Troubleshooting using GitLab Duo Root Cause Analysis\n\nOur first attempt at running our brand-new pipeline failed. So, we took advantage of [GitLab Duo Root Cause Analysis](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/), which looks at the job logs and provides a thorough natural language explanation (with examples) of the root cause of the problem and, most importantly, how to fix it.\n\n![build-job-troubleshooting](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/build-job-troubleshooting.png)\n\nRoot Cause Analysis recommended we look at the compatibility of the command that was trying to be executed with the image of mandrel used in the build job. We were not using any command with the image so we concluded that it must have been the predefined `entrypoint` for the image itself. We needed to override this so we asked Chat the following:\n\n**_How do I override the entrypoint of an image using gitlab keywords?_**\n\n![how-to-override-entrypoint-prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/how-to-override-entrypoint-prompt.png)\n\nChat replied with some use case examples of overriding an image entry point. We used that information to update the build job image definition:\n\n```\nbuild:\n    stage: build\n    image: quay.io/quarkus/ubi-quarkus-mandrel-builder-image:22.3-java17\n    entrypoint:\n        - “”\n```\n\nWe committed our changes to the `main` branch, which launched a new instance of the pipeline. This time the build job executed successfully but the pipeline failed at the `containerize` job.\n\n## Running a successful pipeline\n\nBefore drilling down into the log of the failed `containerize` job, we decided to drill into the log of the successfully completed build job first. Everything looked good in the log of the build job with the exception of this warning message at the very end of it:\n\n```\nWARNING: src/main/docker/Dockerfile.native: no matching files. Ensure that the artifact path is relative to the working directory …\n``` \n\nWe took notice of this warning and then headed to the log of the failed `containerize` job. In it, we saw that the `docker build` command had failed due to a non-existent Dockerfile. We ran Root Cause Analysis on the job and among its suggested fixes was for us to verify that the project structure matched the path of the specified `Dockerfile.native` file.\n\n![containerize-job-troubleshooting](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/containerize-job-troubleshooting.png)\n\nThis information confirmed our suspicion of the misplaced `Dockerfile.native` file. Instead of being at the directory `src/main/docker` as specified in the pipeline, it was located at the root directory of the project.\n\nSo, we went back to our project and updated every occurrence of the location of this file in our `.gitlab-ci.yml` file. We modified the two locations where this happened, one in the `build` job and one in the `containerize` job, as follows:\n\n```\nsrc/main/docker/Dockerfile.native\n```\n\nto\n\n```\nDockerfile.native\n```\n\nWe committed our updates to the `main` branch and this time our entire pipeline executed successfully!\n\n![pipeline-successful-run](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/pipeline-successful-run.png)\n\nOur last step was to check the running application in the `production` environment in our Kubernetes cluster.\n\n## Accessing the deployed application running in cluster\n\nOnce the pipeline ran successfully to completion, we drilled in the log file for the `deploy` job. Remember, this job printed the URL of the application at the end of its execution. We scrolled down to the bottom of the log and clicked on the `https` application link, which opened a browser window warning us that the connection was not private (we disabled `https` for the environment URL but forgot it for this string). We proceeded past the browser warning and then the string \"Hello World\" was displaced in the browser window indicating that the application was up and running in the Kubernetes cluster.\n\nFinally, to double-check our production deployment URL, we headed to the project **Operate > Environments** window, and clicked on the \"Open\" button for it, which immediately opened a browser window with the \"Hello World\" message.\n\n![app-running-on-k8s](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675940/Blog/Content%20Images/app-running-on-k8s.png)\n\n## Try it \n\nWe created, compiled, built, and deployed a simple Quarkus application to a Kubernetes cluster using [GitLab Duo](https://about.gitlab.com/gitlab-duo/). This approach allowed us to be more efficient and productive in all the tasks that we performed and it helped us streamline our DevSecOps processes. We have shown only a small portion of how GitLab Duo's AI-powered capabilities can help you, namely Chat and Root Cause Analysis. There’s so much more you can leverage in GitLab Duo to help you create better software faster and more securely.\n\nWatch this whole use case in action:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/xDpycxz3RPY?si=HHZrFt1O_8XoLATf\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nAll the project assets we used are available [here](https://gitlab.com/gitlab-da/use-cases/ai/ai-applications/quarkusn/quarkus-native).\n\n> [Try GitLab Duo for free for 60 days](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro) and get started on exciting projects like this.",[786,746,703,976,9,701,108],{"slug":6297,"featured":90,"template":683},"use-gitlab-duo-to-build-and-deploy-a-simple-quarkus-native-project","content:en-us:blog:use-gitlab-duo-to-build-and-deploy-a-simple-quarkus-native-project.yml","Use Gitlab Duo To Build And Deploy A Simple Quarkus Native Project","en-us/blog/use-gitlab-duo-to-build-and-deploy-a-simple-quarkus-native-project.yml","en-us/blog/use-gitlab-duo-to-build-and-deploy-a-simple-quarkus-native-project",{"_path":6303,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6304,"content":6310,"config":6315,"_id":6317,"_type":13,"title":6318,"_source":15,"_file":6319,"_stem":6320,"_extension":18},"/en-us/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"title":6305,"description":6306,"ogTitle":6305,"ogDescription":6306,"noIndex":6,"ogImage":6307,"ogUrl":6308,"ogSiteName":670,"ogType":671,"canonicalUrls":6308,"schema":6309},"Use GitLab Duo Workflow to improve application quality assurance","Learn step-by-step how to add unit tests to a Java application using agentic AI (includes a video tutorial).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097617/Blog/Hero%20Images/Blog/Hero%20Images/Workflow%201800x945_2gQoQIbY9NvjLFpXtsxtXy_1750097616649.png","https://about.gitlab.com/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Use GitLab Duo Workflow to improve application quality assurance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-10\",\n      }",{"title":6305,"description":6306,"authors":6311,"heroImage":6307,"date":6312,"body":6313,"category":806,"tags":6314},[803],"2025-04-10","Assuring the quality of your applications via test-driven design, good code coverage, and issue detection is critically important to your customers and your reputation, but it can also be a time-consuming endeavor. [GitLab Duo Workflow](https://about.gitlab.com/gitlab-duo/workflow/), agentic AI built on top of the most comprehensive DevSecOps platform, can help you quickly complete development tasks such as adding unit tests to a Java application. This tutorial demonstrates how by using this sample [Java project](https://gitlab.com/gitlab-da/playground/csaavedra/gdw/prodmgr-gdw).\n\n> GitLab Duo Workflow is currently in private beta. Join the [waitlist](https://about.gitlab.com/gitlab-duo/workflow/) to see what’s possible with AI agents that understand your entire SDLC.\n\n## Opening your project in VS Code\n\n1. Open the Java project in Visual Studio Code (after cloning it to your local machine). Ensure that you’re in a feature branch (not the main or default branch) before you start. If you’re already working on a merge request, it will have its own associated feature branch.\n\n2. (This step is optional.) Navigate to the file that defines the Java class for which you’d like to have GitLab Duo Workflow create unit tests. Inspect it so that you can later confirm that the generated unit tests do cover its class members. This is what you would see:\n\n![File that defines the Java class for which you’d like to have GitLab Duo Workflow create unit tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097627482.png)\n\n**Note:** We are assuming that you already enabled the GitLab Duo Workflow extension in your VS Code. If not, please refer to the [setup documentation](https://docs.gitlab.com/user/duo_workflow/#use-workflow-in-vs-code).\n\n3. Launch GitLab Duo Workflow by opening the VS Code command palette [Ctrl + Shift + P] and entering \"GitLab Duo Workflow\" in it and selecting **GitLab: Show Duo Workflow**. A tab will appear that looks like this:\n\n![Launching GitLab Duo Workflow with VS Code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097627483.png)\n\n4. The next step is to add tests for the default constructor, the verification of the object creation, and the initial state of the properties of the Product class. To accomplish this, enter the following prompt in the text area in GitLab Duo Workflow:\n\n```unset\nCreate unit tests for class defined in the Product.java file and store the unit tests in its own file titled ProductTest.java\n```\n\n![Prompt area in GitLab Duo Workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097627484.png)\n\n5. Click the **Start** button in the GitLab Duo Workflow window. Two new windows will appear: one in the center of the screen and one to the right. The one on the right displays the analysis that GitLab Duo Workflow is performing to come up with a plan that will achieve the goal as specified in your prompt. The plan is displayed in the center window. After the analysis and the plan are finished, you should see an output like this:\n\n![Analysis and plan generated by GitLab Duo Workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097627486.png)\n\n6. Review the analysis and plan and, if you are satisfied with them, click **Approve plan** at the bottom of the window.\n\n7. GitLab Duo Workflow will start executing the approved plan and making modifications to your project accordingly.\n\n8. Once the execution of the plan is finished, you will see a new directory `src/test/java/csaa/jspring/ProductManager` in the project with a new file in it named `ProductTest.java`, which contains all the unit tests for the `Product.java` class.\n\n![New directory in the project iwth a new file name `ProductTest.java`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097627488.png)\n\n9. Navigate to the newly created file `ProductTest.java` and you will see that it has some import statements underlined in red indicating some import errors:\n\n![`ProductTest.java` include imports statement and error indicators in red](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097627489.png)\n\nLet’s have GitLab Duo Workflow fix these for us.\n\n**Note:** We could have also asked GitLab Duo Workflow in our first prompt to update the `pom.xml` file accordingly. But since we didn’t, let’s fix these errors in a new workflow.\n\n## Launching a GitLab Duo Workflow to fix errors in generated code\n\n10. Start a new workflow by clicking on the **New workflow** button at the bottom of the analysis window on the right side of your screen.\n\n![New workflow button](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097627491.png)\n\n11. In the prompt text area, enter the following:\n\n```unset\nThe file ProductTest.java has an error “The import org.junit cannot be resolved”. Please fix it\n```\n\n12. After you approve the proposed plan, GitLab Duo Workflow starts its analysis by reading the current `pom.xml` file. It then edits it and removes the outdated JUnit dependency, and follows that with the addition of the correct dependency and version for JUnit. Lastly, it reads the `ProductTest.java` file to clear all the dependency errors.\n\n![GitLab Duo Workflow carrying out analysis by reading pom.xml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097627492.png)\n\n## Watch the tutorial\n\nThrough the execution of this plan, GitLab Duo Workflow is effectively making updates to the project to achieve what was requested in the prompt, saving time and effort, and increasing productivity so that developers can spend more time innovating and creating value for their organization.\n\nIf you’d like to see what you read above in action, watch the following video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Tuj7TgqY81Q?si=RReuL1pUsLafvAzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Sign up for the [GitLab Duo Workflow private beta waitlist](https://about.gitlab.com/gitlab-duo/workflow/) to see what’s possible with AI agents that understand your entire SDLC.\n\n## Read more about GitLab Duo Workflow and agentic AI\n\n- [GitLab Duo Workflow: Enterprise visibility and control for agentic AI](https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [GitLab Duo Workflow documentation](https://docs.gitlab.com/user/duo_workflow/)\n- [GitLab Duo](https://about.gitlab.com/gitlab-duo/)\n- [Agentic AI: Unlocking developer potential at scale (The Source)](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)\n",[786,478,746,701,9],{"slug":6316,"featured":6,"template":683},"use-gitlab-duo-workflow-to-improve-application-quality-assurance","content:en-us:blog:use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","Use Gitlab Duo Workflow To Improve Application Quality Assurance","en-us/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","en-us/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"_path":6322,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6323,"content":6329,"config":6334,"_id":6336,"_type":13,"title":6337,"_source":15,"_file":6338,"_stem":6339,"_extension":18},"/en-us/blog/value-stream-total-time-chart",{"title":6324,"description":6325,"ogTitle":6324,"ogDescription":6325,"noIndex":6,"ogImage":6326,"ogUrl":6327,"ogSiteName":670,"ogType":671,"canonicalUrls":6327,"schema":6328},"Value stream optimization with GitLab's Total Time Chart","Learn how this new analytics feature provides immediate insights about the time spent in each stage of your workstream.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667913/Blog/Hero%20Images/clocks.jpg","https://about.gitlab.com/blog/value-stream-total-time-chart","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Value stream management: Total Time Chart simplifies top-down optimization flow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2023-06-01\",\n      }",{"title":6330,"description":6325,"authors":6331,"heroImage":6326,"date":2371,"body":6332,"category":1513,"tags":6333},"Value stream management: Total Time Chart simplifies top-down optimization flow",[2014],"\n\nUnderstanding where time is spent during the development lifecycle is a crucial insight for software leaders when optimizing the value delivery to customers. Our new Value Stream Analytics Total Time Chart is a visualization that helps managers uncover how long it actually takes to complete the development process from idea to production. Managers also can learn how much time teams spend in each stage of the workflow.\n \n![The VSA Total Time Chart displays the average time to complete each value stream stage.](https://about.gitlab.com/images/blogimages/2023-05-07-vsa-overview.gif){: .shadow}\nValue Stream Analytics Total Time Chart\n{: .note.text-center}\n\nValue Stream Analytics is available out of the box in the GitLab platform. It surfaces the process and value delivery metrics through the unified data model that stores all the records around development efforts. Value Stream Analytics uses a backend process to collect and aggregate stage-level data into [three core objects](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#how-value-stream-analytics-works):\n\n- Value streams - container objects with stage list \n- Value stream stage - an event pair of start and end events\n- Value stream stage events - the smallest building blocks of the value stream. For example, from Issue created to Issue first added to board. See the [list of available stage events](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events).\n\n> [Register for the GitLab 16 webinar](/sixteen/), where we will unveil the latest innovations in our AI-powered DevSecOps platform.\n\nWe added in the new chart the stages breakdown as a stacked area chart to make it easier to understand how each stage contributes to the total time, and how that changes over time. Each area in the chart represents a stage. By comparing the heights of each area, you can get an idea about how each stage contributes to the total time of the value stream. We also added a tool tip with the stages breakdown sorted top to bottom, to help you understand the stages in their correct order.\n\nThe new chart is available in the Value Stream Analytics Overview page (on the left sidebar, select **Analytics > Value stream**). This page includes four sections:\n  1.  Data filter text box - on the top of the Overview page you can use the [Data filters](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#data-filters) to view data that matches specific criteria or date range. \n  2. Stage navigation bar - below the filter text box you can use the the stage navigation bar to investigate what happened in the specific stage and to identify the items (issues/MRs) that are slowing down the stage time.\n  3. Key metrics tiles - the summary of the stream performance is displayed, above the chart in the [Key metrics tiles](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#key-metrics). \n  4. Overview charts - the newly added Total Time Chart and the [Task by type](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#view-tasks-by-type) chart. \n\nBut that's not all. The Total Time Chart also simplifies the top-down optimization flow, starting from the Value Streams Dashboard organization-level view to a drill-down into the performance of each project:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/EA9Sbks27g4\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\nFrom the Value Stream Analytics overview page, you can drill down from Key metrics tiles into other GitLab analytics pages for deeper investigations. You can also go up to the Value Streams Dashboard, or investigate the [DORA metrics](/solutions/value-stream-management/dora/) that are also available in the new dashboard.\n\nIt's important to note that the chart data is limited to items completed within the selected date range. Also, there could be points in time with no [\"stage event\"](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events) actions. In these cases, the chart will display a dashed line to represent the missing data. These gaps can add contextual information about the workstream, and usually do not represent interruptions in the data. When there is \"no data\" for a specific stage, the stage line will be flat.\n\nTo learn more check out the [Value Stream Analytics documentation](https://docs.gitlab.com/ee/user/group/value_stream_analytics/).\n\nWith the Value Stream Analytics Total Time Chart, you get immediate insights about the time spent in each stage over time to determine if progress is being made. Try it out today and see the difference it can make in your workstream!\n",[1164,851,9,2018,894],{"slug":6335,"featured":6,"template":683},"value-stream-total-time-chart","content:en-us:blog:value-stream-total-time-chart.yml","Value Stream Total Time Chart","en-us/blog/value-stream-total-time-chart.yml","en-us/blog/value-stream-total-time-chart",{"_path":6341,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6342,"content":6348,"config":6354,"_id":6356,"_type":13,"title":6357,"_source":15,"_file":6358,"_stem":6359,"_extension":18},"/en-us/blog/version-12-year-in-review",{"title":6343,"description":6344,"ogTitle":6343,"ogDescription":6344,"noIndex":6,"ogImage":6345,"ogUrl":6346,"ogSiteName":670,"ogType":671,"canonicalUrls":6346,"schema":6347},"GitLab Version 12 Year In Review: Releases 12.0 to 12.10","Product highlights from a pivotal year","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680891/Blog/Hero%20Images/cloud-adoption-roadmap.jpg","https://about.gitlab.com/blog/version-12-year-in-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Version 12 Year In Review: Releases 12.0 to 12.10\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brian Glanz\"}],\n        \"datePublished\": \"2020-05-21\",\n      }",{"title":6343,"description":6344,"authors":6349,"heroImage":6345,"date":6351,"body":6352,"category":678,"tags":6353},[6350],"Brian Glanz","2020-05-21","\n\nAt GitLab, we understand that the strength of your business depends on moving fast. And what makes us strong in good times, makes us resilient in challenging times.\n\nStrength and resilience come from speed, yes, but also agility, operational efficiency, security, and above all, reliability. We've released a new version on the 22nd of every month for [now more than 100 consecutive months](/releases/).\n\nAs we’ve grown, those monthly releases now include dozens of significant features and improvements: 719 new features and improvements total in versions 12.0–12.10, as documented in our [release blog posts](/releases/categories/releases/).\n\nWe’ll cover some of the highlights and trends here in this Version 12 Year in Review. Watch it in the video below, or read on for more detail and all the links.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"1141\" height=\"642\" src=\"https://www.youtube.com/embed/IXRuepeH3xg\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*Here is the [Version 12 Year in Review slide deck](https://docs.google.com/presentation/d/1ht1da_WIrkG_4Cx5C89D4C7zxV80MIExUVwCyZD10aw/edit?usp=sharing) shown in the video.*\n\nGitLab is not just another startup. Over the past year, the awesome GitLab community [made almost 200 contributions to our open source software in every monthly release](https://gitlab.biterg.io/goto/937475d38035f496df3501c9b30af5ef). Community contributions to versions 12.0–12.10 totaled an incredible 2,158 🙌, and contributions per month/per version have grown steadily over versions 10, 11, and 12:\n\n![GitLab Monthly Community Contributions per Major Version](https://about.gitlab.com/images/blogimages/GitLabCommunityContributionsMonthlyPerMajorVersion.png){: .shadow}\n\nOur company and our community are truly working together to make [DevOps](/topics/devops/) a reality for teams of all sizes.\n\nLooking back, Version 12 has been about expanding our focus, first by treating developers, security, and operations alike as first-class citizens in DevOps. [We called 12.0 our DevSecOps release](/releases/2019/06/22/gitlab-12-0-released/) and we’ve delivered on that vision in the year since.\n\nGitLab has also grown to help more types of users contribute, such as by building in [Requirements Management](/releases/2020/04/22/gitlab-12-10-released/#create-and-view-requirements-in-gitlab) and [Design Management](/releases/2019/08/22/gitlab-12-2-released/#annotations-for-designs). As you have more people collaborating in a single application, features like our new [Compliance Dashboard](/blog/make-tracking-agreements-simple-compliance-dashboard/) are more useful, in that case making compliance easier for everyone.\n\n## Dev\n\n![Dev](https://about.gitlab.com/images/blogimages/GitLab-Dev.png){: .small.left.wrap-text}\n\nFor developers, it’s all about delivering and shipping faster while meeting business demands. Today, we provide granular analytics on merge requests, with [Productivity Analytics](/releases/2019/09/22/gitlab-12-3-released/#productivity-analytics) and [Code Review Analytics](/blog/troubleshoot-delays-with-code-review-analytics/), in addition to full, downloadable [Code Quality Reports](/releases/2020/03/22/gitlab-12-9-released/#full-code-quality-report) for even more visibility.\n\nBuilt-in package management now includes a [GitLab Conan repository](/releases/2019/12/22/gitlab-12-6-released/#manage-cc-packages-via-conan-within-gitlabs-package-registry) for C and C++ developers, and a [NuGet repository](/releases/2020/02/22/gitlab-12-8-released/#build-publish-and-share-packages-to-the-gitlab-nuget-net-repository) for Windows developers.\n\nAutomation is fundamental for DevOps teams, and with [Directed Acyclic Graphs](/releases/2019/08/22/gitlab-12-2-released/#directed-acyclic-graphs-dag-for-gitlab-pipelines) and [Parent-Child Pipelines](/releases/2020/01/22/gitlab-12-7-released/#parent-child-pipelines), complex pipelines are now faster and more flexible.\n\n## Sec\n\n![Sec](https://about.gitlab.com/images/blogimages/GitLab-Sec.png){: .small.right.wrap-text}\n\n[DevSecOps](/solutions/security-compliance/) is not only about shifting left with testing or security — it’s also increasing visibility downstream or “shifting right.” Security teams need to manage and mitigate business risk. To do that, they need visibility into development and what vulnerabilities are being created or discovered.\n\nYou can now easily access and export a project’s [Dependency List](/releases/2019/06/22/gitlab-12-0-released/#project-dependency-list) or “Bill of Materials.” Our [scorecard on Security Dashboards](/releases/2019/12/22/gitlab-12-6-released/#quickly-understand-your-at-risk-projects-with-project-security-grades) lets you know immediately which projects are most at risk.\n\nWe also have more efficient [vulnerability management](/releases/2020/03/22/gitlab-12-9-released/#select-and-dismiss-multiple-vulnerabilities) on security dashboards and [autoremediation of vulnerabilities found in Container Scanning](/releases/2020/03/22/gitlab-12-9-released/#suggested-solution-for-container-scanning). Our new [Container Network Security](/releases/2020/02/22/gitlab-12-8-released/#network-policies-for-container-network-security) helps prevent lateral attacks.\n\n## Ops\n\n![Ops](https://about.gitlab.com/images/blogimages/GitLab-Ops.png){: .small.left.wrap-text}\n\nBut containers and applications don’t really run themselves. Application teams everywhere need to plan and architect for stability and efficiency.\n\nEnvironments become hard to wrangle when you have more than just a few, and our [Environments Dashboard](/releases/2019/11/22/gitlab-12-5-released/#environments-dashboard) lets you see what’s going on across projects. For teams with a high volume of merges, [Merge Trains](/releases/2019/07/22/gitlab-12-1-released/#parallel-execution-strategy-for-merge-trains) help mitigate potential conflicts in production pipelines.\n\nManaging deploy tokens is now more efficient, as we introduced both [group-level deploy tokens](/releases/2020/03/22/gitlab-12-9-released/#group-deploy-tokens) and an API to administer them. You can now leverage [HashiCorp Vault](/releases/2020/03/22/gitlab-12-9-released/#secure-your-applications-with-secrets-management-and-vulnerability-remediation) to securely manage keys, tokens, and other secrets with Vault as a GitLab CI managed app.\n\nWe are strong believers in automating repetitive tasks. Creating a new cluster should be simple, and our [EKS integration](/releases/2019/11/22/gitlab-12-5-released/#easily-create-and-deploy-to-an-eks-cluster) does just that. Finally, our new [Log Explorer](/releases/2020/02/22/gitlab-12-8-released/#explore-aggregated-logs) aggregates Kubernetes logs across pods and services, making them searchable and much more useful.\n\n## GitLab is for Everyone\n\nWith Version 12, we can see GitLab is not only for developers, and it’s not even only for DevOps. Expect more progress in Version 13 and beyond, as we continue on [our mission to change all creative work from read-only to read-write](/company/#about-us).\n\nGitLab is for everyone, and everyone can contribute. [Join us, at GitLab.com](https://about.gitlab.com/).\n\nCover image by [Matt Howard](https://unsplash.com/@thematthoward?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/journey?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[9,266,680],{"slug":6355,"featured":6,"template":683},"version-12-year-in-review","content:en-us:blog:version-12-year-in-review.yml","Version 12 Year In Review","en-us/blog/version-12-year-in-review.yml","en-us/blog/version-12-year-in-review",{"_path":6361,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6362,"content":6367,"config":6372,"_id":6374,"_type":13,"title":6375,"_source":15,"_file":6376,"_stem":6377,"_extension":18},"/en-us/blog/visualizing-incident-management-metrics",{"title":6363,"description":6364,"ogTitle":6363,"ogDescription":6364,"noIndex":6,"ogImage":6326,"ogUrl":6365,"ogSiteName":670,"ogType":671,"canonicalUrls":6365,"schema":6366},"Visual guide to incident metrics","Learn what incident metrics are and how they contribute to better performance and response times.","https://about.gitlab.com/blog/visualizing-incident-management-metrics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Visual guide to incident metrics\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2023-01-09\",\n      }",{"title":6363,"description":6364,"authors":6368,"heroImage":6326,"date":6369,"body":6370,"category":1513,"tags":6371},[2114],"2023-01-09","\n\nIncident metrics are a set of standard, quantifiable measurements used to track the incident response process. Accurately tracking these metrics will help DevSecOps teams understand how they are performing and whether responses to unplanned outages are getting better or worse. Decreasing the time to detect, respond, mitigate, and recover from an incident decreases the impact of an incident on customers as well as the cost of the incident to the business overall. \n\nHow are these metrics captured and recorded? Let's backtrack a bit and define five key timestamps to capture during an incident that will enable teams to measure the relevant incident metrics.\n\n1. First product impact (`Start time`): When a service starts degrading or metrics begin deviating from the norm.\n2. Time to detection (`Impact detected`): When the operator becomes aware of the problem.\n3. Time to respond (`Response initiated`): When the operator starts to address the problem. \n4. Time to mitigate (`Impact mitigated`): When there is no longer severe product impact. The system may still be degraded in some way.\n5. Time to recovery (`End time`): When the system has fully recovered and is operating normally. Note: Sometimes recovery and mitigation are the same, but sometimes they are different. Time to recovery is the same as the DORA metric [time to restore service](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html#time-to-restore-service): time an incident was open in a production environment over the given time period.\n\nIt is important to create a single source of truth for what actually happened during a given incident, and GitLab enables users to do that easily by creating incident timelines. Throughout an incident, there are many conversations, meetings, and investigations to determine what's going on and how to recover. However, only some key pieces of what happened during the incident need to be identified to build an incident timeline, and these timeline items are the building blocks of the important incident metrics.  \n\nLet's walk through an example of how that could work:\n\n- When an alert is triggered, Sally, the engineer on call, gets paged.\n- Sally is in the middle of breakfast and doesn't hear the first page.\n- When she gets paged again, she picks up her phone (`impact detected`) and starts to investigate.\n- After taking a closer look, it looks like something isn't working as expected and she declares an incident.\n- After reviewing the metrics that triggered the alert, she notices this has been happening for 8 minutes.\n- Sally determines that the true `start time` of the incident was 8 minutes before the first alert.\n\nSo far, two important timeline events have happened. By applying the `start time` and `impact detected` tags to your incident timeline, you can measure the time to detection, which is the difference between these two timestamps.\n\n![time_to_detection](https://about.gitlab.com/images/blogimages/incident-mgmt/time_to_detection.png)\n\nAfter Sally has had a chance to start investigating the alert, she reaches out to team members that can help, sets up a video conference call, and starts to determine the root cause. The `response is initiated`. \n\nThe response team is seeing multiple reports from customers and internal users that traffic is absent. After taking a closer look at the alert and recent changes, the team is able to determine that this incident originates from a recent deployment. Sally coordinates with the Release Manager to roll back the deployment. Once the rollback is complete, the incident has been mitigated. So far we've captured two key metrics, time to detect and time to mitigate.\n\n![time_to_mitigation](https://about.gitlab.com/images/blogimages/incident-mgmt/time_to_mitigation.png)\n\nOnce the changes from the bad deployment have been reverted, Sally continues to monitor for any additional alerts, irregular logs, or reports that traffic is absent. Things continue to look like they are working as expected, marking the `end time` of the incident and declaring the incident _resolved_. (In this example, the time to mitigate is the same as the time to recover since the rolled back deployment restored services.) Sally starts working on creating/determining corrective actions and investigating the total impact that users experienced during the incident. Once these closing tasks are complete, the incident is closed.\n\n![time_to_recovery](https://about.gitlab.com/images/blogimages/incident-mgmt/time_to_recovery.png)\n\nAt GitLab we've built [incident timelines](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html#view-the-timeline) on the [incident](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) issue type as a first step towards tracking important incident metrics.  We are currently building an MVC for [incident tags](https://gitlab.com/groups/gitlab-org/-/epics/8741) so incident response teams can capture relevant incident timestamps during an incident and add them to the incident timeline.  To learn more about how incident timelines can help your team during an incident, check out [How to leverage GitLab incident timelines](https://about.gitlab.com/blog/gitlab-incident-timelines/).\n\nSpecial thanks to GitLab's talented Product Designer [Amelia Bauerly](https://gitlab.com/ameliabauerly) who illustrated the examples in this blog post.\n",[701,829,9],{"slug":6373,"featured":6,"template":683},"visualizing-incident-management-metrics","content:en-us:blog:visualizing-incident-management-metrics.yml","Visualizing Incident Management Metrics","en-us/blog/visualizing-incident-management-metrics.yml","en-us/blog/visualizing-incident-management-metrics",{"_path":6379,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6380,"content":6386,"config":6391,"_id":6393,"_type":13,"title":6394,"_source":15,"_file":6395,"_stem":6396,"_extension":18},"/en-us/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":6381,"description":6382,"ogTitle":6381,"ogDescription":6382,"noIndex":6,"ogImage":6383,"ogUrl":6384,"ogSiteName":670,"ogType":671,"canonicalUrls":6384,"schema":6385},"What are the benefits of a microservices architecture?","On the fence about what a microservices architecture can bring to your team? Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What are the benefits of a microservices architecture?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":6381,"description":6382,"authors":6387,"heroImage":6383,"date":6388,"body":6389,"category":1513,"tags":6390},[3155],"2022-09-29","\n[Microservices architecture](/topics/microservices/) is a framework where an application is separated into smaller services and each of those services typically runs a unique process and manages its own database. There are many pros and cons to microservices. Let's explore them.\n\n## Advantages of microservices architecture\n\n### Scalability improvements\n\nSince each microservice runs independently, it is easier to add, remove, update or scale each cloud microservice. Developers can perform these tasks without disrupting any other microservice in the system. Companies can scale each microservice as needed. For instance, if a particular microservice experiences increased demand because of seasonal buying periods, more resources can be efficiently devoted to it. If demand drops as the season changes, the microservice can be scaled back, allowing resources or computing power to be used in other areas.\n\n### Improved fault isolation\n\nUnder a monolithic architecture structure, when developers experience a failure in one element of the architecture, it will collapse all architecture components. With a microservices architecture, if one service fails, it’s much less likely that other parts of the application will fail because each microservice runs independently. However, businesses need to be careful, because large volumes of traffic can still be overwhelming in some cases.\n\nThe benefit of a microservice architecture is that developers can deploy features that prevent cascading failures. A variety of tools are also available, from GitLab and others, to build fault-tolerant microservices that help improve the resilience of the infrastructure.\n\n### Program language and technology agnostic\n\nA microservice application can be programmed in _any_ language, so dev teams can choose the best language for the job. The fact that microservices architectures are language agnostic also allows the developers to use their existing skill sets to maximum advantage – no need to learn a new programming language just get the work done.\nUsing cloud-based microservices gives developers another advantage, as they can access an application from any internet-connected device, regardless of its platform.\n\n### Simpler to deploy\n\nA microservices architecture lets teams deploy independent applications without affecting other services in the architecture. This feature, one of the pros of microservices, will enable developers to add new modules without redesigning the system's complete structure. Businesses can efficiently add new features as needed under a microservices architecture.\n\n### Reusability across different areas of business\n\nSome microservice applications may be shareable across a business. If a site has several different areas, each with a login or payment option, the same microservice application can be used in each instance.\n\n### Faster time-to-market\n\nDevelopers can plug this new “microsurgery” into the architecture without fear of conflicts with other code or of creating service outages that ripple across the website. Development teams working on different microservices don't have to wait for each other to finish. Companies can develop and deploy new features quickly and upgrade older components as new technologies allow them to evolve.\n\n### Ability to experiment\n\nDeciding to go forward with experimentation is much easier with microservices architecture.\n\nIt’s simple to roll out new features because each service is independent of the others. If customers don't like it, or the business benefits aren’t clear, it's much easier to roll it back without affecting the rest of the operation.\n\nIf a  new feature is a customer request, a microservices architecture means they’ll get to experience it in weeks, rather than months or years.\n\n### Improved data security\n\nIf the components of the computer systems architecture break down into smaller pieces, sensitive data is protected from intrusions from another area. While there are connections between all microservices, developers can use secure APIs to connect the services. Secure APIs safeguard data by ensuring it is only available to specifically authorized users, applications and servers. If a business requires handling sensitive data such as health or financial information, it's easier to achieve compliance under data security standards such as healthcare's [HIPAA](https://www.hhs.gov/hipaa/index.html) or the European [GDPR](https://gdpr-info.eu).\n\n### Outsourcing flexibility\n\nIt may be necessary for a business to outsource certain functions to third-party partners. Many companies are concerned about protecting intellectual property with a monolithic architecture format. However, a microservices architecture allows businesses to segment areas just for  partners that won’t otherwise disclose core services.\n\n### Team optimization\n\nWhen considering the size of teams you assign to each microservice, consider the two-pizza rule. First articulated by Amazon, which pioneered microservices, the idea is to keep development teams small enough to feed them with two pizzas. Experts explain that this guideline improves work efficiency, allows businesses to achieve goals faster, makes teams easier to manage, creates greater focus among the group and results in higher quality products.\n\n### Attractive for engineers\n\nEngineers find microservices architecture enticing, and companies have a [better chance of finding top-flight talent](/blog/have-devops-jobs-to-fill-try-these-3-strategies-to-hire-and-retain/) to work on microservices application development. Microservices rely on the latest engineering practices and developer tools. This provides an important advantage for businesses hoping to attract specialists.\n\n## Disadvantages of microservices\n\nWhile there are a solid number of advantages for any business, there are also a few disadvantages of microservices to consider before adoption.\n\n### Upfront costs are higher with microservices\n\nWhile cloud microservices are a pro, such as saving money over the long run, there are cons, such as the costs associated with their initial deployment. A business needs to have sufficient hosting infrastructure with security and maintenance support. Even more important, it will need skilled teams to manage all services.\n\n### Interface control is crucial\n\nSince each microservice has its own API, any application using that service will be affected if you change the API, and that change is not backward compatible. Any large operation using a microservices architecture will have hundreds, even thousands, of APIs so controlling those interfaces becomes critical to the business's operation, which can be a disadvantage to microservices architecture.\n\n### A different kind of complexity\n\nDebugging can be more challenging with a microservices architecture. Each microservice will have its own set of logs. This provides a minor headache when tracing the source of a problem in the code.\n\n### Integration testing\n\nUnit testing is more manageable with microservices architecture. Integration testing is not. Since the architecture distributes each microservice, developers cannot test the entire system from their machines.\n\n### Service-oriented architecture vs. microservices\n\nIf you work in cloud computing, you're probably aware of the [service-oriented architecture (SOA)](https://www.techtarget.com/searchapparchitecture/definition/service-oriented-architecture-SOA) versus microservices debate. In many ways, the two architectures are similar as they both involve cloud computing for agile development. Both break large monolithic components into smaller units that are easier to work with.\n\nThe biggest difference is that SOA is an enterprise-wide approach to developing software components. Microservices, meanwhile, build standalone applications that perform a specific function and this cloud-native approach to development and deployment makes them more scalable, agile and resistant. \n\nSo, in essence, the difference between the two comes down to scope. SOA is an enterprise-wide approach, while a microservices architecture has an application scope.\n\nRead on to learn [how to get started with a microservices architecture](/blog/get-started-with-microservices-architecture/).\n",[851,851,9],{"slug":6392,"featured":90,"template":683},"what-are-the-benefits-of-a-microservices-architecture","content:en-us:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","en-us/blog/what-are-the-benefits-of-a-microservices-architecture.yml","en-us/blog/what-are-the-benefits-of-a-microservices-architecture",{"_path":6398,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6399,"content":6404,"config":6409,"_id":6411,"_type":13,"title":6412,"_source":15,"_file":6413,"_stem":6414,"_extension":18},"/en-us/blog/what-the-ml-ai",{"title":6400,"description":6401,"ogTitle":6400,"ogDescription":6401,"noIndex":6,"ogImage":906,"ogUrl":6402,"ogSiteName":670,"ogType":671,"canonicalUrls":6402,"schema":6403},"What the ML is up with DevSecOps and AI?","AI will revolutionize DevSecOps platforms. Learn about where GitLab is today and what we're working on.","https://about.gitlab.com/blog/what-the-ml-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What the ML is up with DevSecOps and AI?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n        \"datePublished\": \"2023-03-16\",\n      }",{"title":6400,"description":6401,"authors":6405,"heroImage":906,"date":6406,"body":6407,"category":806,"tags":6408},[2333],"2023-03-16","\n\nGitLab believes at our core that [AI will revolutionize the power of DevSecOps platforms](//topics/devops/the-role-of-ai-in-devops/) to bring to life a software development experience that feels straight out of science fiction. GitLab users already benefit from a step-function increase in productivity when they adopt our platform: streamlined collaboration, operational efficiencies, and massive acceleration in time to delivery. But by introducing machine learning (ML) and other artificial intelligence (AI) capabilities into the fabric of The DevSecOps Platform feature set, we aim to take those gains to a whole new level. \n\nGitLab occupies a unique seat in relation to defining how AI and ML will impact DevSecOps into the future. As the creators of the DevSecOps platform category, we are the founders behind a successful philosophy for bringing DevSecOps principles into practice. By virtue of curating the entire software development lifecycle, our platform also has an unrivaled level of visibility into the code, configuration, testing, deployment, and operation of the applications it produces. It is in the rich data set underpinning that curated experience where unbounded opportunity lurks. These opportunities include the ability to deliver:\n\n- **Faster deployments**: By automating various aspects of the software development lifecycle, including testing and deployment, [AI/ML can help DevSecOps](/blog/why-ai-in-devops-is-here-to-stay/) teams deliver software faster and more reliably.\n- **Improved security**: AI/ML can help identify and mitigate potential security threats by analyzing data patterns and behavior. It can also automate security testing and analysis, leading to faster and more accurate detection and remediation of vulnerabilities.\n- **Enhanced quality assurance**: AI/ML can help automate quality assurance processes by analyzing data patterns and identifying potential issues in code, leading to faster testing, fewer bugs, and higher quality software.\n- **Intelligent monitoring and alerting**: AI/ML can help monitor systems in real time, analyzing data from logs, alerts, and other sources to detect anomalous behavior and potential security threats.\n- **Predictive analytics**: AI/ML can help DevSecOps teams predict potential issues, identify patterns, and make data-driven decisions to improve their software before issues become critical.\n\nGitLab will focus on incorporating AI/ML capabilities that leverage our unique strengths to deliver unique value. In particular, we plan to:\n\n- incorporate generative AI into GitLab to massively simplify, accelerate, or entirely obviate parts of the software development process,\n- use the unique data set at our disposal to make novel connections and surface insights to users about their teams, their processes, and the software they are building - insights that are otherwise lost to the voids of piecemeal DevOps toolchains.\n- build the MLOps and DataOps plumbing that will enable organizations to build and deploy AI/ML workloads using GitLab.\n\n## AI/ML in GitLab today\n\nHere are some of the ways we are using AI/ML in GitLab today.\n\n### AI/ML for automation\n\nFirst, we are applying ML and AI to automate mundane tasks and reduce the cognitive load for our customers. We are currently developing [AI Assisted capabilities](/direction/modelops/ai_assisted/) to improve productivity and efficiency for everyone in the software delivery workflow. Here are some AI Assisted capabilities available in GitLab today:\n\n![Suggested Review Screenshot](https://about.gitlab.com/images/15_4/create-code-review-suggested-reviewers.png){: .shadow.col-sm-4.right.wrap-text}\n\n- **Suggested Reviewers**, [released last September](/releases/2022/09/22/gitlab-15-4-released/#suggested-reviewers-open-beta), automatically suggests the best available reviewer for a merge request. This capability removes the guesswork by ensuring the right reviewer with the right contextual knowledge is reviewing code changes so that developers can deploy software more efficiently. Early users have told us that Suggested Reviewers minimizes delays and leads to better reviews. They now have more confidence in the code they deploy. The tool has generated tens of thousands of suggested reviewers to more efficiently and securely review code on our platform. You can learn more about the feature and how to enable it in [our Suggested Reviewers documentation](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers).\n\n- **GitLab Code Suggestions**, [released in closed beta this past February](/releases/2023/02/22/gitlab-15-9-released/#code-suggestions-available-in-closed-beta), aims to increase developer speed and productivity by providing code suggestions in GitLab’s VS Code IDE plugin. We’re actively building this into GitLab’s new Web IDE and Remote Development solution as well. Ultimate customers interested in joining the beta of Code Suggestions [can fill out this form](https://forms.gle/cbjqJhLGV1i7t6Sd8). Additional information about Code Suggestions can be found on [our direction page](/direction/modelops/ai_assisted/code_suggestions/). \n\n![Animated gif image of code suggestions](https://about.gitlab.com/images/15_9/DemoFastApi.gif){: .shadow}\n\n### Protecting customer source code\n\nWe’ve heard from many of our enterprise DevSecOps customers that their organizations care deeply about the privacy of their source code. They understandably want control over who processes their data and if their code is used to train code generation AI models. That’s why we’ve built our code suggestions feature to work natively within GitLab. Customer source code does not leave the GitLab instance and it is not used to retrain generic multi-customer code generation models.\n\n## The road ahead for GitLab and AI\n\nWe plan to add many AI capabilities throughout our DevSecOps platform, including: \n\n- automating mundane tasks across the software development lifecycle with [Workflow Automation](/direction/modelops/ai_assisted/workflow_automation/) including assigning, labeling, and summarizing. \n- reducing the risk due to insecure coding practices by automatically detecting and help remediating code quality and security vulnerabilities with [Intelligent Code Security](/direction/modelops/ai_assisted/intelligent_code_security/). \n- augmenting developers with generative [Code Suggestions](/direction/modelops/ai_assisted/code_suggestions/) while writing, reviewing, and fixing code.\n\nWe also want to make it easier for customers to build and deploy amazing AI/ML-backed applications to their customers faster. We are working to integrate [ModelOps](/direction/modelops/) features into the GitLab DevSecOps Platform to better support data science workloads and extend DevSecOps workflows to AI and ML workloads. This includes: \n\n- enabling data science teams to work seamlessly within the Gitlab platform with [better support for python notebooks](https://docs.gitlab.com/ee/user/project/repository/jupyter_notebooks/) and [GPU runners](https://docs.gitlab.com/runner/configuration/gpus.html).\n- improving handoffs between data science teams and DevSecOps teams with a native [GitLab Model Registry](https://gitlab.com/groups/gitlab-org/-/epics/9423).\n\n## Follow along\n\nThis blog is the first in [an ongoing series](/blog/ai-ml-in-devsecops-series/) about GitLab’s journey to [build and integrate ML/AI into our DevSecOps platform. Throughout the series, we’ll feature blogs from our product, engineering, and UX teams that will showcase how we’re infusing AI/ML into GitLab. \n\nWe believe AI is going to dramatically change the way teams work and the way organizations develop, secure, and operate software. We’re using our core value of iteration and our experience building the most comprehensive DevSecOps platform to bring the power of AI/ML to bear on the software development lifecycle. \n\nWant to continue reading about AI? Check out the next blog in this series:[How AI-assisted code suggestions will advance DevSecOps](https://about.gitlab.com/blog/ai-assisted-code-suggestions/)!\n\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[786,9],{"slug":6410,"featured":6,"template":683},"what-the-ml-ai","content:en-us:blog:what-the-ml-ai.yml","What The Ml Ai","en-us/blog/what-the-ml-ai.yml","en-us/blog/what-the-ml-ai",{"_path":6416,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6417,"content":6423,"config":6428,"_id":6430,"_type":13,"title":6431,"_source":15,"_file":6432,"_stem":6433,"_extension":18},"/en-us/blog/whats-next-for-devsecops",{"title":6418,"description":6419,"ogTitle":6418,"ogDescription":6419,"noIndex":6,"ogImage":6420,"ogUrl":6421,"ogSiteName":670,"ogType":671,"canonicalUrls":6421,"schema":6422},"GitLab’s 2023 predictions: What’s next for DevSecOps?","Check out insights on securing the supply chain, new uses for AI/ML, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663820/Blog/Hero%20Images/prediction.jpg","https://about.gitlab.com/blog/whats-next-for-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab’s 2023 predictions: What’s next for DevSecOps?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2023-01-26\",\n      }",{"title":6418,"description":6419,"authors":6424,"heroImage":6420,"date":6425,"body":6426,"category":1513,"tags":6427},[4973],"2023-01-26","\nIn 2023, organizations will focus their time and resources on the continued shift left of security, completing the evolution from DevOps to [DevSecOps](/topics/devsecops/). GitLab Chief Marketing and Strategy Officer [Ashley Kramer](https://gitlab.com/akramer) says that every company will need to have security tightly integrated into DevOps to combat the increased threats throughout the software development lifecycle. In addition, DevSecOps teams will have to continue to focus on supply chain security, make optimal use of artificial intelligence and machine learning, and expand their use of value stream analytics. GitLab leaders from across disciplines share these predictions and more about how the industry will change this year.\n\n## Prediction 1: Protecting the supply chain will be the top priority\n\nSecurity will continue to be an organization-wide responsibility, shifting further left and spanning from [the IDE](/blog/get-ready-for-new-gitlab-web-ide/) to applications running in production, according to  [David DeSanto](https://gitlab.com/david), Chief Product Officer.\n\nIn our [2022 Global DevSecOps survey](https://about.gitlab.com/developer-survey/previous/2022/), 57% of sec team members said their orgs have either shifted security left or are planning to this year. Half of security professionals report that developers are failing to identify security issues – to the tune of 75% of vulnerabilities.\n\nThe shift left will be driven in part by the need for [tighter security for software supply chains](/blog/the-ultimate-guide-to-software-supply-chain-security/). “As remote development becomes more and more commonplace, software supply chain security will play a more expansive role across the software development lifecycle,” DeSanto says.\n\n[Francis Ofungwu](https://gitlab.com/fofungwu), Global Field CISO, predicts this supply chain security evolution will happen in three key ways:\n\n- The engineering frontlines will take on more ownership of managing threats in their day-to-day operations. In order to accomplish this, developers will need real-time context on vulnerabilities and remediation strategies in each phase of the software development lifecycle (SDLC), consequently reducing the likelihood of painful incidents in production environments.\n\n- Security and compliance teams will invest in transcribing their software assurance expectations into policy-as-code to reduce the manual and time-consuming security review processes that reduce development velocity.\n\n- As a result of headline-grabbing incidents highlighting enterprise risks in modern software development, organizations will build audit programs to better assess and report SDLC risks. This will require organizations to design how to deliver artifacts that prove the immutability of the controls deployed across all aspects of their development toolchain. \n\nOrganizations should also expect that “what have been best practices for supply chain security for many years, will now become regulatory requirements,” says [Corey Oas](https://gitlab.com/corey-oas), Manager, Security Compliance (Dedicated Markets). He points to [artifact attestation and software bill of materials (SBOM) generation](/blog/the-ultimate-guide-to-sboms/) as examples of best practices that will soon become federal government or industry mandates. “Both of these are integral to developer workflows.” \n\n[Sam White](https://gitlab.com/sam.white), Group Manager, Product - Govern, doubles down on the SBOM and artifact attestation prediction, saying both SBOMs and attestations will need ongoing attention from DevSecOps teams. “Expect to see a shift from looking at these as one-time events to them becoming part of a continuous evaluation process,” he says, adding that organizations will need deeper visibility into software dependencies (e.g. open source packages) and more centralization of software build information.\n\nAnother element of software supply chain security is [zero trust](/blog/why-devops-and-zero-trust-go-together/). “Organizations have considered zero trust strategies for a while, and it will be an implementation focus for them going forward,” predicts [Joel Krooswyk](https://gitlab.com/jkrooswyk), GitLab Federal CTO. “One reason for this movement, at least among federal agencies and their suppliers, is the recent release of the Department of Defense zero trust architecture strategy and roadmap and the inclusion of zero trust principles in several National Institute of Standards and Technology publications such as [800-207](https://csrc.nist.gov/publications/detail/sp/800-207/final).”\n\n> Get more public sector predictions with our webcast [“2022 Lookback & 2023 Predictions in Cybersecurity & Zero Trust with GitLab”](https://page.gitlab.com/2022_devsecopsusecase_Lookback_Predictions_PubSec_RegistrationPage.html)\n\n## Prediction 2: Security will burrow deep into DevOps education\n\nTo mirror the transformation of DevOps to DevSecOps, [DevOps training and education](/blog/5-ways-to-bring-devops-to-your-campus/) will include security as a key part of the curricula, White says. “Organizations will have to provide access to the training that developers need to get a baseline security knowledge, including why certain vulnerabilities are important and should be addressed right away,” he says.\n\n[Pj Metz](https://gitlab.com/PjMetz), Education Evangelist, believes 2023 will be the year that “Shift Left principles will show up in university classrooms.”\n\n“Already, the GitLab for Education team has seen more and more requests for information on DevSecOps, and not just in computer science and programming. Information systems students are looking to learn more about DevSecOps as well,” he says. ”Integrating security education directly into DevOps curricula will ensure that future professionals will be prepared for all aspects of DevSecOps.”\n\nAnd he encourages DevOps students to [ask for security to be added into their education](https://about.gitlab.com/the-source/security/the-future-of-devops-education-needs-to-include-security/) so they will be properly prepared for the workforce. \n\n## Prediction 3: AI/ML will be used throughout the SDLC\n\n“AI will become essential for productivity,” Kramer says. “For example, DevOps teams will integrate AI/ML to automate repetitive and difficult tasks. Ideally, this would ease the burden on developers by removing their cognitive load, decreasing the amount of context-switching they have to do, and enabling them to stay in the flow of development.\"\n\nAccording to our 2022 Global DevSecOps survey, 62% of respondents practice ModelOps, while 51% use AI/ML to check code.\n\n“Combining digital transformation with business analytics and AI - real transformations are possible,” says [Christina Hupy](https://gitlab.com/c_hupy), Sr. Manager, Community Programs. “As more of their data is input, businesses can draw actual insights and use AI to continuously improve their systems.”\n\nDeSanto agrees and predicts that [AI-assisted workflows will gain popularity](/blog/why-ai-in-devops-is-here-to-stay/) in application development. “AI/ML will further enable rapid development, security remediation, improved test automation, and better observability,” he says.\n\n[Taylor McCaslin](https://gitlab.com/tmccaslin), Group Manager of Product for Data Science, says that while AI/ML certainly isn’t new, making technologies such as open-ended AI accessible to consumers, set an expectation to figure out how it could be better used in software development (think code completion and other such tasks).\n\nHe predicts that while AI/ML will be used all along the SDLC, organizations will grapple with privacy concerns, preserving intellectual property (such as AI-generated code ownership) and permissiveness of licenses for training data sets and algorithms.\n\nAt the same time, he says to look for “more rapid development in the MLOps and DataOps spaces to help developers manage, maintain, and iterate on production software systems that leverage ML and AI.” (Note: GitLab is investing in our ModelOps stage to help support the development of data science-enriched software within the GitLab platform.)\n\n## Prediction 4: Value stream analytics will take on a greater role in organizations\n\nThe digital transformation that organizations will undergo this year will require a deeper commitment to [examining value streams](/blog/the-gitlab-quarterly-how-our-latest-beta-releases-support-developers/). “Value stream analytics will extend past development workflows to provide a more holistic view of the value organizations deliver to their users (both internal and external),” DeSanto says.\n\nExecutive leadership will seek out metrics that give insight into how digital transformation and technological investments are delivering value and driving business results. This is a shift from solely focusing on development efficiencies. The 2022 Global DevSecOps survey found that 75% of respondents are either using a DevOps platform or plan to move to one within a year with one of the drivers of this change being metrics and observability.\n\n## Prediction 5: Observability will shift left for efficient DevSecOps \n\n[Observability](/direction/monitor/platform-insights/) will also move further left in the SDLC, according to [Michael Friedrich](https://gitlab.com/dnsmichi), Senior Developer Evangelist. “Observability-driven development will enable everyone to become more efficient and inspire innovation,\" he says.\n\nNew observability-enabling technologies like [eBPF](https://ebpf.io/what-is-ebpf) will help developers with automated code instrumentation instead of adding more workload with manual code instrumentation. eBPF also supports better observability and security workflows in cloud-native environments.\n\nObservability will play a critical role in improving the efficiency of DevSecOps workflows, including CI/CD, infrastructure cost analysis, and trending/forecasting for better capacity planning.\n\n_What do you think will be the big DevSecOps technology advancements this year? Let us know your predictions in the comments below._\n\n## Engage with DevSecOps experts\n\nWant to dig deeper into how to innovate while still keeping an eye on cost efficiencies? Sign up for our webcast [“GitLab’s DevSecOps Innovations and Predictions for 2023”](https://page.gitlab.com/webcast-gitlab-devsecops-innovations-predictions-2023.html?utm_medium=blog&utm_source=gitlab&utm_campaign=devopsgtm&utm_content=fy23q4release) on Jan. 31 to get expert advice and insights about this era of DevSecOps transformation and the tools and strategies you’ll need to meet this challenge. \n[Register](https://page.gitlab.com/webcast-gitlab-devsecops-innovations-predictions-2023.html?utm_medium=blog&utm_source=gitlab&utm_campaign=devopsgtm&utm_content=fy23q4release) today!\n\nCover image by [Drew Beamer](https://unsplash.com/@dbeamer_jpg?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://www.unsplash.com/)\n{: .note}\n",[851,704,786,9],{"slug":6429,"featured":6,"template":683},"whats-next-for-devsecops","content:en-us:blog:whats-next-for-devsecops.yml","Whats Next For Devsecops","en-us/blog/whats-next-for-devsecops.yml","en-us/blog/whats-next-for-devsecops",{"_path":6435,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6436,"content":6442,"config":6447,"_id":6449,"_type":13,"title":6450,"_source":15,"_file":6451,"_stem":6452,"_extension":18},"/en-us/blog/why-all-organizations-need-prometheus",{"title":6437,"description":6438,"ogTitle":6437,"ogDescription":6438,"noIndex":6,"ogImage":6439,"ogUrl":6440,"ogSiteName":670,"ogType":671,"canonicalUrls":6440,"schema":6441},"Why Prometheus is for everyone","You think you don't need Prometheus – I'm here to tell you why you're wrong. Learn why GitLab uses Prometheus, and why your organization should be using it too!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678778/Blog/Hero%20Images/monitoring-cover.png","https://about.gitlab.com/blog/why-all-organizations-need-prometheus","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why Prometheus is for everyone\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Matos\"}],\n        \"datePublished\": \"2018-09-27\",\n      }",{"title":6437,"description":6438,"authors":6443,"heroImage":6439,"date":6444,"body":6445,"category":849,"tags":6446},[5731],"2018-09-27","\nIt's no secret that here at GitLab, we hitched our wagon to [Prometheus](https://docs.gitlab.com/ee/administration/monitoring/prometheus/index.html#doc-nav) long ago. We've been\n[shipping it with GitLab since 8.16](/releases/2017/01/22/gitlab-8-16-released/). Having said that,\neven within GitLab we weren't all using Prometheus. The Support Engineering team was\nvery much in the camp of \"We don't need this to troubleshoot customer problems.\" We were wrong;\nwe needed Prometheus all along, and here's why your organization should be using it too.\n\n## What is Prometheus?\n\nFor a short answer, Prometheus is software that stores event data in real-time. But more specifically…\n\nPrometheus is a powerful and free open-source software monitoring service that records real-time metrics and provides real-time alerts. It’s built with an HTTP pull model. Prometheus collects data performance metrics which you can view through an external dashboard tool (such as Grafana) or by directly connecting to Prometheus. \n\nSoundcloud was the original developer of Prometheus but nowadays is continuously maintained by the Cloud Native Computing Foundation (CNCF). The cloud-native architecture of Prometheus has made it extremely popular as part of a modern technology stack. \n\n## Prometheus is great, so why isn't everyone using it already?\n\nI think GitLab customers fall into a few categories: You have the customer who wants to use GitLab\nbut can't or doesn't want to manage servers. They'll use [GitLab.com](/pricing/)! By making that choice they can\nleverage the hard work of our Production team and reap the benefits of what Prometheus has to offer.\n\nThen you have the customer who is [running their own simple GitLab deployment](/pricing/#self-managed), but they may\nnot know or appreciate the value of Prometheus metrics. The Support Engineering team was\nlike this too! We thought, \"We can use traditional tools. Just knowing about where logging is,\nknowing about the system, is enough to actually solve the problems that we see. Just having\nexperience is enough.\" Not so.\n\nThen you have large, enterprise customers who are deploying GitLab clusters with multiple dozens of\nservers and a lot of moving parts. For them, Prometheus really shines because the complexity\nballoons, and once you move GitLab from a single server to three, or four, or 20, being able\nto see all of the metrics in one view makes a huge difference in time to resolving critical infrastructure issues.\n\n## How we saw the light about Prometheus\n\nA large GitLab customer was experiencing a really strange, catastrophic failure scenario, and\nthe problem was proving evasive to the support team. Even after days of troubleshooting we couldn't\nfind what we were looking for, so we called in [Jacob](/company/team/#jacobvosmaer) from our\n[Gitaly](/blog/the-road-to-gitaly-1-0/) team because it looked like Gitaly was at the\ncore of the problem. We had been using Gitaly on GitLab.com for about six months at that point\nand he had never seen it behave this way before. It looked like Gitaly was accessing Git data,\nbut just _extremely slow_, and it would spread across the cluster one server at a time. Jacob\nand I speculated and made some Gitaly dashboards, and while that was a good moment of cross-team\ncollaboration, he was stumped.\n\nMost of the time when we're debugging GitLab, it's clear to pinpoint the root of the problem.\nBut in this case, it was a catastrophic failure across the entire cluster that was a ticking timebomb.\nWhen we'd see the indicators we'd effectively have 15-35 minutes before the entire fleet was down.\nThis customer actually had Prometheus on their roadmap but hadn't deployed it yet, so when\nthe failure happened it was top of our list of things to deploy:\n\n**Support**: We should focus on trying to understand why this host is affected.\n\n**Production**: If we get better observability with Prometheus we'll move faster.\n\n**Support**: I'm worried this is a distraction! We don't have much time.\n\n**Production**: Watch and learn. Watch and learn.\n\n_(Cue dramatic montage of hackers with GitLab stickers on their laptops feverishly typing under duress)_\n\nOnce Prometheus was in place, we called in the Production team. They run one of the largest\nGitLab instances: GitLab.com. We exported their dashboard and gave it to the customer, so\nwithin minutes they had a GitLab production-scale dashboard that was all of the things that\nour production engineers use. Now, we could leverage the wealth of knowledge of our Prometheus\nexperts, as it's a familiar interface and they know exactly what they're looking at.\n\nWith that as a starting point we started querying and slicing data, and dashboards, which let\nus build a couple of different facets that let us view the data and come to some conclusions.\n\"Okay, it looks like once a host becomes 'tainted,' all Git-level operations spike and _HALT_.\nNow we can finally ask the question, why?\" And then, when we asked that, we saw that it was\na problem with Amazon's EFS file system. We had hit some upper boundary of EFS access and,\nhaving identified it, we were able to fix it by moving those specific files out of EFS. After we\nmade that change it was easy to use Prometheus and Grafana to verify that the state was sound\nand everything was working as expected afterwards, without even lifting a finger. We just looked\nat the dashboard in place. So while the customer had intended to deploy Prometheus later this\nyear, now, in this emergency situation, Prometheus definitely saved the day and is a huge part\nof keeping their GitLab infrastructure healthy. Without it we wouldn't be nearly as confident\nor comfortable in our solution.\n\n## Prometheues has opened up a whole world of possibilities.\n\nWe have another large client that's on an older version of GitLab without Prometheus. We're\nworking to debug things there and while we're able to do it, it's slower going. It requires a lot\nmore manual effort to coalesce the data and get it in a form we can use. It often takes about\n35-40 minutes to get the data, slicing with grep, AWK, and friends and at least one man page\nto look up syntax. Whereas, with Prometheus and Grafana, we'd be able to just access and view\nthe data, query it, and affect it within minutes. We already have a lot of [built-in monitoring capabilities](https://docs.gitlab.com/ee/administration/monitoring/). GitLab is a complex\nsystem built of various open source sub-systems, and we're monitoring all of them with Prometheus.\nYou can too.\n\n### Everyone should be using our GitLab.com dashboard\n\nAs I said earlier, in our intense, catastrophic scenario we gave the customer our GitLab.com\ndashboard. Any customer can use this dashboard as a template! You literally can go to [dashboards.gitlab.com](https://dashboards.gitlab.com), click \"export,\" get the dashboard, run your instance, then click \"import.\" It will show up, and\nyou just need to tweak the name so that it's not defaulting to our GitLab Production cluster.\nThen Prometheus just fills in the data.\n\n\u003Ciframe src=\"https://giphy.com/embed/12NUbkX6p4xOO4\" width=\"480\" height=\"440\" frameBorder=\"0\" class=\"giphy-embed\" allowFullScreen>\u003C/iframe>\n\nWe're trying to standardize around using the dashboards here, so that while there are differences\nand nuances in the deployments etc., we're speaking a common language, and have a common\nmeeting point for GitLab engineers across teams to monitor and talk GitLab performance.\n\n## Are you convinced about Prometheues yet?\n\nWe're now actively training our support team on Prometheus. And it's likely that other organizations\nprobably have the same thing happening – where another group could be impacting or helping,\nbut they're not collaborating, so they can't see where or how they can help one another. We've\nseen the light! So, we're training our team on Prometheus, and it's something that we want\nto make sure that everybody can make use of.\n\nMany customers think they don't need Prometheus and are reluctant to use it because it adds\noverhead; you have to configure it and set it up, and it may require a bit of finessing. GitLab\nis trying to make that even easier, but right now when you're building a bespoke deployment,\nit requires a bit of time, and you may not think time invested is worth it. And I'm here to say,\nit is, get it now! In fact, it's already there. You just need to turn it on! I'm advocating that all\nlarge, customer deployments over 500 users have Prometheus running by 2019. Turn it on and\nthen we'll all reap the rewards.\n",[9,680,2018],{"slug":6448,"featured":6,"template":683},"why-all-organizations-need-prometheus","content:en-us:blog:why-all-organizations-need-prometheus.yml","Why All Organizations Need Prometheus","en-us/blog/why-all-organizations-need-prometheus.yml","en-us/blog/why-all-organizations-need-prometheus",{"_path":6454,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6455,"content":6461,"config":6466,"_id":6468,"_type":13,"title":6469,"_source":15,"_file":6470,"_stem":6471,"_extension":18},"/en-us/blog/why-devops-and-zero-trust-go-together",{"title":6456,"description":6457,"ogTitle":6456,"ogDescription":6457,"noIndex":6,"ogImage":6458,"ogUrl":6459,"ogSiteName":670,"ogType":671,"canonicalUrls":6459,"schema":6460},"Why DevOps and zero trust go together","Learn how DevOps and zero trust have matured into a solid pairing and the security considerations that come into play.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683257/Blog/Hero%20Images/devopszerotrust.jpg","https://about.gitlab.com/blog/why-devops-and-zero-trust-go-together","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why DevOps and zero trust go together\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-08-17\",\n      }",{"title":6456,"description":6457,"authors":6462,"heroImage":6458,"date":6463,"body":6464,"category":704,"tags":6465},[4973],"2022-08-17","\n\nWhen the concept of zero trust was first [introduced in 2010 by Forrester Research](https://media.paloaltonetworks.com/documents/Forrester-No-More-Chewy-Centers.pdf), it seemed directly aimed at enterprise security professionals, who were struggling to keep the network perimeter safe from breaches and attacks. As enterprises and zero trust frameworks have evolved, DevOps has become the perfect home for these principles.\n\nZero trust requires all users – human and machine, internal or external – to be authenticated, authorized, and continuously validated to first access and continue to access resources. These requirements are fully aligned with modern application development and the advent of DevSecOps, where security continues to shift left in the development life cycle.\n\nIn 2019, GitLab Staff Security Engineer [Mark Loveless](/company/team/#mloveless) began to examine the [opportunities in marrying DevOps and zero trust](/blog/evolution-of-zero-trust/). Much has changed since then, including a greater acceptance, adoption, and, in some cases, requirement of zero trust frameworks. For instance, in its [executive order on cybersecurity](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/), the Biden administration referenced zero trust and the National Institute of Standards and Technology (NIST) called out zero trust architecture as an approach to its [Secure Software Development Framework](/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/) standard.\n\n## Addressing zero trust confusion\n\nAs zero trust strategies have become more popular, confusion in the market has increased. For instance, zero trust is not a single product or service – it is a strategy applied to a security framework.\n\n“Companies are marketing their zero trust solutions as _THE_ solution. They claim that zero trust solves everything wrong and you’ll be secure. No single solution out there addresses all of the authentication problems that organizations encounter,” Loveless says.\n\nAnother point of confusion, according to Loveless, is the fact that some early zero-trust backers have not evolved with zero trust itself. “The core beginnings of zero trust go back a couple of decades, originally centered around users and specific systems. There is an entire world of newer technology, including the cloud, automation, and AI, that has emerged since then that is out there and completely underrepresented in approaches to zero trust,” he says.\n\n## How zero trust fits into modern DevOps\n\nZero trust has three core components that must be fully understood to be able to map it to modern application development:\n\n- Data must be protected. Before the data can be accessed, the identity of who or what (in the case of automation) is accessing the data needs to be determined and a decision has to be made as to whether that access will be granted.\n\n- The identity must be extremely specific. The requestor must be proven, preferably by cryptographic means, to be who or what they say they are.\n\n- A secure channel for accessing the data must be able to be established. After authentication, data in transit should be protected by a secure channel and that data should only be revealed to the requestor.\n\nWhere zero trust strategies often go astray is assuming that the requestor is human. As automation becomes more prevalent in DevOps, DevSecOps must account for the likelihood that a requestor could be automated. But this inevitably raises questions, according to Loveless, such as:\n\n- Is the automated request coming from a trusted device?\n- Who initiated the action that led to the automated process requesting the data?\n- Was it an automated process that kicked off a secondary automated process that is now requesting the data?\n- Does the person that set up the automated processes still have access to these processes’ credentials?\n\nLoveless says organizations might need to rethink their authentication and authorization approaches to get the most out of the DevOps-zero trust pairing because automation requires a greater level of sophistication. “Mutual authentication strategies like managing your own certificate authority or setting up mutual TLS can be challenging,” Loveless says. Instead, organizations might consider [implementing automated multifactor authentication tools such as OpenID Connect](https://docs.gitlab.com/ee/integration/openid_connect_provider.html). “One solution might negate another solution, or solving for one cloud provider might exclude another, creating limits,” he says.  \n\n## How GitLab’s DevOps Platform supports zero trust\n\nGitLab’s cohesion with zero trust stems largely from its belief that it is not a single solution to zero trust, but instead part of an ecosystem in support of zero trust principles. \n\nOrganizations can utilize GitLab to enact its zero trust framework, including the ability to:\n- set and enforce granular role-based access for all users and machines\n- authenticate users and machines before allowing access\n- require continuous authentication and authorization\n- monitor the security status of users and machines and quickly respond to issues\n- classify data and set and enforce access levels accordingly\n- audit data access in real-time and generate compliance reports\n\n## Going forward\n\nGitLab’s commitment to zero trust is foundational and ongoing. As zero trust frameworks evolve and more standards bodies require adherence to zero trust principles, GitLab will continue to be a trusted partner in meeting these demands.\n\nCover image by Max Tcvetkov on [Unsplash](https://unsplash.com/@your_scorpion?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n",[851,704,9],{"slug":6467,"featured":6,"template":683},"why-devops-and-zero-trust-go-together","content:en-us:blog:why-devops-and-zero-trust-go-together.yml","Why Devops And Zero Trust Go Together","en-us/blog/why-devops-and-zero-trust-go-together.yml","en-us/blog/why-devops-and-zero-trust-go-together",{"_path":6473,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6474,"content":6479,"config":6484,"_id":6486,"_type":13,"title":6487,"_source":15,"_file":6488,"_stem":6489,"_extension":18},"/en-us/blog/why-manjaro-builds-with-gitlab",{"title":6475,"description":6476,"ogTitle":6475,"ogDescription":6476,"noIndex":6,"ogImage":1367,"ogUrl":6477,"ogSiteName":670,"ogType":671,"canonicalUrls":6477,"schema":6478},"Why the Manjaro Linux distribution builds with GitLab","Watch this interview with the Manjaro project to learn why the Linux distribution chooses to build with GitLab.","https://about.gitlab.com/blog/why-manjaro-builds-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why the Manjaro Linux distribution builds with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Bryan Behrenshausen\"}],\n        \"datePublished\": \"2023-08-29\",\n      }",{"title":6475,"description":6476,"authors":6480,"heroImage":1367,"date":6481,"body":6482,"category":827,"tags":6483},[3504],"2023-08-29","\nThe [Manjaro](https://manjaro.org/) project is the newest member of the [GitLab Open Source Partners](https://go.gitlab.com/BM5JwV) community. Linux users know the Manjaro project as an [open source](https://go.gitlab.com/wYTY0o) operating system that is fast, reliable, and user-friendly. We recently caught up with project leaders [Philip Müller](https://gitlab.com/philm) and [Bernhard Landauer](https://gitlab.com/oberon-manjaro) to learn how GitLab helps the Manjaro community accomplish its great work.\n\n> [Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n\n## Why the Manjaro project moved to GitLab\nIn 2018, the Manjaro community decided to [adopt GitLab](https://gitlab.manjaro.org) as its development platform, citing several key motivations:\n* **Achieve greater data sovereignty.** By migrating to a new development platform, Manjaro wanted to gain greater control over project development infrastructure. The community now hosts its own dedicated GitLab instance, where all critical Manjaro development occurs. The move has meant greater freedom and autonomy for the community. \"It feels really good to self-host and have our own control,\" Landauer said.\n\n* **Empower a small group of volunteers.** Like so many other open source projects, Manjaro relies on the dedicated work of volunteer contributors from across the world. Müller explained that the project needed a toolkit that could equip a core group of 16 developers to maintain [more than 3,000 packages](https://gitlab.manjaro.org/packages) and foster a community of roughly 8,000 participants. GitLab's sophisticated [CI/CD functionality](https://docs.gitlab.com/ee/ci/) helps the community scale to empower its relatively small developer team to manage ever-increasing complexity.\n\n* **Expand monitoring capabilities.** Using GitLab grants community leads much greater visibility into the project's operations, Müller said. By configuring various activity feeds, maintainers can more efficiently monitor potential pipeline issues and build failures across projects in the Manjaro namespace. Adopting GitLab also produced an interesting network effect for Manjaro: Using the same platform as peers, dependencies, and upstream projects meant greater overall visibility into Manjaro's open source ecosystem. \"Projects like [GNOME and KDE are switching](https://go.gitlab.com/BM5JwV) also over to GitLab,\" Müller said. \"We can look at what the upstream is doing.\"\n\n## Watch the interview\nTo learn more about Manjaro's use of GitLab, watch the full interview.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Rn5IiI3--Ag\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n[Join us at Open Source Summit Europe 2023](https://go.gitlab.com/dPQ92t) to learn more about GitLab's dedication to open source.\n{: .note}\n",[1187,266,9],{"slug":6485,"featured":6,"template":683},"why-manjaro-builds-with-gitlab","content:en-us:blog:why-manjaro-builds-with-gitlab.yml","Why Manjaro Builds With Gitlab","en-us/blog/why-manjaro-builds-with-gitlab.yml","en-us/blog/why-manjaro-builds-with-gitlab",{"_path":6491,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6492,"content":6498,"config":6503,"_id":6505,"_type":13,"title":6506,"_source":15,"_file":6507,"_stem":6508,"_extension":18},"/en-us/blog/working-on-two-git-branches-at-the-same-time",{"title":6493,"description":6494,"ogTitle":6493,"ogDescription":6494,"noIndex":6,"ogImage":6495,"ogUrl":6496,"ogSiteName":670,"ogType":671,"canonicalUrls":6496,"schema":6497},"How to work on two Git branches at the same time","Watch the demo on how using the GitLab Web IDE and your local dev environment to work on two branches at once can help save time.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678782/Blog/Hero%20Images/working-on-two-git-branches-at-the-same-time.jpg","https://about.gitlab.com/blog/working-on-two-git-branches-at-the-same-time","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to work on two Git branches at the same time\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"William Chia\"}],\n        \"datePublished\": \"2018-10-03\",\n      }",{"title":6493,"description":6494,"authors":6499,"heroImage":6495,"date":6500,"body":6501,"category":849,"tags":6502},[2977],"2018-10-03","\nI was recently using both my local development environment and the GitLab [Web IDE](/blog/introducing-gitlab-s-integrated-development-environment/), and found a really nice workflow for working with two Git branches simultaneously.\n\n### The problem\n\nIn this scenario, you’re doing development work on one branch, in one part of your codebase, and then likely documenting your process in another place. I really don’t want all of this in one merge request, because I don’t want to delay shipping the development work if [the docs](https://docs.gitlab.com) aren’t done. I want to be able to get it live so that others can see it, give feedback on each individual component, and iterate on it. At the same time, I don’t want to delay too long on documenting the process, because I want the docs to be as accurate and reproducible as possible.\n\n### The fix\n\nWhile doing my development work in my local development environment, I created another merge request for the documentation using the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/), essentially working on two different Git branches at the same time, using two different editors.\n\nIn my quick example below, you can see a merge request to add Jenkins content to our [DevOps tools](/competition/) page. I’ve checked out this branch locally, and I have it open in my Atom editor. I’ve been doing some work by updating `features.yml`, as well as a Markdown file and a Haml file. All of these changes are related to one merge request. While I’m committing changes locally to the comparison page, I’m documenting each step in my Web IDE in a separate tab, to make sure my instructions are precise, helpful, and completed in real time.\n\n### Watch the demo\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uV3ycYnwhBc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nYou can see what we've got planned for the Web IDE in 2019 in our post about [our product vision for DevOps Create](/blog/create-vision/).\n\nWhat are other ways the Web IDE has come in handy for you? Let us know by tweeting us [@gitlab](https://twitter.com/gitlab)!\n\nCover [photo](https://unsplash.com/photos/3y1zF4hIPCg) by [Hans-Peter Gauster](https://unsplash.com/photos/3y1zF4hIPCg) on Unsplash\n{: .note}\n",[976,9,3058,680,894],{"slug":6504,"featured":6,"template":683},"working-on-two-git-branches-at-the-same-time","content:en-us:blog:working-on-two-git-branches-at-the-same-time.yml","Working On Two Git Branches At The Same Time","en-us/blog/working-on-two-git-branches-at-the-same-time.yml","en-us/blog/working-on-two-git-branches-at-the-same-time",{"_path":6510,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6511,"content":6517,"config":6522,"_id":6524,"_type":13,"title":6525,"_source":15,"_file":6526,"_stem":6527,"_extension":18},"/en-us/blog/working-with-performance-metrics",{"title":6512,"description":6513,"ogTitle":6512,"ogDescription":6513,"noIndex":6,"ogImage":6514,"ogUrl":6515,"ogSiteName":670,"ogType":671,"canonicalUrls":6515,"schema":6516},"How application performance monitoring metrics helps developers","Automatically detect and monitor Kubernetes Clusters and deployed applications from the GitLab interface with application performance metrics (APM).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665635/Blog/Hero%20Images/blog-performance-metrics.jpg","https://about.gitlab.com/blog/working-with-performance-metrics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How application performance monitoring metrics helps developers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Saumya Upadhyaya\"},{\"@type\":\"Person\",\"name\":\"Dov Hershkovitch\"}],\n        \"datePublished\": \"2020-05-07\",\n      }",{"title":6512,"description":6513,"authors":6518,"heroImage":6514,"date":6519,"body":6520,"category":1249,"tags":6521},[1570,1454],"2020-05-07","\n[Application Performance Metrics](/direction/monitor/platform-insights/), also referred to as GitLab Metrics, is designed for developers who need to understand the impact of the changes they are making on performance, and DevOps engineers/operators who are tasked with keeping the production systems up and running. GitLab Metrics, which is at [viable maturity](/direction/maturity/#monitor), can automatically detect and monitor Kubernetes clusters deployed via GitLab. The GitLab Metrics tool can also monitor all of your custom application metrics so that you can see how your entire system is behaving and performing without leaving the familiar GitLab interface.\n\nGitLab has application performance monitoring tightly and automatically integrated into the DevOps process, which allows you to move seamlessly from development to production with confidence. GitLab Metrics is just one part of the [GitLab Monitoring solution](/direction/monitor/). When the whole suite of GitLab Monitoring tools is used together, we can help you decrease the frequency and severity of production incidents.\n\n## What’s under the hood?\n\nGitLab Metrics is powered by [Prometheus](https://prometheus.io/). Prometheus is quickly becoming the de facto standard for metrics for the cloud native community, because it rises to the top for monitoring Kubernetes and the available integrations cover the major elements of the cloud native ecosystem.\n\n## How to use GitLab Metrics?\n\nGitLab Metrics can be used in two ways.\n\nFirst, you can use Prometheus as a [managed application](https://docs.gitlab.com/ee/update/removals.html) within GitLab. Prometheus can be installed into your GitLab managed Kubernetes cluster with one click.\n\n![System Metrics](https://about.gitlab.com/images/blogimages/blog-metrics-system-metrics.png){: .shadow}\nHow the system metrics dashboard looks to users.\n{: .note.text-center}\n\nWhen integrated with Prometheus and Kubernetes, GitLab Metrics includes the following powerful capabilities:\n* [Default metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#getting-metrics-to-display-on-the-metrics-dashboard) collected from Prometheus, such as memory and core usage for the pod and canary deployment, Knative invocations, NGINX, AWS ELB, HA Proxy metrics, etc.\n* [Custom metrics](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#adding-additional-metrics) can be configured with a promQL query.\n* [Alerts](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#setting-up-alerts-for-prometheus-metrics) can be added on the UI directly for each metric.\n* Application deploys works by deploying to the monitored environment and can be [visualized on the metrics chart](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#getting-metrics-to-display-on-the-metrics-dashboard) itself to correlate performance spikes due to deploys.\n* [Custom dashboards](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#defining-custom-dashboards-per-project) can be configured as a YAML file and an existing GitLab default dashboard can be replicated as required.\n\n![Custom Dashboards](https://about.gitlab.com/images/blogimages/blog-metrics-key-services.png){: .shadow}\nUse a YAML file to configure a customized Metrics dashboard.\n{: .note.text-center}\n\nIf you already have an operational Prometheus instance that you would like to integrate with GitLab, you can simply point to the Prometheus server from within GitLab. In this case, performance metrics are retrieved from the external instance of Prometheus, and displayed within the GitLab interface.\n\n## How is GitLab dogfooding our metrics capability?\n\nAt GitLab, [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is one of the main tenets of our [results](https://handbook.gitlab.com/handbook/values/#results) value.\n\nThe [GitLab infrastructure team](/handbook/engineering/infrastructure/) is used as an internal customer, and they provide feedback which feeds directly into how we develop our metrics capabilities. Prometheus and Grafana are two tools the GitLab infrastructure team uses. One of the main reasons the infrastructure team was reluctant to implement GitLab metrics was our previously inadequate graphing capabilities. To encourage our infrastructure team to dogfood metrics, we are focused on filling critical and non-critical gaps in GitLab metrics charts, which initiates a feedback loop for the product. Our goal is to eventually phase out Grafana and work exclusively with Prometheus and GitLab charts to monitor GitLab.com, we will do it on our GitLab way, iteratively, first we'll replace all of our publicly facing [dashboard](https://dashboards.gitlab.com/).\n\n## What's next for GitLab Metrics\n\nGet started by visiting the GitLab Metrics [documentation page](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html) and [directions page](/direction/monitor/platform-insights/). We’d love your help with prioritizing work on the most valuable improvements to the GitLab Metrics solution.\n\nTo report a bug or request a feature or enhancement, follow these steps:\n* Open an issue in the [GitLab project](https://gitlab.com/gitlab-org/gitlab/issues).\n* Describe the feature enhancement and, if possible, include examples.\n* Add these labels to the issue: `devops::monitor`, `Category::Metrics`\n* Tag @dhershkovitch on the issue\n\nCover image by [chuttersnap](https://unsplash.com/photos/gts_Eh4g1lk) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[851,9],{"slug":6523,"featured":6,"template":683},"working-with-performance-metrics","content:en-us:blog:working-with-performance-metrics.yml","Working With Performance Metrics","en-us/blog/working-with-performance-metrics.yml","en-us/blog/working-with-performance-metrics",{"_path":6529,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":6530,"content":6536,"config":6541,"_id":6543,"_type":13,"title":6544,"_source":15,"_file":6545,"_stem":6546,"_extension":18},"/en-us/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"title":6531,"description":6532,"ogTitle":6531,"ogDescription":6532,"noIndex":6,"ogImage":6533,"ogUrl":6534,"ogSiteName":670,"ogType":671,"canonicalUrls":6534,"schema":6535},"10 best practices for using AI-powered GitLab Duo Chat","Explore tips and tricks for integrating GitLab Duo Chat into your AI-powered DevSecOps workflows. Plus, expert advice on how to refine chat prompts for the best results.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097639/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_77JeTV9gAmbXM0224acirV_1750097638765.png","https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"10 best practices for using AI-powered GitLab Duo Chat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-04-02\",\n      }",{"title":6531,"description":6532,"authors":6537,"heroImage":6533,"date":6538,"body":6539,"category":806,"tags":6540},[2037],"2024-04-02","Getting into a conversation with AI can be challenging. What question do you start with? How do you frame the question? How much context is needed? Will the conversation provide the best and most efficient results?\n\nIn this tutorial, we explore 10 tips and best practices to integrate GitLab Duo Chat into your AI-powered DevSecOps workflows and refine your prompts for the best results.\n\n[Get started: Keep GitLab Duo Chat open and in sight](#get-started-keep-gitlab-duo-chat-open-and-in-sight)\n\n[10 best practices for using GitLab Duo Chat](#10-best-practices-for-using-gitlab-duo-chat)\n\n1. [Have a conversation](#1.-have-a-conversation)\n2. [Refine the prompt for more efficiency](#2.-refine-the-prompt-for-more-efficiency)\n3. [Follow prompt patterns](#3.-follow-prompt-patterns)\n4. [Use low-context communication](#4.-use-low-context-communication)\n5. [Repeat yourself](#5.-repeat-yourself)\n6. [Be patient](#6.-be-patient)\n7. [Reset and start anew](#7.-reset-and-start-anew)\n8. [Gain efficiency with slash commands in the IDE](#8.-gain-efficiency-with-slash-commands-in-the-ide)\n9. [Refine the prompt for slash commands](#9.-refine-the-prompt-for-slash-commands)\n10. [Get creative with slash commands](#10.-get-creative-with-slash-commands)\n\nBonus content:\n- [Shortcuts](#shortcuts)\n- [Fun exercises](#fun-exercises)\n- [Learn more](#learn-more)\n\n> Live demo! Discover the future of AI-driven software development with our GitLab 17 virtual launch event. [Register today!](https://about.gitlab.com/seventeen/)\n\n## Get started: Keep GitLab Duo Chat open and in sight\n\n[GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) is available in the GitLab UI, Web IDE, and supported programming IDEs, for example, VS Code. \n\nIn VS Code, you can open GitLab Duo Chat in the default left pane. You can also drag and drop the icon into the right pane. This allows you to keep Chat open while you write code and navigate the file tree, perform Git actions, etc. To reset the Chat location, open the command palette (by pressing the `Command+Shift+P` (on macOS) or `Ctrl+Shift+P` (on Windows/Linux) keyboard shortcut and then type `View: Reset View Locations`. The following short video shows you how to do it.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/foZpUvWPRJQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThe Web IDE and VS Code share the same framework – the same method works in the Web IDE for more efficient workflows.\n\n![Chat in Web IDE](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097645344.png)\n\n## 10 best practices for using GitLab Duo Chat\n\n### 1. Have a conversation\n\nChats are conversations, not search forms.\n\nFor the first conversation icebreaker, you can start with the same search terms similar to a browser search and experiment with the response and output. In this example, let's start with a C# project and best practices. \n\n> c# start project best practices\n\n![Chat prompt for C# start project best practices and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097646/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097645345.png)\n\nThe response is helpful to understand a broad scope of C#, but does not kickstart immediate best practices. Let's follow up with a more focused question in the same context. \n\n> Please show the project structure for the C# project.\n\n![Chat prompt for project structure for the C# project and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097645346.png)\n\nThis answer is helpful. Next, let's follow up with a Git question, and use the same question structure: Direct request to show something.\n\n> Show an example for a .gitignore for C#\n\n![Chat prompt for a .gitignore for C# and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image25_aHR0cHM6_1750097645347.png)\n\nContinue with CI/CD and ask how to build the C# project.\n\n> Show a GitLab CI/CD configuration for building the C# project\n\n![Chat prompt for GitLab CI/CD configuration for building C# project and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image16_aHR0cHM6_1750097645349.png)\n\nIn this example, Chat encouraged us to request specific changes. Let's ask to use the .NET SDK 8.0 instead of 6.0. \n\n> In the above example, please use the .NET SDK 8.0 image\n\n![Chat prompt to use .NET SDK 8.0 image and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image32_aHR0cHM6_1750097645350.png)\n\nThe CI/CD configuration uses the .NET command line interface (CLI). Maybe we can use that for more efficient commands to create the projects and tests structure, too? \n\n> Explain how to create projects and test structure on the CLI \n\n![Chat prompt to explain how to create projects and test structure on the CLI and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097645351.png)\n\nOf course, we could execute these commands in the terminal, but what if we wanted to stay in VS Code? Let's ask Chat.\n\n> Explain how to open a new terminal in VS Code\n\n![Chat prompt to explain how to open a new terminal in VS Code and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097645351.png)\n\n### 2. Refine the prompt for more efficiency\n\nThink of GitLab Duo Chat as a human, and engage with full sentences that provide as much context into your thoughts and questions. \n\nExperienced browser search users might know this approach to queries: Build up the question, add more terms to refine the scope, and restart the search after opening plenty of tabs. \n\nIn a browser search, this probably would result in four to five different search windows. \n\n```markdown\nc# start project best practices\nc# .gitignore\nc# gitlab cicd \nc# gitlab security scanning \nc# solutions and projects, application and tests\n``` \n\nYou can follow this strategy in a chat conversation, too. It requires adding more context, making it a conversational approach. GitLab Duo Chat enables you to ask multiple questions in one conversation request. Example: You need to start with a new C# project, apply best practices, add a `.gitignore` file, and configure CI/CD and security scanning, just like in the above search. In Chat, you can combine the questions into one request.\n\n> How can I get started creating an empty C# console application in VS Code? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI.\n\n![Chat prompt adding more context and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image37_aHR0cHM6_1750097645352.png)\n\nIn this response, Chat suggests to ask for specific configuration examples in follow-up questions in the conversation. Async practice: Create follow-up questions. You can omit `C#` as context in the same chat session.\n\n> Please show an example for a .gitignore. Please show a CI/CD configuration. Include the SAST template.\n\n### 3. Follow prompt patterns \n\nFollow the pattern: `Problem statement, ask for help, provide additional requests`. Not everything comes to mind when asking the first question – don't feel blocked, and instead start with `Problem statement, ask for help` in the first iteration. \n\n> I need to fulfill compliance requirements. How can I get started with Codeowners and approval rules?\n\n![Chat prompt to get started with Codeowners and approval rules and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750097645352.png)\n\nThe answer is helpful but obviously generic. Now, you may want to get specific help for your team setup. \n\n> Please show an example for Codeowners with different teams: backend, frontend, release managers.\n\n![Chat prompt to show an example for Codeowners with different teams: backend, frontend, release managers and reponse ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image31_aHR0cHM6_1750097645353.png)\n\nAn alternative is to describe the situation you are in and to ask for input. It can feel a bit like a conversation to follow the STAR model (Situation, Task, Action, Results). \n\n> I have a Kubernetes cluster integrated in GitLab. Please generate a Yaml configuration for a Kubernetes service deployment. Explain how GitOps works as a second step. How to verify the results?\n\n![Chat prompt with multiple questions and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image27_aHR0cHM6_1750097645354.png)\n\n### 4. Use low-context communication \n\nProvide as much context as needed to provide an answer. Sometimes, the previous history or opened source code does not provide that helpful context. To make questions more efficient, apply a pattern of [low-context communication](https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/#understanding-low-context-communication), which is used in all-remote communication at GitLab.\n\nThe following question did not provide enough context in a C++ project.\n\n> Should I use virtual override instead of just override?\n\n![Chat prompt asking if the users should use virtual override instead of just override and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image34_aHR0cHM6_1750097645354.png)\n\nInstead, try to add more context:\n\n> When implementing a pure virtual function in an inherited class, should I use virtual function override, or just function override? Context is C++. \n\n![Chat prompt with more detail and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image36_aHR0cHM6_1750097645355.png)\n\nThe example is also shown in the [GitLab Duo Coffee Chat: Refactor C++ functions into OOP classes for abstract database handling](https://youtu.be/Z9EJh0J9358?t=2190). \n\n### 5. Repeat yourself\n\nAI is not predictable. Sometimes, it may not answer with the expected results, or does not produce source code examples or configuration snippets because it lacked context. It is recommended to repeat the question and refine the requirements.\n\nIn the following example, we want to create a C# application. In the first attempt, we did not specify the application type – C# can be used to create console/terminal but also UI applications. The result also does not provide an empty example source code. The second, repeated prompt adds two more words - `console` and `empty`. \n\n> How can I get started creating an C# application in VSCode?\n> \n> How can I get started creating an empty C# console application in VSCode?\n\nThe results in the prompt differ. The first response is helpful to get started by following the instructions in the VS Code window, but it does not tell us where the source code is located and how to modify it. The repeated prompt with refinements modifies the response and provides instructions how to override the default template with some “hello world” code.\n\n![Chat prompt with repeated prompt with modifications and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image28_aHR0cHM6_1750097645355.png)\n\nYou can also combine repeat and refine strategies, and ask Chat to show an example for application code and tests.\n\n> How can I get started creating an empty C# console application in VSCode? Please show an example for application and tests.\n\n![Chat prompt that asks for example for application and tests and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097645356.png)\n\n#### Repeat yourself after generic questions \n\nWhen asking generic technology questions, GitLab Duo Chat might not be able to help. In the following scenario, I wanted to get a suggestion for Java build tools and framework, and it did not work. There could be many answers: Maven, Gradle, etc., as build tools, and [100+ Java frameworks](https://en.wikipedia.org/wiki/List_of_Java_frameworks), depending on the technology stack and requirements.\n\n![Chat prompt for Java build tools and framework and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097645356.png)\n\nLet's assume that we want to focus on a customer environment with [Java Spring Boot](https://spring.io/projects/spring-boot). \n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example.\n\n![Chat prompt that asks for more, including a hello world example and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image26_aHR0cHM6_1750097645357.png)\n\nThis provides great results already. As an async exercise, repeat the prompt, and ask how to deploy the application, adding more refinements in each step. Alternatively, you can make it a follow-up conversation.\n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD.\n> \n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images.\n> \n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images. Use Kubernetes and GitOps in GitLab.\n\n### 6. Be patient\n\nSingle words or short sentences might not generate the desired results, [as shown in this video example](https://youtu.be/JketELxLNEw?t=1220). Sometimes, GitLab Duo Chat is able to guess from available data, but sometimes also might insist on providing more context.\n\nExample: `labels` matches the GitLab documentation content.\n\n![Chat prompt about labels and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097645357.png)\n\nRefine the question to problem statements and more refinements for issue board usage.\n\n> Explain labels in GitLab. Provide an example for efficient usage with issue boards.\n\n![Chat prompt that includes asking for an example and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750097645358.png)\n\nOr use a problem statement, followed by a question and the ask for additional examples.\n\n> I don't know how to use labels in GitLab. Please provide examples, and how to use them for filters in different views. Explain these views with examples.\n\n![Chat prompt with problem statement and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097645358.png)\n\nAlso, avoid `yes/no` questions and instead add specific context.\n\n> Can you help me fix performance regressions?\n\n![Chat promptt that asks for help with fixing performance regressions and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750097645359.png)\n\nInstead, provide the context of the performance regression, including the programming languages, frameworks, technology stack, and environments. The following example uses an environment from some years ago, which can still be accurate today.\n\n> My PHP application encounters performance regressions using PHP 5.6 and MySQL 5.5. Please explain potential root causes, and how to address them. The app is deployed on Linux VMs.\n\n![Chat prompt that includes more detail and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image24_aHR0cHM6_1750097645360.png)\n\n### 7. Reset and start anew\n\nSometimes, the chat history shows a different learning curve and provides the wrong context for follow-up questions. Or, you asked specific questions where GitLab Duo Chat cannot provide answers. Since generative AI is not predictable, it might also lack the ability to provide certain examples, but think it gave them in a future response (observed in Chat Beta). The underlying large language models, or LLMs, sometimes might insist on giving a specific response, in an endless loop.\n\n> How can I get started creating an empty C# console application in VSCode? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI.\n\nAfter asking the question above with an example configuration, I wanted to reduce the scope of the question to get a more tailored response. It did not work as expected, since Chat knows about the chat history in context, and refers to previous answers.\n\n> How can I get started creating an empty C# console application in VSCode? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#.\n\n![Chat prompt that asks for configuration examples and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image23_aHR0cHM6_1750097645360.png)\n\nTo force Chat into a new context, use `/reset` as slash command to reset the session, and repeat the question to get better results. You can also use `/clean` or `/clear` to delete all messages in the conversation.\n\n### 8. Gain efficiency with slash commands in the IDE \n\n#### Explain code\n\n- Q: Generated code? Existing code? Legacy code?\n- A: Use the [`/explain` slash command in the IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#explain-code-in-the-ide).\n- A2: Refine the prompt with more focused responses, for example: `/explain focus on potential shortcomings or bugs`. \n\n![Chat prompt with /explain slash command](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/gitlab_duo_chat_slash_commands_explain_01_aHR0cHM6_1750097645361.png)\n\n![Chat prompt with refined prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097645361.png)\n\n#### Refactor code \n\n- Q: Unreadable code? Long spaghetti code? Zero test coverage?\n- A: Use the [`/refactor` slash command in the IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#refactor-code-in-the-ide). \n- A2: Refine the prompt for more targeted actions, for example object-oriented patterns: `/refactor into object-oriented classes with methods and attributes`. \n\n![Chat prompt with /refactor slash command](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image35_aHR0cHM6_1750097645362.png)\n\n![Chat prompt with refined prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image30_aHR0cHM6_1750097645362.png)\n\n#### Generate tests\n\n- Q: Testable code but writing tests takes too much time?\n- A: Use the [`/tests` slash command in the IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#write-tests-in-the-ide).\n- A2: Refine the prompt for specific test frameworks, or test targets. You can also instruct the prompt to focus on refactoring, and then generate tests: `/tests focus on refactoring the code into functions, and generate tests`.\n\n![Chat prompt with /tests slash command](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image29_aHR0cHM6_1750097645363.png)\n\n![Chat prompt with refined prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097645363.png)\n\nMore practical examples in complete development workflows are available in the [GitLab Duo examples](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html) documentation.\n\n### 9. Refine the prompt for slash commands \n\nYou will see refined prompts tips in this blog post a lot. It is one of the ingredients for better AI-powered workflow efficiency. Slash commands are no different, and allow for better results in GitLab Duo Chat.\n\nA customer recently asked: \"Can code explanations using `/explain` create comments in code?\" The answer is: no. But you can use the Chat prompt to ask follow-up questions, and ask for a summary in a code comment format. It requires the context of the language. \n\nThe following example with a [C++ HTTP client code using the curl library](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5cc9bdd65ee8ee16c548bea0402c18f8209d4d06/chat/slash-commands/c++/cli.cpp) needs more documentation. You can refine the `/explain` prompt by giving more refined instructions to explain the code by adding code comments, and then copy-paste that into the editor.\n\n> /explain add documentation, rewrite the code snippet\n\n![Chat prompt to add documentation and rewrite code snippet and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097645363.png)\n\nAlternatively, you can ask Chat to `/refactor` the source code, and generate missing code comments through a refined prompt.\n\n> /refactor add code comments and documentation\n\n![Chat prompt to refactor source code and generate code comments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750097645364.png)\n\n### 10. Get creative with slash commands\n\nWhen the Chat prompt does not know an answer to a question about the source code or programming language, look into the slash commands `/explain`, `/refactor`, and `/tests` and how much they can help in the context.\n\nIn the following example, an SQL query string in C++ is created in a single line. To increase readability, and also add more database columns in the future, it can be helpful to change the formatting into a multi-line string.\n\n> std::string sql = \"CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL)\";\n\nYou can ask GitLab Duo Chat about it, for example, with the following question:\n\n> How to create a string in C++ using multiple lines?\n\nChat may answer with an explanation and optional, a source code example. In this context, it can interpret the question to create a C++ string value with multiple lines, for example, using the `\\n` character, assigned to a variable. \n\nThe requirement instead is to only format the written code, and variable value assignment in multiple lines. The string value itself does not need to contain a multi-line string representation. \n\nThere is an alternative for additional context in VS Code and the Web IDE: Select the source code in question, right-click, and navigate into `GitLab Duo Chat > Refactor`. This opens the Chat prompt and fires the `/refactor` code task immediately.\n\nAlthough, the code task might not bring the expected results. Refactoring a single-line SQL string can mean a lot of things: Use multiple lines for readability, create constants, etc.\n\nCode tasks provide an option to refine the prompt. You can add more text after the `/refactor` command, and instruct GitLab Duo Chat to use a specific code type, algorithm, or design pattern. \n\nLet's try it again: Select the source code, change focus into Chat, and type the following prompt, followed by `Enter`. \n\n> /refactor into a multi-line written string. Show different approaches for all C++ standards.\n\n![Chat prompt to refactor into a multi-line written string and response](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750097645364.png)\n\n**Tip:** You can use GitLab Duo Code Suggestions to refine the source code even more after refactoring, or use alternative `/refactor` prompt refinements.\n\n>/refactor into a multi-line written string, show different approaches\n>\n> /refactor into multi-line string, not using raw string literals\n>\n> /refactor into a multi-line written string. Make the table name parametrizable\n\nAn alternative approach with the `stringstream` type is shown in the [GitLab Duo Coffee Chat: Refactor C++ functions into OOP classes for abstract database handling](https://www.youtube.com/watch?v=Z9EJh0J9358), [MR diff](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-coffee-chat/gitlab-duo-coffee-chat-2024-01-23/-/commit/7ea233138aed46d77e6ce0d930dd8e10560134eb#4ce01e4c84d4b62df8eed159c2db3768ad4ef8bf_33_35). \n\n#### Explain vulnerabilities\n\nIt might not always work, but the `/explain` slash command can be asked about security vulnerability explanations, too. In this example, the [C code](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c) contains multiple vulnerabilities for strcpy() buffer overflows, world writable file permissions, race condition attacks, and more.\n\n> /explain why this code has multiple vulnerabilities\n\n![Chat prompt about the code's multiple vulnerabilities](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750097645365.png)\n\n#### Refactor C code into Rust\n\nRust provides memory safety. You can ask Duo Chat to refactor the vulnerable [C code](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c) into Rust, using `/refactor into Rust`. Practice with more refined prompts to get better results.\n\n> /refactor into Rust and use high level libraries\n\n![Chat prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097645366.png)\n\n### Shortcuts \n\nGive these shortcuts a try in your environment, and practice async using GitLab Duo Chat.\n\n1. Inspect vulnerable code from CVEs, and ask what it does, and how to fix it, using `/explain why is this code vulnerable`. \n**Tip:** Import open-source projects in GitLab to take advantage of GitLab Duo Chat code explanations.\n1. Try to refactor code into new programming languages to help legacy code migration plans.\n1. You can also try to refactor Jenkins configuration into GitLab CI/CD, using `/refactor into GitLab CI/CD configuration`. \n\n### Fun exercises \n\nTry to convince Chat to behave like Clippy.\n![Chat prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image22_aHR0cHM6_1750097645366.png)\n\nAsk about GitLab's mission: \"Everyone can contribute.\"\n\n![Chat prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image33_aHR0cHM6_1750097645367.png)\n\n### Learn more\n\nThere are many different environments and challenges out there. We have updated the [GitLab Duo Chat documentation](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) with more practical examples, and added a new [GitLab Duo examples](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html) section with deep dives into AI-powered DevSecOps workflows, including Chat.\n\n> Want to get going with GitLab Duo Chat? [Start your free trial today](https://about.gitlab.com/solutions/gitlab-duo-pro/self-managed-and-gitlab-dedicated-trial/).\n",[786,746,478,9],{"slug":6542,"featured":90,"template":683},"10-best-practices-for-using-ai-powered-gitlab-duo-chat","content:en-us:blog:10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","10 Best Practices For Using Ai Powered Gitlab Duo Chat","en-us/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","en-us/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",34,[663,688,711,731,754,772,794,814,836],1753208219617]