[{"data":1,"prerenderedAt":1157},["ShallowReactive",2],{"/en-us/blog/tags/research/":3,"navigation-en-us":19,"banner-en-us":437,"footer-en-us":452,"research-tag-page-en-us":663},{"_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/research","tags",false,"",{"tag":9,"tagSlug":9},"research",{"template":11},"BlogTag","content:en-us:blog:tags:research.yml","yaml","Research","content","en-us/blog/tags/research.yml","en-us/blog/tags/research","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,"image":444,"config":447,"_id":449,"_type":13,"_source":15,"_file":450,"_stem":451,"_extension":18},"/shared/en-us/banner","is now in public beta!",{"text":67,"config":441},{"href":442,"dataGaName":443,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"config":445},{"src":446},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":448},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":453,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":659,"_type":13,"title":660,"_source":15,"_file":661,"_stem":662,"_extension":18},"/shared/en-us/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":651},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":457,"config":458},"View page source",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Edit this page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Please contribute",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,558,587,621],{"title":45,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOps platform",{"href":54,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":185,"links":486},[487,491,496],{"text":488,"config":489},"View plans",{"href":187,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Why Premium?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/pricing/premium/","why premium",{"text":497,"config":498},"Why Ultimate?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,535,540,542,545,548,553],{"text":505,"config":506},"Digital transformation",{"href":507,"dataGaName":508,"dataGaLocation":461},"/topics/digital-transformation/","digital transformation",{"text":133,"config":510},{"href":128,"dataGaName":511,"dataGaLocation":461},"security & compliance",{"text":122,"config":513},{"href":104,"dataGaName":105,"dataGaLocation":461},{"text":515,"config":516},"Agile development",{"href":517,"dataGaName":518,"dataGaLocation":461},"/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Cloud transformation",{"href":522,"dataGaName":523,"dataGaLocation":461},"/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":118,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":108,"config":529},{"href":110,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":532,"config":533},"Value stream management",{"href":160,"dataGaName":534,"dataGaLocation":461},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":461},"/solutions/gitops/","gitops",{"text":170,"config":541},{"href":172,"dataGaName":173,"dataGaLocation":461},{"text":543,"config":544},"Small business",{"href":177,"dataGaName":178,"dataGaLocation":461},{"text":546,"config":547},"Public sector",{"href":182,"dataGaName":183,"dataGaLocation":461},{"text":549,"config":550},"Education",{"href":551,"dataGaName":552,"dataGaLocation":461},"/solutions/education/","education",{"text":554,"config":555},"Financial services",{"href":556,"dataGaName":557,"dataGaLocation":461},"/solutions/finance/","financial services",{"title":190,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583,585],{"text":202,"config":561},{"href":204,"dataGaName":205,"dataGaLocation":461},{"text":207,"config":563},{"href":209,"dataGaName":210,"dataGaLocation":461},{"text":212,"config":565},{"href":214,"dataGaName":215,"dataGaLocation":461},{"text":217,"config":567},{"href":219,"dataGaName":568,"dataGaLocation":461},"docs",{"text":240,"config":570},{"href":242,"dataGaName":243,"dataGaLocation":461},{"text":235,"config":572},{"href":237,"dataGaName":238,"dataGaLocation":461},{"text":245,"config":574},{"href":247,"dataGaName":248,"dataGaLocation":461},{"text":258,"config":576},{"href":260,"dataGaName":261,"dataGaLocation":461},{"text":250,"config":578},{"href":252,"dataGaName":253,"dataGaLocation":461},{"text":263,"config":580},{"href":265,"dataGaName":266,"dataGaLocation":461},{"text":268,"config":582},{"href":270,"dataGaName":271,"dataGaLocation":461},{"text":273,"config":584},{"href":275,"dataGaName":276,"dataGaLocation":461},{"text":278,"config":586},{"href":280,"dataGaName":281,"dataGaLocation":461},{"title":296,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":303,"config":590},{"href":305,"dataGaName":298,"dataGaLocation":461},{"text":308,"config":592},{"href":310,"dataGaName":311,"dataGaLocation":461},{"text":316,"config":594},{"href":318,"dataGaName":319,"dataGaLocation":461},{"text":321,"config":596},{"href":323,"dataGaName":324,"dataGaLocation":461},{"text":326,"config":598},{"href":328,"dataGaName":329,"dataGaLocation":461},{"text":331,"config":600},{"href":333,"dataGaName":334,"dataGaLocation":461},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":461},"/sustainability/",{"text":606,"config":607},"Diversity, inclusion and belonging (DIB)",{"href":608,"dataGaName":609,"dataGaLocation":461},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":611},{"href":338,"dataGaName":339,"dataGaLocation":461},{"text":346,"config":613},{"href":348,"dataGaName":349,"dataGaLocation":461},{"text":351,"config":615},{"href":353,"dataGaName":354,"dataGaLocation":461},{"text":617,"config":618},"Modern Slavery Transparency Statement",{"href":619,"dataGaName":620,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Contact Us",[624,627,629,631,636,641,646],{"text":625,"config":626},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":461},{"text":365,"config":628},{"href":367,"dataGaName":368,"dataGaLocation":461},{"text":370,"config":630},{"href":372,"dataGaName":373,"dataGaLocation":461},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":637,"config":638},"Terms of use",{"href":639,"dataGaName":640,"dataGaLocation":461},"/terms/","terms of use",{"text":642,"config":643},"Privacy statement",{"href":644,"dataGaName":645,"dataGaLocation":461},"/privacy/","privacy statement",{"text":647,"config":648},"Cookie preferences",{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":461},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":461},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":664,"featuredPost":1135,"totalPagesCount":1155,"initialPosts":1156},[665,690,715,736,757,780,800,820,840,863,882,904,926,947,966,987,1010,1030,1051,1071,1093,1114],{"_path":666,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":675,"config":683,"_id":686,"_type":13,"title":687,"_source":15,"_file":688,"_stem":689,"_extension":18},"/en-us/blog/ceo-shadow-impressions-takeaways",{"title":668,"description":669,"ogTitle":668,"ogDescription":669,"noIndex":6,"ogImage":670,"ogUrl":671,"ogSiteName":672,"ogType":673,"canonicalUrls":671,"schema":674},"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","https://about.gitlab.com","article","\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":668,"description":669,"authors":676,"heroImage":670,"date":678,"body":679,"category":680,"tags":681},[677],"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](https://handbook.gitlab.com/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",[9,682],"features",{"slug":684,"featured":6,"template":685},"ceo-shadow-impressions-takeaways","BlogPost","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":691,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":692,"content":698,"config":709,"_id":711,"_type":13,"title":712,"_source":15,"_file":713,"_stem":714,"_extension":18},"/en-us/blog/forrester-tei",{"title":693,"description":694,"ogTitle":693,"ogDescription":694,"noIndex":6,"ogImage":695,"ogUrl":696,"ogSiteName":672,"ogType":673,"canonicalUrls":696,"schema":697},"Estimate your GitLab ROI with Forrester's economic study","Now available: A new Forrester ROI study and calculator based on real value customers got from using GitLab for SCM, CI, and CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/forrester-tei","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Discover your GitLab return on investment with the Forrester Total Economic Impact™ Study and Estimator\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Colin Fletcher\"}],\n        \"datePublished\": \"2020-07-29\",\n      }",{"title":699,"description":694,"authors":700,"heroImage":695,"date":702,"body":703,"category":704,"tags":705},"Discover your GitLab return on investment with the Forrester Total Economic Impact™ Study and Estimator",[701],"Colin Fletcher","2020-07-29","\n\nWe consistently hear from the global GitLab family (our community, customers, and really anybody interested in GitLab) that they know from experience that GitLab helps them do the work they want to do, faster and better, and that it’s a valuable, even vital, part of their success. But they often have a difficult time describing the value GitLab delivers, especially in specific, quantified ways. We also regularly hear that the hardest part about quantifying \"value\" is knowing where and how to start. \n\n**Enter the Forrester Total Economic Impact™ (TEI) of GitLab: studying real customer experiences**\n \nSo to help everyone better understand the value proposition, GitLab commissioned Forrester Consulting to conduct a [Total Economic Impact™ (TEI) study](/resources/report-forrester-tei/) examining the potential return on investment (ROI) organizations may realize by using GitLab for version control & collaboration (VC&C)/SCM, [continuous integration (CI), and continuous delivery (CD)](/topics/ci-cd/) - all use cases that represent where many teams begin or expand their use of GitLab.  \n\nTo start, GitLab customers were independently interviewed by Forrester Consulting. The interview experiences and any other data collected was then used to create multiple models which in turn generated quantified results based on the combined experiences of all of the customers studied. The data collected, resulting models, and study itself were then reviewed independently by Forrester Research analysts. GitLab stakeholders were also interviewed as part of the data gathering and review process.  \n\n**Significant results and useful tools to discover your ROI**\n\nJust a sampling of the results realized by the composite organization over an analysis period of three years, based on GitLab customer experiences, yielded these potential, quantifiable benefits in the form of:  \n\n- An overall 407% return on investment (ROI) \n- Improved development and delivery efficiency \n  - Ex. 87% improved development and delivery efficiency (reduced time), resulting in over $23 million in savings \n- Revenue from increased number of releases \n  - Ex. 12x increase in the number of revenue generating application releases in a year, resulting in $12.3 million in additional revenue \n- Improved Code Quality \n  - Ex. 80% reduction in code defects, resulting in over $16.8 million in savings \n- Savings from reducing the number of tools in use \n  - Ex. $3.7 million in savings from using four fewer tools (with their associated costs) each year  \n\nNow these results, while impressive, are based on the experiences of the GitLab customers studied and as with all models, your own unique experience will vary. As such we encourage you to spend time looking over [the study](/resources/report-forrester-tei/) to better understand where the numbers came from and how they may or may not relate to your situation and what you are working to achieve.  \n\nTo help you take the next step of estimating your own potential results, we are thrilled to make available an [online estimator](https://tools.totaleconomicimpact.com/go/gitlab/devopsplatform/index.html) that is based on the TEI study’s models. Enter your own data and you'll get a customized version of the study.  \n\n**Couldn’t have done it without you**\n\nLastly, we want to offer our deepest thanks to the incredibly generous GitLab customers who were willing to share their experiences in this way. They helped all of us in our respective journeys. Thank you! \n\n**Get started today!** \n\n- [Download the Forrester Total Economic Impact™ Study commissioned By GitLab, June 2020](/resources/report-forrester-tei/)\n- \u003Ca href=\"https://tools.totaleconomicimpact.com/go/gitlab/devopsplatform/index.html\" target=\"_blank\">Fill out your info in the online estimator and get a custom report based on the TEI study data and models\u003C/a>\n","news",[108,706,707,704,9,708],"collaboration","DevOps","user stories",{"slug":710,"featured":6,"template":685},"forrester-tei","content:en-us:blog:forrester-tei.yml","Forrester Tei","en-us/blog/forrester-tei.yml","en-us/blog/forrester-tei",{"_path":716,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":730,"_id":732,"_type":13,"title":733,"_source":15,"_file":734,"_stem":735,"_extension":18},"/en-us/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms",{"title":718,"description":719,"ogTitle":718,"ogDescription":719,"noIndex":6,"ogImage":720,"ogUrl":721,"ogSiteName":672,"ogType":673,"canonicalUrls":721,"schema":722},"GitLab named Leader in The Forrester Wave Integrated Software Delivery Platforms 2023","The Forrester report recognized GitLab for its roadmap, which includes supply chain security, enhanced UI, granular security and compliance controls, and pipeline security.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682752/Blog/Hero%20Images/Forrestercoverimage.png","https://about.gitlab.com/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named Leader in The Forrester Wave Integrated Software Delivery Platforms 2023\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2023-06-06\",\n      }",{"title":718,"description":719,"authors":724,"heroImage":720,"date":726,"body":727,"category":728,"tags":729},[725],"GitLab","2023-06-06","\n\nDemand for a platform approach to software delivery is increasing as organizations realize the inefficiencies and costs of stitched-together solutions for software delivery, siloed visibility, broken feedback loops, and increased risk of cyberattacks. We recognized the value of the platform approach early on — and we believe that GitLab's single-application DevSecOps Platform is the best way for organizations to improve developer productivity, build high-performing teams, secure the software supply chain, and implement cloud transformations. \n\n## GitLab’s DevSecOps Platform recognized\n![Your image alt text](https://about.gitlab.com/images/blogimages/forresterwave2.png){: .shadow.small.left.wrap-text} In its evaluation, and in the first year of this report, Forrester has named GitLab as the only **Leader** in **The Forrester WaveTM: Integrated Software Delivery Platforms, Q2 2023**. The report evaluated 13 integrated software delivery platform (ISDP) vendors across 26 criteria based on current offering, strategy, and market presence. GitLab scored the highest possible in the criteria of platform-incorporated security tools test automation, roadmap, community, and pricing flexibility and transparency.\n\nWe are excited to see the market mature and recognize the value of an integrated software delivery platform — a strategy GitLab has followed from the start. Our DevSecOps platform is offered as a single application with a unified data store, increasing efficiency and collaboration and providing value unmatched by traditional vendors and complex toolchains. It provides essential automation needed by various teams in the software delivery lifecycle, along with security and governance needed by security professionals. We also integrate artificial intelligence (AI) throughout the SDLC by incorporating it into our comprehensive enterprise DevSecOps platform.\n\n> Download [The Forrester Wave: Integrated Software Delivery Platforms, Q2 2023 report](https://page.gitlab.com/forrester-wave-integrated-software-delivery-platforms-2023.html).\n\nRecognizing our leadership and continued innovation, the report emphasizes that GitLab “has led the industry towards consolidated ISDPs. GitLab's strategy includes an on-par vision to deliver an excellent developer experience without sacrificing security or compliance.... GitLab is great for enterprises wishing to consolidate their best-of-breed toolchain into one, high-performing ISDP.”\n\n> “GitLab is far ahead of its competitors and provides one product which offers an easy-to-set-up, easy-to-start product with all these capabilities integrated,” says **Daniel Widerin, Head of Software Delivery, Hilti**\n\n## Roadmap gets high scores\n\nThe Forrester report recognized GitLab for its roadmap and focus on community. “[GitLab’s] roadmap gets leading scores and includes enhanced supply chain security, enhanced UI, granular security and compliance controls, and pipeline security – all things enterprises need.”\n\nThe research firm added: “[GitLab’s] innovation is also good, going beyond traditional developers to include AI/ML engineering. GitLab is an open core product that not only invests heavily in the open source software (OSS) community but also enables its customers to contribute to the product, earning it high scores for community.”\n\nGitLab is trusted by more than 30 million users and more than 50% of Fortune 100 organizations. We will continue to focus on integrating transformative technologies into our DevSecOps Platform, such as AI, into all parts of the software delivery lifecycle, software supply chain security, and value stream analytics, to enable customers to accelerate and secure software development and delivery.\n\n> Download [The Forrester Wave: Integrated Software Delivery Platforms, Q2 2023 report](https://page.gitlab.com/forrester-wave-integrated-software-delivery-platforms-2023.html).\n\n","insights",[704,9,481],{"slug":731,"featured":6,"template":685},"gitlab-leader-forrester-wave-integrated-software-delivery-platforms","content:en-us:blog:gitlab-leader-forrester-wave-integrated-software-delivery-platforms.yml","Gitlab Leader Forrester Wave Integrated Software Delivery Platforms","en-us/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms.yml","en-us/blog/gitlab-leader-forrester-wave-integrated-software-delivery-platforms",{"_path":737,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":738,"content":744,"config":751,"_id":753,"_type":13,"title":754,"_source":15,"_file":755,"_stem":756,"_extension":18},"/en-us/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms",{"title":739,"description":740,"ogTitle":739,"ogDescription":740,"noIndex":6,"ogImage":741,"ogUrl":742,"ogSiteName":672,"ogType":673,"canonicalUrls":742,"schema":743},"GitLab named Leader in 2023 Gartner DevOps Platform Quadrant","In the first Gartner® Magic Quadrant™ for this category, GitLab is positioned highest on the Ability to Execute axis.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663830/Blog/Hero%20Images/gartner-report-blog-asset.jpg","https://about.gitlab.com/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named a Leader in the 2023 Gartner Magic Quadrant for DevOps Platforms\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2023-06-07\",\n      }",{"title":745,"description":740,"authors":746,"heroImage":741,"date":748,"body":749,"category":728,"tags":750},"GitLab named a Leader in the 2023 Gartner Magic Quadrant for DevOps Platforms",[747],"Ashley Kramer","2023-06-07","\nToday marks an important milestone for DevOps and for GitLab. \n\nGartner® recognized GitLab as a Leader in the 2023 Gartner® Magic Quadrant™ for DevOps Platforms – the first Magic Quadrant for the category – positioned highest on the Ability to Execute axis. According to Gartner, Leaders execute well against their current vision and are well-positioned for tomorrow. \n\nSince our founding, we have been focused on delivering the most comprehensive suite of solutions for every use case – and for every stakeholder - in developing and deploying software. These solutions come together as a comprehensive platform that eliminates point solution tool sprawl and a ‘Do it Yourself’ DevOps approach. GitLab brings together everyone involved in the software development lifecycles – development teams, security teams, operations teams – to collaborate together on the same platform. \n\nWe believe Gartner naming GitLab a Leader in the Magic Quadrant for DevOps Platforms is a recognition of our success in both creating a comprehensive software development and delivery platform, and our role in helping mature the DevOps Platform category so that it is ready for mainstream technology adoption. \n\n![2023 Gartner® Magic Quadrant™ for DevOps Platforms](https://about.gitlab.com/images/blogimages/gartnermqfigure1.png){: .shadow}\n\nGitLab’s goal is to help our customers deliver software faster. We do this by improving developer productivity, increasing operational efficiency, securing the software supply chain, and accelerating their digital transformation. Today, GitLab is the most comprehensive AI-powered DevSecOps platform. \n\n> Download the [2023 Gartner Magic Quadrant for DevOps Platforms](http://about.gitlab.com/gartner-magic-quadrant).\n\n### Reducing complexity and increasing operational efficiency \nWe focus on reducing production risks through automation. With a best-in-class CI/CD solution, GitLab empowers teams to build and test every change as well as create scalable and repeatable software delivery processes. Our platform eliminates the complexity of sprawling toolchains, preventing context switching, reducing cognitive load, improving developer satisfaction, and driving operational efficiencies across organizations. \n\n### Shifting left with embedded security \nGitLab helps organizations meet [the need for speed and security](/the-source/ai/velocity-with-guardrails-ai-automation/) throughout the software supply chain because security is embedded within the software development lifecycle rather than bolted on as an afterthought. GitLab enables teams to automate policy enforcement, compliance frameworks, and security testing, which frees up resources. We continue to innovate in security. In the last quarter alone, we’ve introduced capabilities that support centralized policy management; expand our compliance reports, controls, and dashboards; and support default [SLSA Level 3 attestations](/direction/supply-chain/#frameworks).\n\n### Driving action with insights and metrics \nGitLab helps customers understand and analyze every aspect of the software delivery process. We are innovating on [value stream management](/solutions/value-stream-management/) through a unified data store, [tracking of DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html), value stream dashboards, and value stream analytics – all designed to give stakeholders a unique and useful view into the end-to-end software delivery value stream. Organizations can now visualize and manage DevSecOps workflows – from ideation to delivery – to gain insight into how digital transformation and technology investments are delivering value and driving business results.\n\n### Embedding AI throughout the software development lifecycle\nGitLab is an [AI-powered DevSecOps platform](/solutions/ai/). We adopt a privacy-first approach, ensuring that organizations can be confident their intellectual property is safe within our infrastructure. We integrate AI throughout the software development lifecycle to improve cycle time, from code creation and testing to security and deployment.\n\n### Empowering innovation with open core \nGitLab is built on an open core model, enabling us to be on the leading edge of innovation. Every year, our customers and the community at-large contribute hundreds of new capabilities to our DevSecOps platform. Through our feedback issues and publicly available roadmaps, we continue to stay close to our community and invite everyone to help improve our platform. \n\nOn behalf of the GitLab team, we are honored to be named a Leader by Gartner in the 2023 Gartner Magic Quadrant for DevOps Platforms. We will continue to innovate every day to make DevSecOps even more effective for our customers and to achieve our mission to make it so [everyone can contribute](/company/mission/). \n\n> Download the [2023 Gartner Magic Quadrant for DevOps Platforms](http://about.gitlab.com/gartner-magic-quadrant).\n\n*Gartner, Magic Quadrant for DevOps Platforms, Manjunath Bhat, Thomas Murphy, Joachim Herschmann, Daniel Betts, Chris Saunderson, Hassan Ennaciri, Bill Holz, Peter Hyde, 05 June 2023* \n\n*GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.*\n\n*Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.*\n\n*This graphic was published by Gartner Inc. as part of a larger report and should be evaluated in the context of the entire document. The Gartner document is available upon request from Gartner B.V.*\n",[704,9,481],{"slug":752,"featured":6,"template":685},"gitlab-leader-gartner-magic-quadrant-devops-platforms","content:en-us:blog:gitlab-leader-gartner-magic-quadrant-devops-platforms.yml","Gitlab Leader Gartner Magic Quadrant Devops Platforms","en-us/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms.yml","en-us/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms",{"_path":758,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":759,"content":765,"config":774,"_id":776,"_type":13,"title":777,"_source":15,"_file":778,"_stem":779,"_extension":18},"/en-us/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"title":760,"description":761,"ogTitle":760,"ogDescription":761,"noIndex":6,"ogImage":762,"ogUrl":763,"ogSiteName":672,"ogType":673,"canonicalUrls":763,"schema":764},"GitLab named a Leader in 2024 Gartner Magic Quadrant for AI Code Assistants","In the first Gartner® Magic Quadrant™ for this category, GitLab is recognized for its ability to execute and completeness of vision in AI code assistant technology.","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/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named a Leader in 2024 Gartner Magic Quadrant for AI Code Assistants\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-08-22\",\n      }",{"title":760,"description":761,"authors":766,"heroImage":762,"date":768,"body":769,"category":770,"tags":771},[767],"Dave Steer","2024-08-22","We’re thrilled to announce that GitLab has been recognized as a Leader in the [Gartner® Magic Quadrant™ for AI Code Assistants](https://about.gitlab.com/gartner-mq-ai-code-assistants/) — the first-ever year of this category. We feel this is an important recognition and we believe it highlights our commitment to delivering AI-powered capabilities that accelerate software delivery, enhance security, and drive innovation for our customers. \n\nAI code assistants go beyond just code generation and completion. They're collaborative partners that boost developer efficiency by improving code quality and continuous learning. By automating routine tasks and providing intelligent suggestions, assistants like GitLab Duo — our suite of AI-powered features — free up developer time to focus on higher-level problem-solving. \n\n![Gartner MQ AI Code Assistants image](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675964/Blog/Content%20Images/AI_Code_Assistants_MQ_graphic__1_.png)\n\n> Download the [2024 Gartner® Magic Quadrant™ for AI Code Assistants report](https://about.gitlab.com/gartner-mq-ai-code-assistants/).\n\n## AI code assistants: Speed, security, and seamless integration\n\nAI code assistants are integral to organizations of all sizes, helping DevSecOps teams develop and deploy secure software faster. However, the true value of AI emerges when it’s integrated across the entire software development lifecycle. Unlike limited AI point solutions, which can lead to fragmented toolchains and data silos, GitLab’s comprehensive platform embeds AI from planning through production, offering holistic visibility and insights via metrics and dashboards.\n\n## The power of GitLab Duo\n\n[GitLab Duo](https://about.gitlab.com/gitlab-duo/) is a comprehensive toolbox of AI capabilities designed to improve the developer experience, shift security left in the development cycle, and strengthen collaboration across Dev, Sec, and Ops teams. Key features include: \n\n* Code Suggestions for code generation and code completion\n* Chat for context-aware, in-app assistance on code explanation, code refactoring, and test generation\n* Vulnerability Explanation to better understand vulnerabilities in code\n* Vulnerability Resolution to help mitigate found vulnerabilities\n* Root Cause Analysis to troubleshoot pipeline issues\n* AI Impact Analytics Dashboard to gain real-time insights and evaluate an organization's AI ROI\n\n## Maximizing ROI with AI \n\nBusiness and engineering leaders need visibility into how AI is being used across the software development lifecycle to assess the ROI of their technology investments. GitLab's [AI Impact Analytics Dashboard](https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) provides that visibility as well as metrics to gauge AI adoption rates, performance improvements, and more.\n\n## Flexibility, privacy, and transparency at the forefront\n\nGitLab customers looking to explore AI-powered capabilities can use GitLab Duo to leverage the power of AI securely across an IDE of choice or a remote development workspace right out of the box, with a flexible pricing structure and a 60-day free trial. Also, the [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/) provides full visibility into our governance and transparency practices. \n\nSoon, organizations will be able to [tailor their AI experience](https://about.gitlab.com/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/) to their strategic and regulatory requirements with model personalization and self-hosted model deployment. Model personalization will allow enterprises to customize GitLab Duo and tap into AI’s full potential in close alignment with their business goals, operational needs, and customer expectations. Self-hosted model deployment ensures that data does not leave an organization's secure environment, reducing the risk of breaches and ensuring compliance for highly regulated industries. \n\n## Leading the future of AI in DevSecOps\n\nGitLab is your partner in AI-driven software development. We equip teams with the tools to build, secure, and deploy software faster. Our commitment to innovation ensures you're always at the forefront of AI advancements. Stay tuned for exciting updates on our roadmap as we continue to revolutionize DevSecOps.\n\n> [Download the 2024 Gartner® Magic Quadrant™ for AI Code Assistants report](https://about.gitlab.com/gartner-mq-ai-code-assistants/).\n\n***Source: Gartner, Magic Quadrant for AI Code Assistants, Arun Batchu, Haritha Khandabattu, Philip Walsh, Matt Brasier, August 2024***\n\n***GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.***\n\n***Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only\nthose vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research\norganization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.***\n\n***This graphic was published by Gartner Inc. as part of a larger report and should be evaluated in the context of the entire document. The Gartner\ndocument is available upon request from Gartner B.V.***\n","ai-ml",[704,772,773,9],"AI/ML","DevSecOps",{"slug":775,"featured":90,"template":685},"gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","content:en-us:blog:gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","Gitlab Named A Leader In 2024 Gartner Magic Quadrant For Ai Code Assistants","en-us/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","en-us/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"_path":781,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":782,"content":788,"config":794,"_id":796,"_type":13,"title":797,"_source":15,"_file":798,"_stem":799,"_extension":18},"/en-us/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":783,"description":784,"ogTitle":783,"ogDescription":784,"noIndex":6,"ogImage":785,"ogUrl":786,"ogSiteName":672,"ogType":673,"canonicalUrls":786,"schema":787},"GitLab named 2024 Gartner DevOps Platforms Quadrant leader","GitLab is positioned highest in Ability to Execute and Completeness of Vision, which we believe is recognition of our customers’ success and our continued innovation in the DevOps category.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named a Leader in the 2024 Gartner Magic Quadrant for DevOps Platforms\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2024-09-05\",\n      }",{"title":789,"description":784,"authors":790,"heroImage":785,"date":791,"body":792,"category":704,"tags":793},"GitLab named a Leader in the 2024 Gartner Magic Quadrant for DevOps Platforms",[747],"2024-09-05","DevOps was originally just a concept, a methodology for delivering software faster by bringing traditionally disparate teams together. It was a response to all the issues caused by the separation of those who built software and those who deployed it.\n\nAt GitLab, we iterated on that concept: Instead of stitching together tools to create a complex DevOps toolchain, a [single DevOps platform](https://about.gitlab.com/platform/) would result in tighter collaboration, greater automation, and more scalable and standardized processes.\n\nWe believe that strategy, which focuses on our customers' success, was correct. In the second iteration of the [Gartner Magic Quadrant for DevOps Platforms](https://about.gitlab.com/gartner-magic-quadrant/), we are once again named a Leader by Gartner and this time, positioned highest on both axes: Ability to Execute and Completeness of Vision.\n\n![Gartner MQ for DevOps Platforms 2024 image](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> Download the [2024 Gartner® Magic Quadrant™ for DevOps Platforms report](https://about.gitlab.com/de-de/gartner-magic-quadrant/).\n\nToday’s software organizations must contend with increasing security threats, complex compliance requirements, and carefully adopting new technologies such as generative AI. This is in addition to simply delivering on their promises of scalable services and continued innovation to their own customers.\n\nGitLab helps our customers face these challenges and become leaders in their own industries. With our AI-powered DevSecOps platform, they are shifting security left, enabling visibility throughout the development lifecycle, and bringing together all the roles and responsibilities needed to deliver the software that powers our world.\n\n## Furthering the DevOps vision\n\nOur work here isn’t done. We will continue to innovate on the DevOps vision and advance our DevSecOps platform in two ways.\n\nFirst, we want to invite even more teams to collaborate on the same platform, with specific features for those involved in [Agile planning](https://about.gitlab.com/blog/categories/agile-planning/), [data science](https://about.gitlab.com/topics/devops/the-role-of-ai-in-devops/), and [observability and application monitoring](https://docs.gitlab.com/operations/observability/).\n\nSecond, we strive to make our platform adoption and deployment options even more flexible to meet our customers’ diverse needs. This includes investing in [GitLab Dedicated](https://about.gitlab.com/dedicated/), our single-tenant, hosted option, so companies in highly regulated industries can have the simplicity of SaaS and the power of all the latest features and capabilities, while adhering to the compliance needs of isolated infrastructure.\n\n## Helping organizations build secure software\n\nBeyond building a better collaboration platform for delivering software, one of the most important things we do at GitLab is help organizations build more secure and compliant software. Our vision here sets us apart, as GitLab integrates [security scanning](https://about.gitlab.com/solutions/security-compliance/) at the point of code commit, not when applications are ready for release. This helps teams catch vulnerabilities sooner, leading to faster release cycles. GitLab also makes compliance easy with policy guardrails and automatically generating [a software bill of materials](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/).\n\nWe know our customers face more security threats as their own software surface attack area increases. This is why, in the next 12 months, we plan to continue improving our SAST scanners, add additional policy controls, and build [an upcoming native secrets manager](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/).\n\n## Leading with AI throughout the SDLC\n\nOur vision is to also be a leader in AI – both in enabling our customers to build innovative software with AI, and also to do it with privacy-first AI technology. AI represents a generational leap forward with an incredible amount of opportunity when integrated throughout the software development lifecycle. As we innovate, we are doing so responsibly. We’ve heard our customers’ concerns loud and clear: They want [AI with guardrails](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/), [AI that’s transparent](https://about.gitlab.com/ai-transparency-center/), and AI that respects their code and intellectual property.\n\nWe are committed to building [GitLab Duo](https://about.gitlab.com/gitlab-duo/), a suite of AI-powered features for our DevSecOps platform that are all of these: comprehensive, privacy-first, and built to support the entire software development lifecycle.\n\nWe believe this commitment and our GitLab Duo features are why, recently, [Gartner® also named us a Leader in its first 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\nWe are honored by this recognition and see it as a sign to continue listening to you  –  our customers – because that is what drives our vision, product roadmap, and commitment in delivering the best DevSecOps platform.\n\n> Download the [2024 Gartner® Magic Quadrant™ for DevOps Platforms report](https://about.gitlab.com/gartner-magic-quadrant/).\n\n***Source: Gartner, Magic Quadrant for DevOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, August 2024***\n\n***GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a\nregistered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.***\n\n***Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.***\n\n***This graphic was published by Gartner Inc. as part of a larger report and should be evaluated in the context of the entire document. The Gartner document is available upon request from Gartner.***",[704,9,481,707,773],{"slug":795,"featured":90,"template":685},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","content:en-us:blog:gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","Gitlab Named A Leader In The 2024 Gartner Magic Quadrant For Devops","en-us/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","en-us/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"_path":801,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":802,"content":808,"config":814,"_id":816,"_type":13,"title":817,"_source":15,"_file":818,"_stem":819,"_extension":18},"/en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"title":803,"description":804,"ogTitle":803,"ogDescription":804,"noIndex":6,"ogImage":805,"ogUrl":806,"ogSiteName":672,"ogType":673,"canonicalUrls":806,"schema":807},"GitLab named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025","Forrester calls GitLab platform the \"most all-in-one of the all-in-one solutions,\" adding it \"suits enterprises looking to standardize with a single purchase.\"","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2025-06-02\",\n      }",{"title":803,"description":804,"authors":809,"heroImage":805,"date":810,"body":811,"category":812,"tags":813},[767],"2025-06-02","Choosing a DevSecOps platform is one of the biggest technology decisions enterprises make. That's why we are thrilled to be named a [**Leader in The Forrester Wave™: DevOps Platforms, Q2 2025**](https://about.gitlab.com/forrester-wave-devops-platform/), receiving the highest scores possible across the criteria our customers tell us they care about most, including day zero experience, developer tooling, build automation and CI, deployment automation, AI risk mitigation, AI infusion, directly incorporated security tools, and platform cohesion.\n\n***\"GitLab is the most all-in-one of the all-in-one solutions and suits enterprises looking to standardize with a single purchase.” -*** Forrester Wave™: DevOps Platforms, Q2 2025\n\nFor us, this recognition reflects what we've been hearing from customers: They need to deliver secure software faster, but existing solutions force them to compromise on speed, security, or simplicity. GitLab delivers all three. And with our [GitLab 18.0 release](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) in May, we’ve taken this a step further by [including AI-native GitLab Duo capabilities](https://about.gitlab.com/blog/gitlab-premium-with-duo/) — such as test generation, code suggestions, and code refactoring — directly in GitLab Premium and GitLab Ultimate at no additional cost.\n\n> [Access the report today!](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n![ Forrester Wave™: DevOps Platforms, Q2 2025 graphic ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## Staying at the forefront of AI transformation, with enterprise control\n\nDevSecOps is rapidly evolving, with AI at the forefront of that change. Unfortunately, many AI tools force a choice: cutting-edge capabilities or enterprise security. \n\nForrester scored GitLab a 5 – the highest on their scale – for both the **AI infusion** and **AI risk mitigation** criteria. We’re pleased to see our focus on building innovative AI capabilities that maintain security is being noticed by more than just our customers.\n\nThis dual strength shows up across our GitLab Duo AI offerings, including:\n\n* Duo Workflow (private beta): Autonomous AI agents that handle complex tasks across development, security, and operations — with enterprise-grade guardrails and audit trails.  \n* Agentic Chat: Contextual, conversational AI assistance for everything from code explanations to test creation — with IP protection and privacy controls built in.  \n* Code Suggestions: AI assistance that can predictively complete code blocks, define function logic, generate tests, and propose common code like regex patterns.  \n* AI-native Vulnerability Resolution: Find and fix vulnerabilities with auto explanation and auto-generated merge requests, ensuring a streamlined development process.\n\n## Doing more with less \n\nWe’ve heard loud and clear that DevSecOps teams don’t need more tools and integrations that help them with part of their software delivery lifecycle. They need a seamless, integrated developer experience that covers the entire SDLC.\n\nWe believe GitLab’s scores in the following criteria are validation of our customer-focused strategy:\n\n* **Day zero experience:** Forrester cited our “strong day zero experience,” noting that “everything is ready to run out-of-the-box,” supported by extensive migration tools and tutorials. \n* **Developer tooling:** Forrester pointed to [GitLab Duo with Amazon Q](https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), our agentic AI offering for AWS customers, as well as our cloud development environment, integrated developer platform, and wikis for documentation as examples.  \n* **Project planning and alignment:** Forrester noted our \"strong compliance center,\" and that we have tools to drive alignment top-down and bottom-up.  \n* **Pipeline security:** Forrester gave us the highest score possible in the pipeline security criterion.  \n* **Build automation and CI:** Forrester cited our build automation and CI with multistage build pipelines and strong self-hosted support.\n\n## Read the report\n\nFor us, being named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025 speaks to the breadth and depth of our platform’s capabilities, providing a single source of truth for the entire software development lifecycle. No more juggling multiple tools and integrations – GitLab provides a seamless, integrated experience that boosts productivity and reduces friction. We believe this placement reflects the hard work of our team, the many contributions from GitLab’s open source community, the invaluable feedback from our customers, and our dedication to shaping the future of software development.\n\n> #### [Access the report today!](https://about.gitlab.com/forrester-wave-devops-platform/)\n\n*Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read about Forrester’s objectivity [here](https://www.forrester.com/about-us/objectivity/).*","product",[9,812,704,481],{"slug":815,"featured":90,"template":685},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","content:en-us:blog:gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","Gitlab Named A Leader In The Forrester Wave Devops Platforms Q2 2025","en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","en-us/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"_path":821,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":822,"content":828,"config":834,"_id":836,"_type":13,"title":837,"_source":15,"_file":838,"_stem":839,"_extension":18},"/en-us/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"title":823,"description":824,"ogTitle":823,"ogDescription":824,"noIndex":6,"ogImage":825,"ogUrl":826,"ogSiteName":672,"ogType":673,"canonicalUrls":826,"schema":827},"GitLab Ultimate's total economic impact: 483% ROI over 3 years","A Forrester Consulting study of GitLab Ultimate finds that the DevSecOps platform enhanced security posture with 5x time saved on security-related activities.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Ultimate's total economic impact: 483% ROI over 3 years\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-11-13\",\n      }",{"title":823,"description":824,"authors":829,"heroImage":825,"date":830,"body":831,"category":704,"tags":832},[767],"2024-11-13","A powerful DevSecOps platform streamlines operations, prevents security vulnerabilities from disrupting (and costing) your business, increases productivity, and fosters a culture of innovation and collaboration. That's exactly what we built GitLab to do, and our Ultimate tier represents the full power of our platform. To see the real-world results, we commissioned Forrester Consulting to create a “Total Economic Impact™ of GitLab Ultimate” study. Here’s what we discovered at a glance. \n\nAccording to the study, for a composite organization based on interviewed customers, GitLab delivered:  \n\n* **Three-year ROI of 483%**  \n* **400% improvement in developer productivity**  \n* **15x faster time to first release\u003Csup>1\u003C/sup>**  \n* **5x time saved on security-related activities**\n\n**Overall, GitLab enables 50% more work with business value.** \n\nThe numbers tell a clear story: GitLab's platform transforms how teams work together. Whether you’re an application security lead tasked with improving the company’s security posture, a developer looking to deliver high-quality code faster, or a CTO looking for a scalable, secure, and flexible DevSecOps platform, this study (see full methodology below) shows that GitLab Ultimate delivers. Let’s break down the results.  \n\n> Download the full [2024 Forrester Consulting “Total Economic Impact of GitLab Ultimate” study](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n## **1\\. Three-year ROI of 483%**\n\n*“The big win for us was efficiency — both in administration and in overall operations. Now, everyone can work collaboratively, and we can easily automate our pipeline. I’m also able to move personnel around to complete different tasks more efficiently. Rather than needing to train on different tools across programs, now it’s just ‘learn GitLab,’ and they’re ready to begin working.”* - CTO and Senior Vice President, Defense industry\n\nThe study found that teams started seeing payback within six months of implementing GitLab Ultimate, primarily through improved efficiency. With a **483% ROI over three years**, organizations reduced their software toolchain costs by 25% and cut the time IT teams spent on administering complex toolchains by 75%. Beyond the cost savings, moving to a unified platform fundamentally improves how teams develop and deliver software.\n\n## **2\\. 400% improvement in productivity**\n\n*“When I have conversations about GitLab with our developers, they universally agree that it has increased productivity at our organization across teams and roles. We now have one platform that has functions that everyone can use.”* - Software architect, Energy/Research industry\n\nDevelopers thrive in environments where they can easily switch between tasks without losing momentum. According to the study, developers can reclaim up to 305 hours per year by using [testing automation](https://about.gitlab.com/topics/devops/devops-test-automation/) within GitLab to help them test more frequently and track and fix bugs faster, all within a single interface with no context switching. This streamlined workflow allows them to focus on coding rather than juggling multiple tools and processes.\n\nThe productivity gains extend to onboarding, too: new hires in the composite organization’s software development team ramped up to full productivity 75% faster (i.e., in 1.5 weeks instead of 1.5 months). The impact is clear: Everyone on the team can contribute meaningful work sooner. \n\n## **3\\. 15x faster time to first release**\n\n*“Our superpower is software. It’s measured in terms of velocity and the ability to get new capabilities into the hands of our customers. For that to remain our primary focus, it just made economic sense to \\[consolidate\\] onto a single platform.”* - CTO and Senior Vice President, Defense industry\n\nThe summary data from the customer interviews reveals that GitLab enables organizations to accelerate first production release by 15 times. This boost is achieved through faster project initiation, more frequent software releases, and a proactive approach to security that natively integrates security scans into the development process from the outset. Even with this increase in velocity, software quality, and security remain at the same high levels, thanks to developers' ability to fix issues early and quickly. \n\nWith [security built directly into the development process](https://about.gitlab.com/solutions/security-compliance/), developers can identify, prioritize, and remediate vulnerabilities without disrupting their flow. This unified approach to managing the entire software development lifecycle means teams can move faster without compromising on security.\n\n## **4\\. 5x time saved on security-related activities**\n\n*“Integrating security and quality scanners into the pipeline was a game changer for us. With more automation and less manual work, we’re seeing fewer failures, fewer problems, and faster progress.”* - Program Manager, Finance industry \n\nSecurity is top-of-mind for every organization, as development speeds up and threats keep evolving. GitLab saves security team members in the composite organization **78 hours per member per year** by automating recurring tasks like disaster recovery prep, auditing, and compliance checks. GitLab also improves visibility into software development processes, helping security and development teams work together more efficiently.  \n\nCybersecurity and software development teams at the composite organization **managed and mitigated security risks throughout the software development lifecycle with 81% less effort.** This is because GitLab enabled them to integrate security protocols and scans throughout all stages of the software development lifecycle, simplifying how they maintain stringent security standards. As security testing and remediation are built into pipelines, teams reduce average response times and the risk of issues reaching production. \n\n# **Experience DevSecOps in action**\n\nWith a 483% ROI, a rapid payback period, and countless success stories, GitLab is an invaluable tool for enterprises looking to transform their software development processes.\n\n> To explore how GitLab can benefit your organization, download the full [Forrester Consulting “Total Economic Impact of GitLab Ultimate” study today](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n**Methodology**  \n*For the study, Forrester interviewed four GitLab Ultimate customers across industries, including finance, defense, and research, and created a composite organization to represent the aggregated results of these interviews. The composite organization is expected to adopt GitLab Ultimate across all teams in a three-year period.*\n\n*The composite organization is a $5 billion company with 5,000 employees, with 40% involved in software delivery and 50% of annual revenue driven by software development. Their goals are to consolidate multiple tools into a single, integrated platform, enhance developer productivity, ensure compliance with industry regulations and internal policies, and strengthen security throughout the development lifecycle.*\n\n*1. Based on summary data from customer interviews; not applicable to the composite organization results.*",[481,9,704,833],"security",{"slug":835,"featured":90,"template":685},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years","content:en-us:blog:gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","Gitlab Ultimates Total Economic Impact 483 Roi Over 3 Years","en-us/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","en-us/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"_path":841,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":842,"content":848,"config":857,"_id":859,"_type":13,"title":860,"_source":15,"_file":861,"_stem":862,"_extension":18},"/en-us/blog/gitlab-ux-2020-year-in-review",{"title":843,"description":844,"ogTitle":843,"ogDescription":844,"noIndex":6,"ogImage":845,"ogUrl":846,"ogSiteName":672,"ogType":673,"canonicalUrls":846,"schema":847},"GitLab UX 2020 Year in Review","2020 was a difficult but productive year. Let's take a look back.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/gitlab-ux-2020-year-in-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab UX 2020 Year in Review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2020-11-20\",\n      }",{"title":843,"description":844,"authors":849,"heroImage":845,"date":851,"body":852,"category":812,"tags":853},[850],"Christie Lenneville","2020-11-20","\nA global pandemic and broad social unrest have made this year difficult for everyone. When times are as tough as 2020 has proven to be, it's easy to focus on the negative and forget about the many good things that happened along the way. But our product designers, user researchers, and technical writers spend every day doing great work, and we can't let that slip by unnoticed. \n\nIn this post, I want to be intentional about celebrating our successes during a year when many of us wanted to just curl up under a comfy blanket and wait for the turmoil to pass. So, let's take a moment to reflect on some of the things we can feel really proud to have achieved.\n\n## Usability is now a key consideration in our category maturity model\n\nHistorically, we rated the [maturity](https://about.gitlab.com/direction/maturity/) of our product areas fairly subjectively and based almost entirely on feature availability. This year, that changed when we introduced [Category Maturity Scorecards](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) that are based on user research. Now, we start by considering the Job to be Done (JTBD) that our users need to accomplish, and we gather user feedback to rate the entire experience -- not just functionality, but usability, too. \n\nWe've learned some amazing things through this new approach, and those learnings have enabled us to make [valuable recommendations](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=cm-scorecard-rec) to improve our product experience in areas like Code Review, Logging, and Issue Management. We have several additional scorecard initiatives underway, which means that our focus on creating an exceptional experience will only continue to grow. \n\nSo often, UX departments complain that they have to fight for executives to acknowledge the importance of usability on business outcomes. In this case, refining category maturity started as an idea from [Sid](https://gitlab.com/sytses), our CEO. This is honestly amazing! It's the kind of user-centered focus that UX teams get really excited about.\n\nAs the person who leads UX at GitLab, it was awesome for me to watch our cross-functional team immediately get on board. Because measuring product maturity isn't an industry standard, through our value of [Iteration](https://handbook.gitlab.com/handbook/values/#iteration) it took us some time (and a false start) to determine the right approach. Fortunately, Product leadership was both enthusiastic and patient, UX Researchers were persistent in taking feedback and making methodological refinements, and Product Designers were courageous in trying something they've never done before. Even better: Technical Writing has been involved, too, as we've identified documentation improvements that will refine our product maturity. \n\nThis was truly a team effort, and I appreciate everyone who participated. 🤝\n\n## Our design system evolved from an idea into reality\n\nWhen I joined GitLab in early 2019, our design system, [Pajamas](https://design.gitlab.com/), was a scrappy project that the design team was working hard to get off the ground. We had designed a set of 28 single-source-of-truth components and were working hard to build them into [GitLab UI](https://gitlab.com/gitlab-org/gitlab-ui), our Vue-based component library.\nWe now have a robust design library that's implemented in Figma, and a large collection of SSOT Vue components are available to use in the product, too. Even more exciting: We're just finishing with implementing our 8 most impactful components across the entire product UI (buttons, alerts, dropdowns, modals, tabs, popovers, and tooltips), which will result in better performance and consistency when we're done. (We're so close!)\n\nMost amazing to me was watching product designers and technical writers jump in to do much of this component migration work themselves. This was no small feat, because frontend development is not something that many of us are deeply skilled at. But, apparently we're both tenacious and brave, because we did the work anyway (with lots of help from our Frontend Engineers and the awesome documentation that our UX Foundations team created). In the process, we've gotten to know both our product features (which are complex) and our code base (which is also complex) even better, which makes us more effective in our day-to-day jobs.\n\nSpeaking of our UX Foundations team, this is another related success. At the beginning of 2020, we got the budgetary support to create a team that is dedicated solely to maintaining our design system and tooling. The team may be small, but its impact certainly isn't. They've already made some big improvements to things like:\n\n* **Improving tooling for designers:** The move to Figma allows for greater collaboration, as well as community contributions. Sketch is only available on Mac platforms and there are no real-time collaboration features. Figma allows us to provide a UI Kit that is available across platforms, while being available for community contributors to use for free. It also promotes collaboration through its use of real-time editing capabilities and version history. We were able to streamline developer handoff by simply linking to the design file, reducing the need for additional plugins such as Sketch Measure.\n* **Making our color palette consistent and accessible:** We addressed color contrast for accessibility and normalized the palette across hues, so that we can better systematize variable use throughout the UI.\n* **Improving consistency in our icons:** With the creation of our own [SVG Library](http://gitlab-org.gitlab.io/gitlab-svgs/), we've been working to [deprecate our use of Font Awesome](https://gitlab.com/groups/gitlab-org/-/epics/2331) throughout the year. With the help of the Frontend department, we've closed out 156 out of 168 issues related to this effort.\n* **Moving towards more accessible workflows:** Near the end of the year, we've started focusing more on building accessibility standards into our workflows. We are currently auditing and updating our [voluntary product accessibility template](https://design.gitlab.com/accessibility/vpat), as well as [incorporating accessibility audit guides](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2158) into Pajamas.\n\n## Actionable insights\n\nUser research is so incredibly valuable... when you take action on it. But it can be a challenge for research teams to condense their powerful findings into small but compelling insights and then track those insights to determine whether they actually make it into the product.\n\nIn the second half of this year, our user research team made two big strides in this area. First, we started using [Dovetail](https://dovetailapp.com/) to help us more easily analyze research data to find meangingful insights and share it collaboratively with Product Managers and Product Designers (and anyone else who may be interested). But, they took this a step farther by also beginning to [track actionable insights](https://about.gitlab.com/handbook/product/ux/performance-indicators/#actionable-insights) as a performance indicator.\n\nThe considerable effort it took to get both of these programs in place will be worth it as we watch our research efforts result in an even better product.\n\n## Beautifying our docs\n\nComplex products like GitLab require high-quality documentation. Some things you just can't (and shouldn't) communicate through the UI, so users rely on great docs to get their daily jobs done.\n\nOur Technical Writing team (many of whom have been with GitLab less than a year) worked hard to improve our docs site during 2020, including:\n\n- Several UX research projects to discover - and fix! - problems users encounter when using the docs site.\n- A \"Beautification\" effort that focused on an updated visual design. Our 2020 GitLab Contribute event included many rapid improvements to the docs site, and we made many more afterward. (Did you notice?)\n- Ongoing content improvements, including making our docs more consistent, findable, detailed, and easier to read.\n- Adding (a lot of) metadata information to product docs to help connect content contributors with Technical Writers.\n- Coding innovations for automation, such as grammar checking with Vale, a linter, to automatically catch errors before they’re merged.\n\nWe’ve also completed work on a Docs Strategy roadmap to drive even more improvements in the upcoming months.  \n\n## And so much more...\n\n* GitLab Design Talks: In this fun video series, watch designers, technical writers, researchers, and product managers talk about [Iteration](https://www.youtube.com/playlist?list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o) and [Collaboration](https://www.youtube.com/playlist?list=PL05JrBw4t0KrER807JktsL-addVZa4N0-) at GitLab. (Special thanks to host [Nick Post](https://gitlab.com/npost)!)\n* UX Showcase: See [100+ videos](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz) highlighting exciting UX work happening across GitLab. I learn something new everytime I watch one of these.\n* Blog posts: Read about a variety of topics we were thinking about in 2020, including:\n    * [Designing in an all-remote company](https://about.gitlab.com/blog/designing-in-an-all-remote-company/)\n    * [Running an asynchronous sketching workshop for UX](https://about.gitlab.com/blog/async-sketching/)\n    * [Synchronous collaboration as a remote designer at GitLab](https://about.gitlab.com/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab/)\n    * [A tale of two file editors](https://about.gitlab.com/blog/a-tale-of-two-editors/)\n    * [How holistic UX design increased GitLab.com free trial signups](https://about.gitlab.com/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups/)\n    * [Improving iteration and collaboration with user stories](https://about.gitlab.com/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool/)\n    * [Designing incident management from scratch](https://about.gitlab.com/blog/designing-alerts-and-incidents/) \n    * [Why GitLab is the right design collaboration tool for the entire team ](https://about.gitlab.com/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team/)\n\nAgain, the GitLab UX team does amazing work every single day, and there is no way to capture all of that effort in a single blog post. As this year wraps up, I hope you personally take time to think about your own successes and the impact they had on our fast-moving company. \n\nI also hope you know that we value every one of you. You are appreciated. 💜\n\n{::options parse_block_html=\"true\" /}\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>One more thing...\u003C/strong>\u003C/p>\n\u003Cdiv class=\"panel-body\">\n\n\u003Cp>The final 2020 highlight I wanted to ensure is here was Christie Lenneville's own promotion to be GitLab's first \u003Cstrong>Vice President of User Experience (UX)\u003C/strong>. I knew that as both the author of this article, and as a humble (and great) leader she'd be hesitant to add this herself. But it's not only a recognition of her achievements and her potential. VP-level leadership of UX at GitLab should \u003Ci>also\u003C/i> be a signal of how important UX is to our organization and to our community. And it should indicate that usability is an important differentiator for GitLab, and a critical part of our company's strategy. Congratulations again, Christie!\u003C/p>\n\n— Eric Johnson, Chief Technology Officer\n\n\u003C/div>\n\u003C/div>\n\n{::options parse_block_html=\"false\" /}\n",[854,855,856,9],"UX","design","inside GitLab",{"slug":858,"featured":6,"template":685},"gitlab-ux-2020-year-in-review","content:en-us:blog:gitlab-ux-2020-year-in-review.yml","Gitlab Ux 2020 Year In Review","en-us/blog/gitlab-ux-2020-year-in-review.yml","en-us/blog/gitlab-ux-2020-year-in-review",{"_path":864,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":865,"content":870,"config":876,"_id":878,"_type":13,"title":879,"_source":15,"_file":880,"_stem":881,"_extension":18},"/en-us/blog/how-non-engineers-experience-gitlab",{"title":866,"description":867,"ogTitle":866,"ogDescription":867,"noIndex":6,"ogImage":845,"ogUrl":868,"ogSiteName":672,"ogType":673,"canonicalUrls":868,"schema":869},"Uncovering the diverse needs of non-engineering GitLab users","This post describes how the System Usability Scale (SUS) uncovered opportunities to improve the GitLab user experience for non-engineering users.","https://about.gitlab.com/blog/how-non-engineers-experience-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Uncovering the diverse needs of non-engineering GitLab users\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Huang\"}],\n        \"datePublished\": \"2020-10-26\",\n      }",{"title":866,"description":867,"authors":871,"heroImage":845,"date":873,"body":874,"category":680,"tags":875},[872],"Erica Huang","2020-10-26","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nI discovered UX research when I was looking for my next opportunity early this year as a researcher. The field's initial impression intrigued me, so I spent the following weeks learning from online courses, books, and other UX researchers. I started networking and asking for informational interviews. One particular conversation with [Katherine Okpara](https://gitlab.com/katokpara), UX Researcher at GitLab, led to a capstone project. We discussed the System Usability Scale (SUS) survey that is run quarterly at GitLab and uncovered an opportunity to better the user experiences for GitLab users in non-engineering roles.\n\n### Understanding the problem\nAfter taking a closer look at the trends and themes from the survey data, I learned that many non-engineer GitLab users are having difficulties working in GitLab. Most feedback came from users in product management, product design, academic research, and executive leadership.\n\nBased on the SUS feedback, I hypothesized that non-engineer GitLab users take longer to learn how to use the tools in GitLab. They may be overwhelmed by the many features of GitLab and have less experience with competitor tools.\n\n> With all the Auto- and advanced DevOps features creeping in constantly, it becomes harder to use Gitlab as a simple git repository system with issues/MR/wiki/simple CI for small non-DevOps teams…\n\nMany engineers expressed their frustrations with persuading or teaching their non-engineer colleagues to use GitLab.\n\n> I've been using GitLab for more than four years, so it's obvious and intuitive to me, but I am finding coworkers new to GitLab are increasingly unable to figure out some of the features on their own. As a specific example, we had someone propose to use a different code review tool, but when I showed them how to do a side-by-side diff and view the file tree, they were OK with it. These features are obvious to me as I've watched them get added over time, but I think the cues for them may be too subtle to new users.\n\nAfter considering these challenges, I believed that non-engineer users would benefit from a tailored onboarding experience.\n\n### Defining goals and objectives\n\nThrough this project, my goal was to understand these users' needs and pain points and identify ways to improve their user experience with GitLab, especially during the onboarding process. I set out to answer these questions:\n- What are the areas of GitLab particularly challenging for non-engineer users?\n- How long does it currently take non-engineer users to get comfortable with GitLab?\n- What do users need to learn during onboarding to use GitLab more easily?\n\n### Conducting interviews with GitLab users\nTo get a deeper understanding of the user experiences, I wanted to interview diverse groups of roles and get as many sides of the story possible. I started close to home and spoke with GitLab employees who use GitLab every day for work.\nFrom this set of interviews, I learned that:\n- The majority of the participants expressed frustration with using the Search function.\n- The majority of the participants utilized other tools such as Figma and Google Docs to complete their work.\n\nThe next step was to conduct interviews with external GitLab users to ensure that I was forming a balanced perspective. I recruited participants by sending a screener to the GitLab First Look research panel and experimented with recruiting outside sources such as Reddit and LinkedIn.\n- All of the participants proposed the need for a better workflow\n- Some participants would like a more robust approval system that easily tracks the project and its members.\n\n### Leveraging secondary research\nDue to recruiting constraints, I could not interview as many external users as needed to gain a full picture of their experiences. To conclude everything I learned so far, I decided to look into data from previous GitLab research projects and analyze findings according to the themes observed in each set of data.\nFrom this secondary research, I learned that needs of non-engineer GitLab users were diverse depending on their specific roles:\n- Many researchers expressed that they want the ability to reorganize and customize their GitLab UI.\n- Executives said that the page layouts and overall structure are too complex and affect how they navigate the site.\n- Many product managers expressed that GitLab features are inefficient and incomplete for task management and tracking.\n- Many non-engineer GitLab users want a documentation feature separate from Wiki.\n\n### Synthesizing findings from interview and survey data\nOverall, many non-engineer GitLab users suggested improved onboarding and better help documentation to help them get used to new features. These users are overwhelmed by GitLab features and want to customize the feature menu they see.\n\nI also saw a trend of users having trouble finding what they need from using the search function. Additionally, these users are more likely to supplement missing features with other services (i.e., Jira, Trello, Google Docs, MURAL, Figma).\n\n### What's next?\nI now have a better idea of the challenges and needs of diverse groups of people who use GitLab. To invest in critical areas that would improve the GitLab experience for non-engineers, I recommend the following next steps:\n- Stakeholder Interviews: Present findings to the stakeholder and get their perspectives. Understand whether the research insights are consistent with business needs and outline potential deliverables.\n- Usability Test: Learn about the users' behaviors in action. How are non-engineering users navigating between features? Where do they experience challenges, and where do they experience delight?\n- A/B Testing: Compare the current UI design to a design iteration that results from the findings.\n\n### What I learned\nUnfortunately, research projects don't always go as planned, so researchers will need to be adaptable. Adequate documentation will allow researchers to revisit past projects to collect secondary research for instances like these. It will also make it easier for stakeholders to access research projects without going through researchers each time.\n\n### About the guest author\nErica's background is in academic research and psychology. Her curiosity about human behavior and emotions steered her in the direction of research. Her favorite ways of learning are through her own experience and from listening to other people's stories.\n",[854,9],{"slug":877,"featured":6,"template":685},"how-non-engineers-experience-gitlab","content:en-us:blog:how-non-engineers-experience-gitlab.yml","How Non Engineers Experience Gitlab","en-us/blog/how-non-engineers-experience-gitlab.yml","en-us/blog/how-non-engineers-experience-gitlab",{"_path":883,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":884,"content":890,"config":898,"_id":900,"_type":13,"title":901,"_source":15,"_file":902,"_stem":903,"_extension":18},"/en-us/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics",{"title":885,"description":886,"ogTitle":885,"ogDescription":886,"noIndex":6,"ogImage":887,"ogUrl":888,"ogSiteName":672,"ogType":673,"canonicalUrls":888,"schema":889},"GitLab Runner Fleet dashboard improved through user research","Learn how GitLab user research drives the product development process when enabling more runner fleet features.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666543/Blog/Hero%20Images/lightvisibility.png","https://about.gitlab.com/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How user research transformed GitLab Runner Fleet dashboard visibility and metrics\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gina Doyle\"}],\n        \"datePublished\": \"2023-11-07\",\n      }",{"title":891,"description":886,"authors":892,"heroImage":887,"date":894,"body":895,"category":896,"tags":897},"How user research transformed GitLab Runner Fleet dashboard visibility and metrics",[893],"Gina Doyle","2023-11-07","\nContinuous integration and continuous deployment (CI/CD) are a crucial part of the product development workflow. Companies depend on CI/CD to get new software features, bug fixes, and improvements out the door quickly. At GitLab, runners are at the core of CI/CD and are needed to build, test, and deploy code. [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) is the open source project that is used to run CI/CD jobs and send the results back to GitLab. However, since GitLab's early years, GitLab Runner has been code-centric with limited UI capabilities. We recently embarked on a journey to change that – follow along to see how we gathered user input and made desired improvements to the visibility and metrics of the GitLab Runner Fleet dashboard.\n\n## Managing runners\nAs GitLab scaled as a company, so did the number of GitLab users with complex and evolving use cases. In the past five years, we have seen a radical increase in the need for a best-in-class experience when managing a large number of self-managed runners. This need has led us to put more time and focus into improving how GitLab manages runners and how it supports users in making decisions quickly and effectively.\n\nTo that end, we’ve been making incremental changes to the runner fleet management experience, including improving the general usability of admin and group runner pages, providing more data around runners such as jobs run and status checks, and improving the runner creation process so it’s more secure and easier to follow. By doing this, we built a better underlying system so we could add new features easily.\n\nHowever, runner admins and platform engineers shared this recurring problem with us: \n- It is difficult to get an at-a-glance view of my fleet of runners, including how they are performing (how fast they pick up jobs, which ones are running the most jobs, etc.) and what issues (if any) are present that need to be fixed. \n\nIn addition to this problem, the GitLab Runner Fleet team was also running into issues with the performance of runner pages and with scalability when trying to add new features. This was a perfect opportunity to learn more about the problem users were facing and to innovate to extend our runner offering.\n\n## Gathering insights and exploring proposals\nTo fully understand the problem at hand and help make the requirements more clear, we carried out [problem validation](https://about.gitlab.com/handbook/product/ux/ux-research/problem-validation-and-methods/) research. We held [moderated in-depth interviews](https://www.usability.gov/how-to-and-tools/methods/individual-interviews.html) and sifted through much of our existing data from previous interviews. As we gained confidence in our understanding of the problem, we created a first iteration of the design to be tested with users through [moderated usability testing](https://about.gitlab.com/handbook/product/ux/ux-research/usability-testing/#different-types-of-usability-testing), which would [determine whether the solution really did solve the problem](https://about.gitlab.com/handbook/product/ux/ux-research/solution-validation-and-methods/).\n\nThis first design proposal focused on: \n- a general overview of the fleet, broken down by types (instance, group, project runners) and status\n- visibility into runner system failures\n- a general concept of runner load - how many jobs are running at once out of how many possible jobs the runner can run?\n- how long it takes for runners to pick up jobs\n= a list of runner events (job failures, status changes, upgrades, etc.)\n\n![Initial design of dashboard 1](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/initial-design-1.png)\n\n\n![Initial design of dashboard 2](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/initial-design-2.png)\n\n\n## Testing the usability of iteration\nWe ran moderated usability testing sessions so we could measure user responses and satisfaction based on a set of consistent questions across multiple participants. We used a Figma prototype and had participants complete tasks that connected back to the problem we were solving. \n\nAn advantage of running moderated sessions compared to unmoderated sessions is that we could tailor our follow-up questions as required once participants completed a task or provided an answer. After completing these sessions, we summarized the data we received into the following key insights to create the MVC (minimal viable change) of the runner fleet dashboard:\n1. Runner failures/errors are crucial to identify problems (voted the most important feature on the dashboard).\n2. Online and offline runners matter the most in terms of status breakdowns for a fleet.\n3. Visibility into busy runners (tied for second most important feature on the dashboard) helps users see individual runner load.\n4. Wait time to pick up a job was tied for the second most important feature on the dashboard and seeing this over time with more configuration options can help identify where to make optimizations in the fleet.\n\nThere are many other features requested by participants that should be handled in follow-up iterations of the dashboard. See [this epic](https://gitlab.com/groups/gitlab-org/-/epics/10631) for more information.\n\n## Updating the designs\nOur next step was to update the designs to consider the research we ran.\n\n### Responding to feedback\n\n1) Wait times\n\n**What we heard:**\n- “Right now, there is very little information available as to how soon a CI build might start. Oftentimes, users are left wondering why jobs won’t run.” \n- “It's mostly reactive for us at this point anyway when, as you know, we get users reporting problems, we might want to go look at wait times here. And be able to dig down on those to see who's waiting...”\n\n**What we did:**\n- Added an in-depth visualization of wait times for all instance runners in the fleet in the past three hours and included percentiles to give users a true representation of the wait times. By providing the data over this interval, we enable runner admins to quickly get a sense of how their runners are performing and if there are any issues with the fleet that would cause jobs to stay in pending state.\n\n![Wait time graph](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/wait-time-graph.png)\n\n2) Runner loads\n\n**What we heard:**\n- “I have three build servers that are shared amongst many projects and in order for me to ensure each build server is properly set up, it's important for me to track builds by server. So, if one particular server is having issues, I need to be able to focus on that server.”\n\n**What we did:**\n- To start indicating some data on runner load, we’ve added a list of the top five busiest runners based on the number of running jobs they have at the moment, ranked from highest to lowest. This should help when analyzing concurrency settings and seeing if runners really need the capacity set for them.\n\n![Active runners](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/active-runners.png)\n\n3) Understanding of most recent failures\n\n**What we heard:**\n- “We actually have a dashboard on Datadog that gives us error counts and errors coming from the runners themselves. But you know, without a dashboard, we have no visibility on anything inside of GitLab, like queue lengths or wait times or anything like that.”\n\n- “Our setup is not perfect...some of the runners run on spot instances and can disappear, which means the background engine can die. You get this very strange error that the job failed because of something and we need to retry the job using a different runner.”\n\n**What we did:**\n- Created a list of most recent failures in the last hour for instance runners. Not only can you quickly navigate to the job log and details, but you’re also given a short summary of the error so you get insight into it immediately and can get on your way to fix it.\n\n![Runner failures](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/runner-failures.png)\n\n**The full dashboard:**\n\n![Full runner dashboard](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/full-dashboard.png)\n\n## What's next?\nThis first iteration of the dashboard is not the end. We have many iterations planned to improve the dashboard over the next year. To first get feedback on how it works for users, we will run an [Early Adopters Program](https://gitlab.com/groups/gitlab-org/-/epics/11180) for GitLab Ultimate self-managed users. We will work with teams to set up the feature on their instance and continuously ask for feedback once it is being used. This will also help us understand user satisfaction levels and help our team prioritize fixes and new features as we continue improving the experience.\n\n**Do you want to provide feedback now?** We would love to hear what you think! Please add your thoughts about the Fleet Dashboard to [this feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/421737). To learn more about how we built this dashboard, [watch this technical demo](https://www.youtube.com/watch?v=clyfLsss-vM) by Miguel Rincon, Pedro Pombeiro, and Vladimir Shushlin.\n","engineering",[108,9,855],{"slug":899,"featured":6,"template":685},"how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics","content:en-us:blog:how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics.yml","How We User Research Transformed Gitlab Runner Fleet Dashboard Visibility And Metrics","en-us/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics.yml","en-us/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics",{"_path":905,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":906,"content":912,"config":920,"_id":922,"_type":13,"title":923,"_source":15,"_file":924,"_stem":925,"_extension":18},"/en-us/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too",{"title":907,"description":908,"ogTitle":907,"ogDescription":908,"noIndex":6,"ogImage":909,"ogUrl":910,"ogSiteName":672,"ogType":673,"canonicalUrls":910,"schema":911},"Zoopla Boosts Deployments & Automation with DORA Metrics","GitLab customer Zoopla used the DORA metrics to boost production deployments from once a week to roughly 40 times a day. And that was only one of the performance improvements...","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665635/Blog/Hero%20Images/blog-performance-metrics.jpg","https://about.gitlab.com/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How Zoopla used DORA metrics to boost deployments, increase automation and more\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gustaw Fit of Zoopla\"}],\n        \"datePublished\": \"2022-01-24\",\n      }",{"title":913,"description":908,"authors":914,"heroImage":909,"date":916,"body":917,"category":728,"tags":918},"How Zoopla used DORA metrics to boost deployments, increase automation and more",[915],"Gustaw Fit of Zoopla","2022-01-24","\n\nAbout two years ago, Zoopla started wondering how we could measure the overall improvements in performance in the engineering department. We were in the early stages of a program of work called [Bedrock](https://zoopla.blog/posts/2021/project-bedrock-replatforming/). Bedrock was all about making engineering capability more efficient and flexible in responding to the business needs.\n\nAfter researching various options, we decided on the [DORA metrics](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance). They provided us with all the necessary insights to track our success, and benchmark ourselves against a definition of good.\n\n## What is DORA?\n\nDORA is the acronym for the DevOps Research and Assessment group: they’ve surveyed more than 50,000 technical professionals worldwide to better understand how the technical practices, cultural norms, and management approach affect organisational performance.\n\n(Take a dive into the [latest DORA Report](https://www.ciosummits.com/Online_Assets_Puppet_2016_State_of_DevOps_Report.pdf) and in the book that summarizes the findings:  [Accelerate](https://www.amazon.com/Accelerate-Building-Performing-Technology-Organizations/dp/B07BMBYHXL/ref=sr_1_2?crid=R1O9AH85U6PR&keywords=accelerate+book&qid=1643046474&sprefix=accelerate+book%2Caps%2C70&sr=8-2)).\n\n## What are the metrics Zoopla is using?\n\n- Production deploy frequency - Time between the first commit on a merge request to master and production deployment\n- Lead time - Number of successful production deployments / day\n- Mean Time To Recover - Time required from customer impact first started to removal of the customer impact\n- Change fail rate - For the primary application or service you work on, what percentage of changes to production or released to users result in degraded service (e.g., lead to service impairment or service outage) and subsequently require remediation (e.g., require a hotfix, rollback, fix forward, patch)\n- Time to onboard - Time required from the engineer who had joined the company, until their first commit is merged to master on a non-personal repository.\n\n\n## How do we understand the metrics?\n\n- Production deploy frequency - limiting amount of code going to production at once (limited batch size)\n- Lead time - reducing amount of blockers for developers\n- MTTR - improving speed of incident recovery\n- Change fail rate - improving quality focus\n- Time to onboard - how efficient is our onboarding process\n\nFollowing the rules of lean:\n\n- Value is only released to production, once it leaves the factory floor (production deploy frequency)\n- Optimize Work In Progress (lead time)\n- Invest in SRE/automation (mean time to recover)\n- Practice kaizen (change fail rate)\n- Have efficient knowledge sharing and work allocation processes (time to onboard)\n\n## How are we collecting the metrics?\n\nWe are using the following data sources:\n\n[GitLab](https://about.gitlab.com) for deploy frequency, lead time, change fail rate and time to onboard\n\n[Blameless](https://www.blameless.com) for mean time to recover (as recorded in incidents)\n\n[Jenkins](https://www.jenkins.io) for deploy frequency and change fail rate\n\nThe process is using APIs extensively. We also needed to come up with a standardised data schema to be able to meaningfully use the metrics. The raw data stored in the s3 bucket can be used in any visualization tool. For our own purposes we have decided to display them in a google spreadsheet. All of these required an extensive implementation effort. The whole flow is powered by modern Python.\n\nSome parts of our process are still not perfect. We are actively working to simplify the flows and standardize data sets.\n\n## How are the metrics used at Zoopla?\n\nThe dashboard is regularly reviewed by the senior engineering management. The metrics are on public display, and are discussed and reviewed in our monthly town hall meeting, and our fortnightly Ops Review. Each team is encouraged to reflect on the metrics as they plan their work, and consider improvements they could introduce.\n\nThe metrics also influence the decisions and prioritization. Just as importantly, they help us to transform our company culture.\n\nIn terms of improvements measured:\n\n- Production deployment frequency was improved from once in a week to multiple times per day (~40 deployments per day).\n- Lead time was improved from an average of 10 days to less than two days (with many projects being close to 2-4h on average).\n- Mean time to recover: we have not measured it before, the main benefit for us is understanding what we need to improve. We are currently in the area of 1-3h on average for sev-0 or sev-1 issues and 24h on average, when we include sev-2 issues.\n- Change failure rate was about 60% before we started, it is now oscillating between ~1-5%.\n- Time to onboard was over 20 days, and we have brought this down to around five days.\n\nThe main cultural changes were:\n\n- We have automated the majority of our deployment pipelines.\n- We have added a lot of automation to incident resolution, primarily by adding auto-scaling.\n- We have trained our teams in incident response, and introduced an on-call rota.\n- We have moved the bulk of our infrastructure management to a standardised Infrastructure as Code (mainly Terraform).\n- We have improved our onboarding process.\n- We have improved our alerting, and partnered with New Relic to reduce investigation effort.\n\nWe hold the ambition to join the elite performing group of organisations as defined by the State of DevOps report. Each day brings us closer to that goal.\n\n## What are our future plans?\n\nOn the technical side, we are working to improve automation of the metrics, to go away from our internal and bespoke metric collection model. We hope our partnership with New Relic will soon enable a much better solution.\n\nOn the DevOps/DORA culture side, we are providing regular talks and training to wider audiences (not only engineering), to establish DORA as a reference point in future product development. We are also making it a key point of our new consolidated engineering strategy.\n\nWe’ve found the DORA metrics helped us improve our software development and delivery processes. With these findings, organizations can make informed adjustments in their process workflows, automation, team composition, tools, and more. We recommend you try this in your organisation too.\n\nFurther reading:\n\n- [The Phonenix Project](https://www.amazon.com/The-Phoenix-Project-audiobook/dp/B00VATFAMI/ref=sr_1_1?crid=3U43AWAK4L6YI&keywords=The+Phoenix+project&qid=1643046949&sprefix=the+phoenix+project%2Caps%2C70&sr=8-1) by Gene Kim, Kevin Behr and George Spafford\n- [The Goal: A Process of Ongoing Improvement](https://www.amazon.com/The-Goal-audiobook/dp/B00IFGGDA2/ref=sr_1_1?crid=2EAKYMNBHT0B5&keywords=the+goal+by+eliyahu+goldratt&qid=1643047036&s=audible&sprefix=The+goal%2Caudible%2C125&sr=1-1) by Eliyahu Goldratt and Jeff Cox\n- [The Unicorn Project](https://www.amazon.com/The-Unicorn-Project-Gene-Kim-audiobook/dp/B0812C82T9/ref=sr_1_1?crid=2B0ENCYRNG2BO&keywords=the+unicorn+project&qid=1643047132&s=audible&sprefix=the+unicorn%2Caudible%2C76&sr=1-1) by Gene Kim et al\n",[707,919,9],"customers",{"slug":921,"featured":6,"template":685},"how-zoopla-uses-dora-metrics-and-your-team-can-too","content:en-us:blog:how-zoopla-uses-dora-metrics-and-your-team-can-too.yml","How Zoopla Uses Dora Metrics And Your Team Can Too","en-us/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too.yml","en-us/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too",{"_path":927,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":928,"content":934,"config":941,"_id":943,"_type":13,"title":944,"_source":15,"_file":945,"_stem":946,"_extension":18},"/en-us/blog/iterate-like-a-gitlab-designer",{"title":929,"description":930,"ogTitle":929,"ogDescription":930,"noIndex":6,"ogImage":931,"ogUrl":932,"ogSiteName":672,"ogType":673,"canonicalUrls":932,"schema":933},"Iterate Like a GitLab Designer","Think big, ship small, learn fast","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/iterate-like-a-gitlab-designer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Iterate Like a GitLab Designer\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-10-16\",\n      }",{"title":929,"description":930,"authors":935,"heroImage":931,"date":937,"body":938,"category":680,"tags":939},[936],"Holly Reynolds","2020-10-16","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAny GitLab team member can tell you that [iteration](https://handbook.gitlab.com/handbook/values/#iteration) is often the most challenging organizational value to practice. Designing and shipping the smallest thing possible can often feel like it goes against our desire to beautify, polish, and perfect.  \n\nThe major challenge is in scoping down the initial vision. Sometimes, we may have to cut scope so much that we do not feel we are shipping anything of value. We often feel a [low level of shame](https://handbook.gitlab.com/handbook/values/#low-level-of-shame) that it doesn't look complete. We sometimes worry that perhaps even a paying customer will feel this pain too.\n\nIn a [GitLab Unfiltered conversation](https://www.youtube.com/watch?v=0lhjzU-QZ2w&feature=youtu.be) about iteration between two GitLab product designers, they talk about our iteration value and some of the challenges teams experience while practicing it: \n\n_\"What we try to do differently than other companies is that we try to make something embarrassingly small. Sometimes I feel that we get trapped in that thought. We become too focused on minimal. Then we've gone past the point of being viable for our business or valuable for our users.\"_\n\nAt best, the goal of making a feature smaller can cause a low level of shame. And at worst, it can create tension on a team that worries about shipping an incomplete vision to customers. \n\nWhen we try to deliver an MVC (or [Minimal Viable Change](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc)), a challenging aspect is when the problem feels too large. Perhaps there is a clear [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions), but the amount of time and resources needed to accomplish it is too large. We ask ourselves: _\"What needs to be cut while still providing immediate value and paving the way for scalable improvements?\"_ We often address this question with our [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/), which includes steps to validate the problem or solution and test in advance to minimize the more significant unknowns.\n\nAnother challenge is keeping our eyes on the bigger picture while also creating MVC solutions. It's easy to focus on the trees we're trimming at the time, but this can cause erosion in the forest elsewhere if we cut them back too much. Collaboration amongst Product Designers and Product Managers in various stages is critical to ensuring we're not making choices that could have a negative ripple effect throughout the application.\n\nAs our team members phrase it, the solution to all of this is to _think big, ship small, and learn fast_.\n\n## Keeping MVCs as C's, not P's\n\nWe can balance smaller with viable if we define the [MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc). MVC (Minimal Viable Change) is not the same as MVP (Minimum Viable Product). Thousands of little changes make up a product, and there is often more than one right way to solve a problem. An MVC is a singular yet mighty change that takes a step in the right direction to improving the product for the user. \n\nA series of incremental, step-wise MVCs make a feature more complete. It can often take multiple releases to discern if this is the right direction. However, we can also learn more and at a faster pace along the way. The inverse would be to ship extensive features that take longer to build, which means we're less likely to learn quickly.\n\nAt GitLab, we currently release in a 1-month milestone cadence. That said, there are many opportunities to learn faster, and we employ a variety of methods to do so. Designers work with Product Managers (PMs) to incrementally de-risk feature ideas. We break solutions down into smaller experiments, all while considering the impact of these experiments both in the short and long term. Our approach requires both divergent and convergent thinking at any given time on an idea. We need to think big to know what small changes will make sense within the broader vision.\n\n## Think Big: Define the Vision\n\nThinking big helps us keep a high-level view of the overall product while exploring ways to learn from small, valuable features that we can ship quickly. \n\nSo, what does it look like to _Think Big_? We start with a known problem and examine how that problem impacts our users, the organization, and the product as a whole. The [GitLab product development flow](https://about.gitlab.com/handbook/product-development-flow/) helps us balance being reactive to known issues while proactively identifying UX improvements. Before we begin to generate solutions for a problem we hear about, we first must weigh this problem against all others in our backlog.\n\nThis process of determining what to work on first can be a bit tricky at times. However, some of the criteria we consider when we prioritize include:\n1. New product category work\n2. Determining the next [maturity state](https://about.gitlab.com/direction/maturity/) for a product category (e.g., _viable_ to _complete_)\n3. The envisioned feature is large or introduces a significant change to the product's UX\n4. Understanding if a JTBD is relevant to why customers buy or use the product\n5. When targeting a new user or buyer persona\n\nOnce we've determined what we want to address first, ideas enter a phase known as [Problem Validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation). When a problem is known, our ideas for a solution also become more focused. An important signal to watch for revolves around whether we have a shared language about the problem, who feels it, and if we have a collection of reasonably small solution proposals. \n\nProduct and UX Research may work together to run studies, user interviews, competitor analysis, and other research efforts within the problem validation phase. We also review data from previous studies surrounding the [category maturity](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) and [System Usability Score (SUS)](https://about.gitlab.com/handbook/product/ux/ux-resources/#system-usability-score) results.\n\nAs the conversational thread coalesces around a viable range of solutions, we know what to do next. At this point, the idea may move into our [Design phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design), where we create wireframes and prototypes.\n\n## Solution Evolution\n\nAt GitLab, nothing should ever happen in a silo. If we are to think big, we need to be sure that we are sharing and collaborating on our ideas with others in the organization and even the wider GitLab community. \n\nThe [Design phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design) is often a highly collaborative phase involving at the very least: Design, Product (for insight on business needs, strategy and priorities), and Engineering (to help determine the feasibility of possible solutions). Others involved may include Tech Writing, UX Research, Sales, Customer Success, the CEO, and GitLab community members.\n\nThis phase's challenge is not to let the conversation stall or the participants get into _analysis paralysis_. As the DRI (directly responsible individual) of this phase, the Designer often needs to select a path and move forward.\n\nLastly, the [GitLab Pajamas design system](https://design.gitlab.com/) is an excellent resource for providing a solid foundation for UI and design patterns. It reduces the time needed to think through solutions and create visual deliverables for those solutions. Again, thinking about the big picture of being consistent while exploring ways to move fast and ship small.\n\nOnce design solutions are in place, the idea can move into the [Solution Validation phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation) to test and validate the MVC with users. Suppose users' feedback proves that the solution is right - meaning, it aligns with the business needs, and it's feasible. In that case, we can move into the [Planning Breakdown phase](https://about.gitlab.com/handbook/product-development-flow/#build-phase-1-plan), where it is weighted and prioritized by engineers.\n\n\n## Ship Small: Build and Ship\n\nAn aspect of GitLab's value proposition revolves around helping teams release faster and at a _sustainable_ pace. Organizations will evolve their workflows to fit their context. Every process seeks to understand what customers need, deploy the solution, and learn. We utilize our product to its fullest extent to accelerate iterations that converge toward optimal solutions to real-world problems.\n\nWe strive in the [Design phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design) to both understand the big picture and define the smallest [MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) solution. We use tools like [Figma](https://www.figma.com/community/plugin/860845891704482356/GitLab) to create prototypes and other deliverables. With Figma, engineers can view coded aspects of the design, saving time in translating design expectations during design hand-off.\n\nDesign and Engineering review the proposed solution and collaborate to:\n*   Ensure the MVC is as small as possible in terms of both the frontend and backend.\n*   Identify impacts on other areas of the product. \n*   Discuss possible performance issues.\n*   Decide whether to implement new vs. existing patterns and UI elements.\n\nAdditional design iterations could occur if the idea is still too large to deliver within a single milestone.\n\n## Learn Fast: Measure and Learn\n\nThroughout the entire GitLab Product Development Flow, we're learning. We're not just uncovering what needs our users have. We're also learning about ways to improve our methods to make our process more efficient. Because we ship small, our learnings can and should happen quickly. We're always exploring ways to get feedback faster from our users and empathize with their needs. We also [dogfood](https://about.gitlab.com/handbook/engineering/development/principles/#dogfooding) our product, which helps us to experience and identify the same usability and performance pains as our users. \n\nFinally, we regularly:\n*   Have 1:1 conversations with our users\n*   Evaluate quantitative data\n*   Document and tag the qualitative feedback for future reference\n*   Take action on insights\n\n## Conclusion \n\nPractice and theory don't always align. Sometimes, we'll realize later that we could have made something smaller or better. Instead of charging ahead with the plan, we take a step back and make the idea smaller. The ultimate goal of iteration is to release the smallest change possible to learn from real-world usage.\n\nWe also embrace contributions from team members and the wider community. In the words of [Jeremy Elder](https://gitlab.com/jeldergl): \"[In the cycle of iteration, there are multiple on-ramps](https://www.youtube.com/watch?v=apQTxlqZeBA&feature=youtu.be&list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o&t=1278).\"\n\n\n## Explore further\n*   [GitLab design talks: Iteration](https://www.youtube.com/playlist?list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o)\n*   [Presenting an MVC solution](https://about.gitlab.com/handbook/product/ux/product-designer/index.html#present-an-mvc-solution)\n*   [Conduct a Job statement activity with the team](https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/)\n*   [Opportunity Canvas](https://about.gitlab.com/handbook/product-development-flow/#opportunity-canvas)\n*   [Improvement phase in the Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/#build-phase-4-improve)\n",[855,854,940,9,706],"UI",{"slug":942,"featured":6,"template":685},"iterate-like-a-gitlab-designer","content:en-us:blog:iterate-like-a-gitlab-designer.yml","Iterate Like A Gitlab Designer","en-us/blog/iterate-like-a-gitlab-designer.yml","en-us/blog/iterate-like-a-gitlab-designer",{"_path":948,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":949,"content":955,"config":961,"_id":963,"_type":13,"title":950,"_source":15,"_file":964,"_stem":965,"_extension":18},"/en-us/blog/jira-importer-research",{"title":950,"description":951,"ogTitle":950,"ogDescription":951,"noIndex":6,"ogImage":952,"ogUrl":953,"ogSiteName":672,"ogType":673,"canonicalUrls":953,"schema":954},"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":950,"description":951,"authors":956,"heroImage":952,"date":957,"body":958,"category":680,"tags":959},[936],"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://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) or a [DevOps Engineer](https://handbook.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",[682,855,854,960,9],"developer survey",{"slug":962,"featured":6,"template":685},"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":967,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":968,"content":974,"config":981,"_id":983,"_type":13,"title":984,"_source":15,"_file":985,"_stem":986,"_extension":18},"/en-us/blog/jobs-to-be-done-interviews",{"title":969,"description":970,"ogTitle":969,"ogDescription":970,"noIndex":6,"ogImage":971,"ogUrl":972,"ogSiteName":672,"ogType":673,"canonicalUrls":972,"schema":973},"How we use the Jobs-To-Be-Done Framework to rethink user workflow","We experimented with our methodology and this is what we learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670074/Blog/Hero%20Images/jobs-to-be-done.jpg","https://about.gitlab.com/blog/jobs-to-be-done-interviews","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we use the Jobs-To-Be-Done Framework to rethink user workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erika Feldman\"},{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2022-09-07\",\n      }",{"title":969,"description":970,"authors":975,"heroImage":971,"date":978,"body":979,"category":728,"tags":980},[976,977],"Erika Feldman","Veethika Mishra","2022-09-07","\n\nThe past few years exposed us to the heights of unpredictability, and a lot of time was spent on Zoom. The pandemic showed us that planning is not enough for an organization to survive in difficult times. Companies need to be flexible enough to innovate in accordance with altered workflows if they wish to sustain and support market use cases as they evolve. Innovating and iterating at the speed of DevOps requires designers and researchers to look at the user workflow differently, outside of the content of the UI. To understand our users and how their work has changed, we zoomed out our perspective by asking users their key tasks and goals at the Stage level - instead of presenting them with a UI to work within. \n\nAt GitLab, we use the Jobs-To-Be-Done ([JTBD](/handbook/product/ux/jobs-to-be-done/)) framework to always keep room for innovation in our approach to research and customer inquiry. We believe that our users do not purchase our product because of the features and capabilities we build into it, but for what it helps them accomplish in their workflows. To capture more macro-changes in user workflows through this research, we adjusted the level of the JTBD framework to focus on the entire code integration, verification, and deployment process.  \n\nWhen we are too focused on the features and solutions we work on day after day, our frame becomes myopic, our sense of progress becomes skewed, and [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) rears its head. Our product then reflects our organizational structure rather than the user's workflow. The JTBD framework helps us be more aware of opportunities in the competitive arena by allowing us to understand the goal of the products at a more fundamental level that can easily be missed by a superficial frame.   \n\n## Pipeline execution JTBDs\nThe [Pipeline Execution group](/handbook/engineering/development/ops/verify/pipeline-execution/) in GitLab is responsible for supporting the functionalities with respect to Continuous Integration use cases. GitLab [CI/CD](/topics/ci-cd/) offerings have come a long way over the years. This realization triggered us to start re-examining the vision we have for the Stage Group earlier this year. We wanted to make sure that we’re leaving no stone unturned. And what better place to start than revisiting our JTBDs?\n\n## Designing the research\nTo avoid cutting any corners, we decided to keep our confidence in the product and our biases aside and speak with users without talking to them about our UI. A privilege of working at GitLab is having a well-documented handbook that is a living and evolving single source of truth. We looked at the [documented process](/handbook/product/ux/jobs-to-be-done/mapping-jobs-to-be-done/) and, at the same time, made notes on our assumption around what might not have gone right the previous time we did this exercise. These are the areas we felt we could improve on:\n\n1. Making interviews more collaborative\n2. Documenting the findings without bias\n3. Helping participants tell us about the fundamental workflow level, and not at a utility level\n\n## The interview template\nWe co-created an interview deck with users to help us codify their workflows. After an introduction to the session to set them at ease, we showed them a relatively blank canvas with different stages of their workflow written on the top of the slide. We started with our GitLab Stages, falling into the Conway conunmdrum. At the end of our inquiry and co-creation of the deck templates that we use across participants, we had the following six steps: \n\n1. Define - How code is defined and how it will be integrated and verified\n1. Locate - How team members gets to know about Infrastructure-as-Code frameworks and how they should be used\n1. Execute - How the processes and frameworks are ultimately executed\n1. Monitor - How performance is monitored\n1. Modify  - How teams change existing processes or existing code\n1. Secure, Deploy, and Debrief - How teams securely release changes to production and learn from their most recent process\n\nSpeaking with users for this research activity didn't just help us identify new JTBDs, but also validate some of the [previously listed ones](/handbook/engineering/development/ops/verify/pipeline-execution/jtbd/). The same research also helped us identify opportunities related to learnability of the tool, post code-integration monitoring capabilities and discoverability of the code-verification practices set up by organization on GitLab for their teams.\n\nUsers are at the focal point of our decisons at GitLab and going forward we will continue to improve our research methods and communication practices to capture the insights in the purest form. \n\n",[9,854,812],{"slug":982,"featured":6,"template":685},"jobs-to-be-done-interviews","content:en-us:blog:jobs-to-be-done-interviews.yml","Jobs To Be Done Interviews","en-us/blog/jobs-to-be-done-interviews.yml","en-us/blog/jobs-to-be-done-interviews",{"_path":988,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":989,"content":995,"config":1004,"_id":1006,"_type":13,"title":1007,"_source":15,"_file":1008,"_stem":1009,"_extension":18},"/en-us/blog/lets-all-search",{"title":990,"description":991,"ogTitle":990,"ogDescription":991,"noIndex":6,"ogImage":992,"ogUrl":993,"ogSiteName":672,"ogType":673,"canonicalUrls":993,"schema":994},"Let's all search!","We spoke with you about our search tools. Now we've got some issues we'd like your help on.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679339/Blog/Hero%20Images/AdvancedSearch.png","https://about.gitlab.com/blog/lets-all-search","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Let's all search!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Will Leidheiser\"}],\n        \"datePublished\": \"2022-12-01\",\n      }",{"title":990,"description":991,"authors":996,"heroImage":992,"date":998,"body":999,"category":1000,"tags":1001},[997],"Will Leidheiser","2022-12-01","\n\nEarlier this year, our research team set out to learn how users search for GitLab content and to better understand their experience with our [global search](https://docs.gitlab.com/ee/user/search/) and [advanced search](https://docs.gitlab.com/ee/user/search/advanced_search.html) tools. We spoke with 12 GitLab users individually over the course of a four-week span to get their [feedback on our search capabilities](https://gitlab.com/groups/gitlab-org/-/epics/8193). \n\n![Getting feedback from GitLab users](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Talking_to_GitLab_users.png){: .shadow.medium.center}\nA researcher talking with GitLab users to gather their feedback.\n{: .note.text-center}\n\n## Research insights\n\nOur research identified that the discoverability of our search could be better. Some users had never tried out our search capabilities because they did not know we had a search bar inside of GitLab. The search bar [did not visually stand out](https://gitlab.com/groups/gitlab-org/-/epics/8275) to some GitLab users, so this led them to try other means (e.g., using their web browser URL history or using another external application) to find content. In addition, we learned that even long-time users of the GitLab search bar were [unaware of the kinds of content it could find](https://gitlab.com/groups/gitlab-org/-/epics/8274). As we encouraged users to try out the search tools for our study, they would uncover new information either through exposure or by reading our documentation.\n\nOur research helped the Global Search Product team at GitLab with future roadmap planning. Now, we need the support of our community to make iterative improvements to GitLab search tools. We have identified **two** actionable insight issues that you can contribute to directly to improve the search experience for all GitLab users. \n\n## Community contribution issues\n\n- In order to make the search bar stand out, we're proposing a change to [improve the contrast of the search bar](https://gitlab.com/gitlab-org/gitlab/-/issues/330925) in the GitLab navigation header. This change would greatly support the accessibility of our site and would assist users when looking for a way to search for content.\n\n![Update to improve the contrast of our search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Focus.png){: .shadow.medium.center}\nA visual mock-up of improved contrast for the GitLab search bar.\n{: .note.text-center} \n\n- Improve the search experience by [providing hints](https://gitlab.com/gitlab-org/gitlab/-/issues/364402) about the kinds of content that the GitLab search bar can find. This change would prompt users with different ideas of what they can do with the search bar, so they can learn about our functionality without having to read through documentation.\n\n![Hints in the search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Placeholder_Options.png){: .shadow.medium.center}\nSome examples of hints that would be shown in the GitLab search bar.\n{: .note.text-center}\n\n## Let's contribute\n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started) and [our development guide](/community/contribute/development/) and become an all-star contributor!\n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\n**Let's all contribute to GitLab's search!**\n","open-source",[1002,266,1003,9,854],"contributors","open source",{"slug":1005,"featured":6,"template":685},"lets-all-search","content:en-us:blog:lets-all-search.yml","Lets All Search","en-us/blog/lets-all-search.yml","en-us/blog/lets-all-search",{"_path":1011,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1012,"content":1018,"config":1024,"_id":1026,"_type":13,"title":1027,"_source":15,"_file":1028,"_stem":1029,"_extension":18},"/en-us/blog/navigation-research-blog-post",{"title":1013,"description":1014,"ogTitle":1013,"ogDescription":1014,"noIndex":6,"ogImage":1015,"ogUrl":1016,"ogSiteName":672,"ogType":673,"canonicalUrls":1016,"schema":1017},"How we overhauled GitLab navigation","Users weren't getting what they needed from our navigation. Here are the steps we took to turn that experience around.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682884/Blog/Hero%20Images/navigation.jpg","https://about.gitlab.com/blog/navigation-research-blog-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we overhauled GitLab navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Knobloch\"}],\n        \"datePublished\": \"2023-08-15\",\n      }",{"title":1013,"description":1014,"authors":1019,"heroImage":1015,"date":1021,"body":1022,"category":728,"tags":1023},[1020],"Ashley Knobloch","2023-08-15","\nGitLab navigation was complex and confusing - that was the message we received from our users through issues and other feedback channels. Initially, to address these concerns, we conducted research around proposed solutions, but quickly found they wouldn't help users achieve their goals well enough to warrant implementing them. In the process of learning what wasn't working and what wouldn't work, we still didn't have clarity around *why* the navigation wasn't working. This article chronicles our journey to finding that clarity and developing navigation that is easier to use and better suited to our users' needs.\n\n## Our approach\nAs a first step, we reviewed past research and user feedback to ensure we had a solid understanding of what we had done and learned already. We found that we still needed more insight into why proposed changes weren’t receiving enough positive feedback to implement them.\n\nOur goals were straightforward:\n- understand what users are doing in GitLab\n- study how they navigate the platform\n- learn why they need certain navigation elements \n\nOur perspective shifted from validating proposed solutions to going back to revalidate the problems that exist with our navigation experience. Our hypothesis was that with a deeper understanding of our users’ behavior and mental models for how they navigate around GitLab, we could develop concepts to better match their needs and improve their overall experience.  \n\nThe scope of features in GitLab and the number of user personas across GitLab made this challenging. We have [16 personas](https://handbook.gitlab.com/handbook/product/personas/#user-personas) to represent different types of users, all with unique goals and techniques to achieve those goals. We focused our efforts on a subset of those personas that best represented usage across GitLab to ensure a holistic understanding of different user needs. We wanted to learn how navigation among different personas was similar and where it differed, what worked well with the current navigation, and what challenges users faced.\n\n## Studying key persona cohorts\nWe conducted [diary studies](https://about.gitlab.com/handbook/product/ux/ux-research/diary-studies/) with cohorts of our key personas to learn what their primary tasks and workflows were at a deeper level. This provided us with many real-world examples of how they navigate to their tasks and why. We also learned what worked well with their current workflows, what pain points existed, and what workarounds were being used (such as creating browser bookmarks, typing in the URL to pull browser history, or keeping a bunch of browser tabs open) to streamline their tasks in GitLab. \n\nWe learned that for some users, many of their primary tasks don’t require much navigation within GitLab because they use outside tools that link into GitLab through notifications (e.g., Slack and email) or use direct links through other tools. We also learned that often users’ work is quite scoped in GitLab, and they would like easier access to some of their core features without having to wade through all of the other features they don’t use. This illuminated some unmet needs that would improve their workflows, such as having the ability to customize navigation to access things important to them more quickly and streamline their path to relevant projects.\n\nLearning more about our users from a foundational perspective ensured that we had a solid base to build upon when considering changes to the navigation.\n\n## Anchoring to a North Star\nTo anchor the redesign process in user problems more broadly, a review of past feedback was analyzed that revealed three overarching themes with navigation-related feedback. These themes helped to guide the process and to remind us of the key problems we were trying to solve: \n- minimize feeling overwhelmed (ability to customize left sidebar)\n- orient users across the platform (differentiating groups and projects)\n- pick up where you left off (switching contexts)\n\nThe team continually mapped back design concepts to these themes to ensure potential solutions were rooted in user problems. \n\n## Evaluating and iterating\nNext, several navigation design concepts were developed and shared with users for feedback. Multiple rounds of [solution validation testing](https://about.gitlab.com/handbook/product/ux/ux-research/solution-validation-and-methods/) were conducted with our key personas to determine which design concepts to move forward with. The testing revealed how users felt about each design and also how well each design supported users completing core tasks. We identified a final concept that supported mature and new GitLab users with common workflows.\n\n## Understanding mental models for sidebar organization\nWe wanted to revisit our groupings in the left sidebar because we’ve heard over time that the organization can be confusing and unintuitive, especially some categories such as Operations. We needed to understand our users’ mental models for how they would group these items, and why. Learning the thought processes behind their organization was critical for us to know what changes to make that would align with user expectations. \n\nWe ran facilitated [card sort](https://about.gitlab.com/handbook/product/ux/ux-research/mental-modeling/#card-sorting) studies with our key personas to understand how they would group items in the left sidebar, and why. This helped us learn some areas that could benefit from readjusting, such as the Manage and Operate categories. We learned that users most often preferred to have analytics items together, for example, which is reflected in the Analyze tab. This insight, combined with patterns in analytics data, informed changes to the groupings in the left sidebar to better support workflows. \n\n## Launching and learning\nPrior to launching to external users, the new navigation was released to internal team members and we collected [feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/403059) to help iterate and improve the experience. \n\nNext, we launched the new navigation to external users as a toggle that could be turned on optionally. During this initial launch, a [longitudinal study](https://about.gitlab.com/handbook/product/ux/ux-research/longitudinal-studies/) was conducted with a sample of GitLab users to learn how they experienced the change in the context of their real work. Over time, the study would provide insight into adoption among the entire user base.  \n\nWe interviewed users prior to the monthlong study to learn more about their experience with the existing navigation. Then, they began using the new navigation while completing surveys and participating in interviews at checkpoints in the beginning, middle, and end of the month. This enabled us to capture their initial impressions of the new navigation, what they liked/disliked, how the new experience compared to the previous one, and if their sentiment changed over the course of the month as they continued to use the new navigation. \n\nUsers in this study found the new navigation to be an improvement from the previous one, and most preferred its features, including:\n- the ability to pin items streamlined common workflows\n- the new task-based sidebar categories in the sidebar, which they said felt more approachable, especially for newer users\n- the new navigation changes, which they said weren’t too overwhelming and felt familiar\n\nWe also learned about some opportunities to iterate and improve the new experience. For instance, some users pointed out:\n- the inability to pin entire Projects, Groups, or specific pages makes it difficult to streamline other workflows\n- some users unpin items accidentally\n- the overall lack of color can cause some features to blend in or be missed\n- it's not always easy to know what’s new in GitLab  \n\n## What’s next: Iterate, listen, and iterate again\nTo capture large-scale feedback on navigation over time, we launched a new navigation-focused quarterly survey in Q1 (February) of this year. This first quarter data established a baseline of our old navigation, and beginning in Q2 (May), we began collecting data on the new navigation experience. We will monitor this closely, and look for themes to help us learn what is working well and what may need further iteration. \n\nThis survey, along with our longitudinal study feedback and various other user feedback sources, will provide insights to help prioritize iterative improvements to the new navigation experience. Stay tuned for changes, and keep sharing [your navigation feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/409005) with us!\n",[856,854,9],{"slug":1025,"featured":6,"template":685},"navigation-research-blog-post","content:en-us:blog:navigation-research-blog-post.yml","Navigation Research Blog Post","en-us/blog/navigation-research-blog-post.yml","en-us/blog/navigation-research-blog-post",{"_path":1031,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1032,"content":1038,"config":1045,"_id":1047,"_type":13,"title":1048,"_source":15,"_file":1049,"_stem":1050,"_extension":18},"/en-us/blog/one-devops-platform-can-help-you-achieve-devsecops",{"title":1033,"description":1034,"ogTitle":1033,"ogDescription":1034,"noIndex":6,"ogImage":1035,"ogUrl":1036,"ogSiteName":672,"ogType":673,"canonicalUrls":1036,"schema":1037},"One DevOps platform can help you achieve DevSecOps","GitLab drives innovation in the AST market to secure cloud-native applications.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679348/Blog/Hero%20Images/locks.jpg","https://about.gitlab.com/blog/one-devops-platform-can-help-you-achieve-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"One DevOps platform can help you achieve DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-05-09\",\n      }",{"title":1033,"description":1034,"authors":1039,"heroImage":1035,"date":1041,"body":1042,"category":833,"tags":1043},[1040],"Sandra Gittlen","2022-05-09","\n\nApplication security testing (AST) is a fast-moving and important area for software development. DevOps methodologies have spurred the need to integrate testing within the developer’s workflow. GitLab believes the more ingrained AST is in the software factory, the more secure applications will be and the easier it will be for companies to meet compliance demands. We believe our [strategic platform approach](/why-gitlab), where security and compliance are embedded in DevOps from planning to production, provides efficiency and value unmatched by traditional application security vendors.\n\nGartner® has named GitLab a Challenger in the [2022 Gartner Magic Quadrant™ for Application Security Testing](https://page.gitlab.com/resources-report-gartner-magic-quadrant-ast.html). According to Gartner, “a major driver for the evolution of the AST market is the need to support enterprise [DevSecOps](/topics/devsecops/) and cloud-native application initiatives.”\n\n“We are excited to see continued momentum for our unique approach that embeds security into the DevOps workflow,” says Hillary Benson, GitLab director of product management. This is the third year that GitLab has been recognized in the Gartner Magic Quadrant for Application Security Testing. “We believe that our recognition as a Challenger in the Magic Quadrant represents an evolving market understanding of the value of an approach that empowers and enables developers to find and fix vulnerabilities – and the simplicity of leveraging a DevOps platform to do so.”\n\n> **You can read more about the results and download a copy of the report by visiting [our commentary page](/analysts/gartner-ast22/).**\n\n\nGitLab’s complete DevOps platform approach provides automation needed by DevOps, along with policy and vulnerability management needed by security professionals. GitLab’s Ultimate tier provides an integrated, vetted, and managed set of scanners to meet the security and compliance needs of modern-day application development and [cloud-native](/topics/cloud-native/) environments. \n\n## A unique approach to AST\n\nWe continue to innovate in the application security space. Let’s look at how we’re different from many of the more traditional stand-alone AST technologies. It’s these very differences that provide benefits achievable by using a single platform for DevOps and security. For example: \n\nWe build comprehensive scans into the CI pipeline to enable a more interactive testing environment. This is a unique approach as others in the category focus their offering on instrumentation-based interactive AST. With GitLab, the developer gets a more complete view of the security flaws as they are created – when they are most efficiently resolved.\n\nSimilarly, while analysts place emphasis on lightweight spell-check-like SAST features, we have found that these features are less important to GitLab users, again because of our built-in approach. A metaphor may be helpful to explain. We are all accustomed to saving documents frequently so edits are not lost. Developers do the same while editing software. Changes made are “committed” frequently to the code repository. Upon hitting the ‘commit’ button, GitLab performs a true, [SAST scan](/direction/secure/static-analysis/sast/) on code changes, which gives developers instant and more complete feedback. And DevOps teams can choose to enable  [DAST scanning](https://docs.gitlab.com/ee/user/application_security/dast/) that uses GitLab’s review app feature to assess changes pre-merge. Similarly,  [dependencies](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), containers, infrastructure as code, and more can all be scanned, at the push of the commit button.\n\nIn addition, GitLab also is keen on providing DevOps teams just-in-time education about vulnerabilities and fixes. Now, via partnerships with [Kontra](/blog/kontra-and-gitlab-integrate-vulnerability-education-into-the-devops-workflow/) and [Secure Code Warrior](/blog/heres-how-to-get-integrated-secure-coding-advice-in-gitlab/), GitLab provides developers with crisp training on how to mitigate the specific vulnerability they just created. This helps developers learn proper coding techniques instead of flagging the problem to figure out later.\n\n## Concentrating on compliance\n\nShifting compliance left and embedding it deep into the software development lifecycle, a.k.a. [continuous software compliance](/solutions/compliance/), is also a priority for GitLab.\n\n“We enable organizations to create policies that align with their compliance regulations and enforce them throughout the application development workflow,” Benson says. “Rather than juggling multiple policy enforcement applications, you have a single lens for visibility across the entire lifecycle.” For instance, a company can develop granular compliance pipeline policies that require a SAST to run for every commit in a certain project or a chain of MR approvals that developers can’t circumvent. “Those types of common controls and separation of duties simplify software audits and speed up application deployments.”\n\nGitLab is honored to be recognized in the Gartner Magic Quadrant, and will continue to empower and unite developers and security professionals alike using repeatable, defensible processes that automate security and compliance policies from development through production.\n\n> **[Start a free Ultimate trial](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial)**\n \n_Gartner, “Magic Quadrant for Application Security Testing,” Dale Gardner, Mark Horvath, Dionisio Zumerle, April 18, 2022. Gartner does not endorse any vendor, product or service depicted in our research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER and Magic Quadrant are registered trademarks and service marks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved._\n\nCover image by [Fly:D](https://unsplash.com/photos/ZNOxwCEj5mw) on Unsplash\n{: .note}\n",[707,773,9,833,1044],"testing",{"slug":1046,"featured":6,"template":685},"one-devops-platform-can-help-you-achieve-devsecops","content:en-us:blog:one-devops-platform-can-help-you-achieve-devsecops.yml","One Devops Platform Can Help You Achieve Devsecops","en-us/blog/one-devops-platform-can-help-you-achieve-devsecops.yml","en-us/blog/one-devops-platform-can-help-you-achieve-devsecops",{"_path":1052,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1053,"content":1059,"config":1065,"_id":1067,"_type":13,"title":1068,"_source":15,"_file":1069,"_stem":1070,"_extension":18},"/en-us/blog/redesigning-our-docs",{"title":1054,"description":1055,"ogTitle":1054,"ogDescription":1055,"noIndex":6,"ogImage":1056,"ogUrl":1057,"ogSiteName":672,"ogType":673,"canonicalUrls":1057,"schema":1058},"Redesigning the GitLab docs","We're working on improving our documentation site usability and discoverability. Check out what's changed and get a sneak peek at the refinements coming to docs.gitlab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670050/Blog/Hero%20Images/homepage-cover-image.png","https://about.gitlab.com/blog/redesigning-our-docs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Redesigning the GitLab docs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2021-02-12\",\n      }",{"title":1054,"description":1055,"authors":1060,"heroImage":1056,"date":1062,"body":1063,"category":704,"tags":1064},[1061,850],"Susan Tacker","2021-02-12","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-03-03.\n{: .note .alert-info .text-center}\n\nFor a product like GitLab, great documentation isn’t just nice to have – it’s a must. \n\nAs a complete DevOps platform, GitLab brings a sprawling tooling ecosystem into a single experience so that teams can build software faster and with greater confidence. Part of our responsibility is to help users quickly understand how to complete standard tasks, while giving them insight into the larger possibilities of the product and which features they might take advantage of next.\n\nOver the past year, we’ve worked really hard to understand our docs experience. We started by assessing the sheer amount of content that’s available on [docs.gitlab.com](https://docs.gitlab.com/) (equal to two copies of \"War and Peace\"!) and then we began user research to discover how well that content meets our users’ needs.\n\n**Wow, did we learn a lot!** While 96% of participants thought our content was useful, research confirmed what we suspected: we have some problems with site usability and information discoverability. That was good news, because these things are fixable. In this blog post, you’ll learn more about what’s in process, what we’ve already addressed, and what we plan to do next.\n\n## What we’re working on now\n\nLet’s start by covering what we’re working on now, since these are nice refinements that we’re really excited about.\n\n### It’s always about the homepage\n\nA website’s homepage is where users first orient themselves and look for important information. And, frankly, our homepage just isn’t doing that job well. While we’ve made iterative improvements over the past year (we'll talk about those in a minute), we know it’s time for a major overhaul. That's why we’re so excited to see the improvements we’ve made in collaboration with senior product designer, [Jeremy Elder](/company/team/#jeldergl), come to fruition.\n\nHere's our current home page.\n\n![Current homepage](https://about.gitlab.com/images/blogimages/redesigning-our-docs/homepage-current.png){: .shadow.medium.center}\nCurrent homepage\n{: .note.text-center}\n\nOur [homepage redesign](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/916) focuses on: \n\n- Helping users find what they need more quickly by elevating search and removing extraneous content to simplify the design\n- Highlighting key areas that users typically want to get started \n- Making installation instructions easy to find\n- Aligning the top navigation with accessibility guidelines\n\n![Homepage coming soon](https://about.gitlab.com/images/blogimages/redesigning-our-docs/homepage-coming-soon.png){: .shadow.medium.center}\nIn progress (better usability and visual appeal)\n{: .note.text-center}\n\n### Type scales matter\n\n> \"Sometimes I get emotional over fonts.\" - Kanye West\n\nIt’s OK, Kanye – we understand. Fonts make us emotional sometimes, too. Unfortunately, our current type scale makes us feel sad. :( \n\nHere's what it looks like now:\n\n![Type scale before](https://about.gitlab.com/images/blogimages/redesigning-our-docs/typescale-before.png){: .shadow.medium.center}\nCurrent type scale\n{: .note.text-center}\n\nHere's a peek at how we’re [updating it](https://gitlab.com/gitlab-org/gitlab/-/issues/300424#note_497435628) to be more modern, easier to scan, and better themed. \n\n![Type scale after](https://about.gitlab.com/images/blogimages/redesigning-our-docs/typescale-after.png){: .shadow.medium.center}\nComing soon!\n{: .note.text-center}\n\n## What we’ve already done\n\nAs mentioned before, we didn’t just start this refinement process – we’ve been making iterative changes for a while. Those changes aren’t as impactful as what we’re working on now, but they’re still worth mentioning.\n\n### Fixed our alert box madness\n\nAlert boxes, including notes, tips, and warnings, provide important information that we want you to know. That doesn’t mean they should be visually overwhelming. And when you overuse them, making it seem like everything is important, then nothing is.  (Confession time: One of our pages included 40 notes.)\n\nSo, we [reduced the number of “Notes”](https://gitlab.com/gitlab-org/technical-writing/-/issues/255) in our documentation by 25%, and we toned down the colors of notes, tips, and warnings to be less “in your face.” \n\n![Before and after of alert boxes](https://about.gitlab.com/images/blogimages/redesigning-our-docs/notecolor.png){: .shadow.medium.center}\nAlert box refinement\n{: .note.text-center}\n\n### Improved topic scanning with better use of fonts and white space\n\nGood use of fonts and white space can provide visual cues that help users more quickly identify related information. This is especially important for scanning large amounts of content.\n\nThe most egregious example of elements that needed to change was our headings.\n\n![Before headings](https://about.gitlab.com/images/blogimages/redesigning-our-docs/Headings1111.png){: .shadow.medium.center}\nEarlier version of headings\n{: .note.text-center}\n\nTo begin making improvements, we removed the borders from every heading level except H1, refined how we used margins, and made better use of font weight and size to distinguish levels H2 and smaller. Our headings will continue to improve in the type scale work we’re doing now, but in the spirit of early iteration, we didn’t let perfect be the enemy of better.\n\n![After headings](https://about.gitlab.com/images/blogimages/redesigning-our-docs/Headings1309.png){: .shadow.medium.center}\nCurrent version of headings\n{: .note.text-center}\n\nAlso, the leading in our bulleted lists (which appear frequently in technical docs) was… weird. Every line of text had equal spacing, making it difficult to see what information belonged together. There was too much space between the introductory sentence and the bullets that followed. \n\nNot anymore!\n\n![Refined bullets](https://about.gitlab.com/images/blogimages/redesigning-our-docs/bulletspacing.png){: .shadow.medium.center}\nFixed leading, margin, and enumeration\n{: .note.text-center}\n\n### Toned down visual noise of images\n\nWe also realized that our images were too visually pronounced. So, we removed drop shadows and reduced the size of the margins surrounding images.\n\n![Images are toned down](https://about.gitlab.com/images/blogimages/redesigning-our-docs/padding2.png){: .shadow.medium.center}\nRemoved drop shadow and reduced margin\n{: .note.text-center}\n\n## What’s up next\n\nWe’re excited about the improvements we’ve already made and what’s in process now, but there’s still more to do. Based on the same user research that guided our visual design enhancements, our [Documentation Roadmap](https://gitlab.com/groups/gitlab-org/-/epics/4602) includes back- and front-end changes to continue to improve the docs experience for the GitLab community. \n\nAs always, we value your feedback, so please continue to let us know how we’re doing!\n",[855,9,854],{"slug":1066,"featured":6,"template":685},"redesigning-our-docs","content:en-us:blog:redesigning-our-docs.yml","Redesigning Our Docs","en-us/blog/redesigning-our-docs.yml","en-us/blog/redesigning-our-docs",{"_path":1072,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1073,"content":1079,"config":1087,"_id":1089,"_type":13,"title":1090,"_source":15,"_file":1091,"_stem":1092,"_extension":18},"/en-us/blog/risk-mapping",{"title":1074,"description":1075,"ogTitle":1074,"ogDescription":1075,"noIndex":6,"ogImage":1076,"ogUrl":1077,"ogSiteName":672,"ogType":673,"canonicalUrls":1077,"schema":1078},"Search team directs testing efforts with risk mapping","A justification of how the search team decided to try risk mapping as an ongoing exercise to determine where test automation should be written, and some guidance on how to create a risk map.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669590/Blog/Hero%20Images/niklas_hamann-fyvNzhJTQBA-unsplash.jpg","https://about.gitlab.com/blog/risk-mapping","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the Search Team at GitLab Implemented a Risk Map to Direct Automated Testing Efforts\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erick Banks\"},{\"@type\":\"Person\",\"name\":\"John McGuire\"}],\n        \"datePublished\": \"2020-09-03\",\n      }",{"title":1080,"description":1075,"authors":1081,"heroImage":1076,"date":1084,"body":1085,"category":680,"tags":1086},"How the Search Team at GitLab Implemented a Risk Map to Direct Automated Testing Efforts",[1082,1083],"Erick Banks","John McGuire","2020-09-03","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n**_’What's the good of Mercator's North Poles and Equators,_**\n\n**_Tropics, Zones, and Meridian Lines?’_**\n\n**_So the Bellman would cry: and the crew would reply_**\n\n**_‘They are merely conventional signs!’_**\n\n**-Lewis Carroll, \"The Hunting of the Snark\"**\n\nWhen I first started at GitLab I was hired to automate a specific task for the advanced search team: search for security holes in our data redaction logic. Shortly after my being hired this mandate became moot. Simultaneously, the search team was also in the middle of transitioning our product manager to a new team and introducing a new one. This left me with some existential angst around my role as the software engineer in test for the search team. I mean, there’s always work to do, but *what* work would be *most helpful*?\n\nAfter a few months of seeing bug reports being filed by users and GitLab team members, I thought it would be best to try to direct our testing efforts where we have the most unmitigated risk. But, how would we come to know with any degree of certainty where that is? To find out I made a risk map.\n\nRisk maps are not new. [The United States Federal Emergency Management Agency](https://www.fema.gov/flood-maps/tools-resources/risk-map) uses them, [insurance companies](https://www.techriskreport.com/2019/10/preparing-for-data-breaches-data-mapping-response-team-and-insurance/) use them, and [software companies](https://www.pmi.org/learning/library/risk-analysis-project-management-7070) use them.\n\nThe point of the risk map is to show you and your team where in the project you are responsible for is the most unmitigated risk. It can then be used to inform what areas of the project should be the focus of adding testing, preferably automation, though not exclusive of manual testing ([exploratory testing](https://www.tricentis.com/blog/creating-an-exploratory-testing-charter/), [bug bashes](https://www.classy.org/blog/run-bug-bash/), etc.).\n\n## “The Map is Not the Territory”\n\nRisk maps are not perfect reflections of where the risk exists in your project. Any criticism of the map, “It gets stale too quickly”, “You’re distorting where the real risk lies”, “It takes too much time to keep updated”, have validity and could apply just as well to maps of physical places. In my case I would say that even a low resolution map, supported by data, of where risk is in the project is better than no map at all. Without such a map I would continue working by just relying on my gut instinct of where the risk is, or worse, I would be in the reactive state of fixing things after they’ve gone wrong. Isn’t an old, out of date map sometimes useful?\n\n## Should You Make A Risk Map?\nOf course I can’t be prescriptive about this. If you’re reading this, you are likely the best judge of if you and your team will get utility from making one. I can say that in my situation: new to the search team, transitioning to a new product manager, and no clear signal as to where the riskiest part of the project was, it made sense for me to make one.\n\n## How to get started\nIf you do decide you want to make a risk map for your team, here are some steps and tips that may help.\n\nFirst you’ll want to get a sense of what can go wrong. I call these “risk facets”. For example: a simplified view of [Elasticsearch](https://www.elastic.co/home) (the underlying tech we use for our advanced search feature at Gitlab) is that users insert records (Merge Requests, Issues, Users, Comments etc.) they want to be searchable into GitLab, that record gets indexed, and then, later, a user tries to recall that record. In this simplified view the facets could be problems around record insertion, indexing, and recall. These could be multiplexed by considerations of: speed, efficiency, and cost. So, that may yield a risk map with nine rows, or risk facets: record insertion - speed, record  insertion - efficiency, record insertion - cost, record indexing - speed, etc.\n\nA helpful starting point for understanding what risk facets may be for your project is to look at the list of features it has. This is not likely to be an exhaustive list of the risk facets your project presents, but it is a good place to start.\n\nSome of these facets may have a label (or, more likely, a combination of labels) that accurately map issues to the risk facet. If your project is anything like mine, many facets will **not** have these corresponding labels. For future extensibility and automated aggregation of issues around each facet, it is important to create labels or create combinations of labels that can accurately map issues to a single risk facet.\n\nSo, take some time to read through recent issues. Look at the issues your users are filing. See if there are some shared areas around which the issues are filed. These are likely the more important risk facets. I did this over several weeks of reading issues as they were filed and extrapolating where problems could arise. I then created a list of these facets in a notebook until I found that I had a substantial amount of facets that could be tracked. Next, I transferred those risk facets to the rows of the table in the risk map issue.\n\n![Example Chart from website](https://about.gitlab.com/images/blogimages/egb/risk-map/facets.png){: .shadow.center}\n\nDo not, as I did, confuse *solutions* to risk facets for the risk facets themselves. For example, I erroneously added a row to my map for “regex - optimization”, which is a solution to the risk facet “regex - efficiency”.\n\nAfter a time of gathering the risk facets and adding them to the rows of the table in the issue it’s time to add the other columns to the table and track if those risk facets are being implicitly or explicitly tested and where. It felt important to differentiate between implicit and explicit testing because explicitly testing for every risk facet is prohibitively expensive in either time, cost, effort, etc. (or some combination thereof). Just because we aren’t explicitly testing some facet doesn’t mean there isn’t some kind of test coverage for that facet. Since the exercise is aimed at showing the team where risk facets are, their severity, and if they are being mitigated or not, showing where the implicit testing is happening is important. Fill in the implicit/explicit testing columns and add the links that point to where this testing is happening.\n\n![Example Chart from website](https://about.gitlab.com/images/blogimages/egb/risk-map/facet-coverage.png){: .shadow.center}\n\nThe last three columns compose your [risk matrix](https://en.wikipedia.org/wiki/Risk_matrix). They are: *risk level*, *impact*, and *likelihood*, so ordered so that the most important of the three columns, *risk level* (which is just a composite of the other two columns), is more likely to be visible before horizontally scrolling off the screen, are most likely to need input from the rest of the team. Actively solicit other team members to help fill out these columns.\n\n![Example Chart from website](https://about.gitlab.com/images/blogimages/egb/risk-map/riskmatrix.png){: .shadow.center}\n\nIt’s important to recognize that this map will never be done. You’ll never “finish it”. Incompleteness is to be expected. But what should emerge is a picture of where most of the testing is being done, and where most of the risk is being carried in the project. You can then use this to help the team align testing toward facets to better mitigate risk.\n\n![Example Chart from website](https://about.gitlab.com/images/blogimages/egb/risk-map/risk-map-sample.png){: .shadow.center}\n## Product Management\n\nTo Product Managers a risk map helps quantify the amount of energy to spend mitigating a possible risk. With a goal of not over investing in a mitigation, as well as avoiding catastrophe.  Product Managers can also help identify primary and secondary effects that can create a need to change the level of risk assessed. \nHistory is full of examples where improper risk assessments lead to preventable disasters. [PMI.org Deepwater Horizon\nLessons in Probabilities](https://www.pmi.org/learning/library/comparison-risk-events-with-risk-management-9919)\n## Next steps\n\n- Identify where the highest risk is and try to mitigate it.\n- Decide with the team how often we should update the risk map.\n- Add labels so that each issue for the search team falls into one unique risk facet.\n- Automate some of the creation of the map by aggregating issues and MRs based on the newly created labels.\n- Compare my efforts at doing this exercise with other teams (should they decide to do it as well).\n- Add features like:\n  - Sorting by risk level\n  - Toggle by open/closed/all for issues/MRs.\n  - Toggle displaying issues found by customers.\n\nLink to Risk Map: [https://gitlab.com/gitlab-org/gitlab/-/issues/229431](https://gitlab.com/gitlab-org/gitlab/-/issues/229431)\n\nLink to Risk Mapping Epic: [https://gitlab.com/groups/gitlab-org/-/epics/4253](https://gitlab.com/groups/gitlab-org/-/epics/4253)\n\nCover image by [Niklas Hamann](https://unsplash.com/@hamann?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/server?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n{: .note}\n",[1044,833,9],{"slug":1088,"featured":6,"template":685},"risk-mapping","content:en-us:blog:risk-mapping.yml","Risk Mapping","en-us/blog/risk-mapping.yml","en-us/blog/risk-mapping",{"_path":1094,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1095,"content":1101,"config":1108,"_id":1110,"_type":13,"title":1111,"_source":15,"_file":1112,"_stem":1113,"_extension":18},"/en-us/blog/the-evolution-of-ux-at-gitlab",{"title":1096,"description":1097,"ogTitle":1096,"ogDescription":1097,"noIndex":6,"ogImage":1098,"ogUrl":1099,"ogSiteName":672,"ogType":673,"canonicalUrls":1099,"schema":1100},"The Evolution of UX at GitLab","What did it look like to work in User Experience (UX) at GitLab over the last several years? Take a peek into our time machine.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679527/Blog/Hero%20Images/timeline.png","https://about.gitlab.com/blog/the-evolution-of-ux-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Evolution of UX at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Austin Regnery\"}],\n        \"datePublished\": \"2021-05-04\",\n      }",{"title":1096,"description":1097,"authors":1102,"heroImage":1098,"date":1104,"body":1105,"category":680,"tags":1106},[1103],"Austin Regnery","2021-05-04","\n\nSince hiring our first designer at GitLab in 2014, there have been numerous milestones for the product and our organization. It's easy to get lost in the day-to-day and lose sight of the accomplishments that brought us to where we are today, so let's look back to remind ourselves of how far we've come.\n\nNielsen Norman Group breaks down the progression of UX Maturity into eight stages ([1-4](https://www.nngroup.com/articles/ux-maturity-stages-1-4/) & [5-8](https://www.nngroup.com/articles/ux-maturity-stages-5-8/)). This retrospective looks into our perception of how the UX department has evolved over the last several years. It is by no means a perfect evaluation, but it illustrates our journey thus far.\n\n## 2014-2016 (UX maturity stages 1-3)\n\nThe first designer at GitLab was hired in September of 2014, with the audacious goal to uplift the UI design of GitLab away from vanilla Bootstrap. With that came a more intensive demand on UX to bring cohesion to the incoming development changes. Working with a limited capacity was an expected growing pain and necessary for evolving the maturity of our UX at GitLab.\n\nIn mid-2016, the workload on UX did not slow down, as GitLab continued to emphasize improvement to the existing UI and new features. Our UX team grew from 1 to 6 people, including the hiring of our first UX manager and UX researcher. UX moved to the Engineering department to better align the two practices, focusing on speed of iteration. The team's growth brought some changes to our UI design tooling (moving from Antetype to Sketch).\n\n**Fun product milestones**\n- CI grew beyond jobs (back then \"builds\") into the [pipelines](https://about.gitlab.com/releases/2016/05/22/gitlab-8-8-released/)\n- [Review Apps](https://about.gitlab.com/blog/introducing-review-apps/) released\n- [Better empty states](https://about.gitlab.com/blog/gitlab-ux-update/) began to appear\n- We implemented our [first redesign of site navigation](https://about.gitlab.com/blog/navigation-redesign/)\n\n![Image of GitLab builds in 2016 compared to pipelines in 2021](https://about.gitlab.com/images/blogimages/ux-evolution/pipelines-side.png){: .shadow}\n\nBuilds in 2016 (left) vs pipelines in 2021 (right) \n{: .note.text-center}\n\n## 2017-2018 (UX maturity stages 4-5)\n\nEmphasis on setting the foundations for the future of UX at GitLab started to come into play, and the team grew to 12 people. We began documenting our personas, [why we use them](https://about.gitlab.com/blog/the-importance-of-ux-personas/), and insights from UX research in our handbook. [Category Maturity Scorecards](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) established a mechanism to evaluate our UX. We took our first steps towards the [Pajamas Design System](https://design.gitlab.com/). We also made a shift to allow better cross-functional collaboration by [restructuring our organization into stage groups](https://about.gitlab.com/blog/configure-post/). These things helped keep the UX tightly integrated as GitLab began to expand to a more holistic DevOps solution.\n\n**Fun product milestones**\n- [Navigation overhauled again](https://about.gitlab.com/blog/unveiling-gitlabs-new-navigation/)\n- GitLab grew its product scope from Dev to [DevOps](https://about.gitlab.com/blog/from-dev-to-devops/)\n- Launched a research program, [GitLab First Look](https://about.gitlab.com/community/gitlab-first-look/), for invites to usability tests, user interviews, surveys, and more\n- [Custom illustrations and icons](/blog/illustrations-and-icons-on-gitlab-com/) started making their way into the product, replacing the FontAwesome icon library\n- [Color system](https://design.gitlab.com/product-foundations/colors) introduced, read more on [why we focused on colors](https://about.gitlab.com/blog/polishing-gitlabs-ui-a-new-color-system/)\n- [WebIDE](https://about.gitlab.com/blog/introducing-gitlab-s-integrated-development-environment/) reached [HackerNews #1](https://news.ycombinator.com/item?id=17321921)\n\n![Image of GitLab left navigation in (left) vs 2021 (right)](https://about.gitlab.com/images/blogimages/ux-evolution/nav-side-by-side.png){: .shadow}\n\nGitLab left navigation in 2016 (left) vs 2021 (right)\n{: .note.text-center}\n\n## 2019-2020 (UX maturity stages 6-7)\n\nThings started to boom as the UX department grew to nearly the 60 individuals that we have today. This growth brought our ratio of Product Designers to Product Managers closer to our goal of a balanced 1:1 ratio. Increasing the presence of UX made it possible to embed into cross-functional teams. Broader department changes helped support this scale by incorporating the design system into our quarterly Objectives and Key Results while also switching to more web app tooling (Figma and Mural). Expanding our tools created space to focus on UX debt, actionable insights, and our [System Usability Scale](https://about.gitlab.com/handbook/product/ux/performance-indicators/system-usability-scale/). Tech writing became a part of the UX department. We dedicated a team to the Pajamas Design System. The use of whiteboarding for collaboration became more of a common practice to solve complex problems. Additionally, [pairing designers](https://about.gitlab.com/blog/designing-in-an-all-remote-company/) helped support our all remote culture. \n\nWe also began to place a heavier emphasis on research, and it became much more critical in decision-making. For example, the introduction of [UX Scorecards](/handbook/product/ux/ux-scorecards/) helped quickly identify and prioritize usability issues and Product Designers started regularly conducting their own research. It was also valuable for us to invest in our user research tooling (Dovetail, Qualtrics, and UserTesting.com) for getting feedback from participants in unmoderated and moderated research sessions.\n\n**Fun product milestones**\n- Figma [plugin](https://www.figma.com/community/plugin/860845891704482356/GitLab) was shipped to tie Figma into the GitLab workflow\n- [Design Management](https://about.gitlab.com/releases/2019/08/22/gitlab-12-2-released/) added into GitLab Issues\n\n\n![Image of GitLab in 2015 vs 2021](https://about.gitlab.com/images/blogimages/ux-evolution/old-v-new.png){: .shadow}\n\nGitLab in 2015 (left) vs 2021 (right)\n{: .note.text-center}\n\n## Looking forward\n\nAs the demand for DevOps tooling has grown, GitLab has followed suit. GitLab used to look a lot different in many ways, but our UI is only the surface of the evolution of UX at GitLab. Our team continually is looking inwards for ways to improve and automate small bits of work. We don't try to conquer everything at once, instead embracing the spirit of iteration the best we can. We're still filling the gaps in our UX Maturity, but it is a journey that we will build together as we work towards the ever-elusive User-Driven corporation (Stage 8).\n\n> You can read more about [how we operate as a UX department](https://about.gitlab.com/handbook/product/ux/#how-we-work) in our handbook.\n\nA previous [UX Showcase presentation](https://docs.google.com/presentation/d/1TGwSz2ctX2uLEKEh0pCEwDPzX21WPt9amDBNFsjJI2g/edit#slide=id.g7f2750be29_0_0) inspired this blog. Check out the showcase on our Unfiltered YouTube Channel. Thank you for the great presentation Dimitrie Hoekstra ([GitLab](https://gitlab.com/dimitrieh), [Twitter](https://twitter.com/dimitrieh)).\n\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n    \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/97bcgynw_zY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n\n",[854,855,9,812,1107],"production",{"slug":1109,"featured":6,"template":685},"the-evolution-of-ux-at-gitlab","content:en-us:blog:the-evolution-of-ux-at-gitlab.yml","The Evolution Of Ux At Gitlab","en-us/blog/the-evolution-of-ux-at-gitlab.yml","en-us/blog/the-evolution-of-ux-at-gitlab",{"_path":1115,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1116,"content":1122,"config":1129,"_id":1131,"_type":13,"title":1132,"_source":15,"_file":1133,"_stem":1134,"_extension":18},"/en-us/blog/why-the-market-is-moving-to-a-platform-approach-to-devsecops",{"title":1117,"description":1118,"ogTitle":1117,"ogDescription":1118,"noIndex":6,"ogImage":1119,"ogUrl":1120,"ogSiteName":672,"ogType":673,"canonicalUrls":1120,"schema":1121},"Why the market is moving to a platform approach to DevSecOps","A single DevOps platform improves ROI, the developer experience, and customer retention and satisfaction.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667886/Blog/Hero%20Images/cobolshortage.jpg","https://about.gitlab.com/blog/why-the-market-is-moving-to-a-platform-approach-to-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why the market is moving to a platform approach to DevSecOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-10-24\",\n      }",{"title":1117,"description":1118,"authors":1123,"heroImage":1119,"date":1124,"body":1125,"category":1126,"tags":1127},[725],"2022-10-24","The market is moving to a platform approach to [DevSecOps](/topics/devsecops/). What had previously been a process that let different engineering teams adopt their own tools for different stages of the software development lifecycle – what we call “DIY DevOps” – is being replaced by a method that leverages a single application.\n\nWhy is this happening? First, IT managers are coming to grips with the inefficiencies and cost of toolchain sprawl. Second, executives are relying on digital transformation to solve significant business-level problems: improving developer onboarding and productivity, building high-performing teams, securing the software supply chain, and creating a secure on-ramp to the public cloud. Finally, there’s the impact of [the potential recession](https://www.worldbank.org/en/news/press-release/2022/09/15/risk-of-global-recession-in-2023-rises-amid-simultaneous-rate-hikes), which has accelerated the above trends.\n\nWe recently commissioned a [Forrester Consulting “Total Economic Impact™ of GitLab’s Ultimate Plan” study](https://page.gitlab.com/resources-study-forrester-tei-gitlab-ultimate.html) to better understand how companies save on costs and achieve business and technology goals with GitLab. We focused on our Ultimate tier, which is the fastest growing part of the business. We believe the results align with the business requirements needed to endure economic headwinds and position companies for success: strong return on technology investment, cost savings through technical tool consolidation, a faster pace of application releases to acquire and retain customers, greater development and delivery efficiency, increased and simplified security, and a rapid payback period. \n\nGitLab’s DevOps platform enables source code management, continuous integration/continuous delivery, advanced security capabilities, and more in a single application. The Forrester study found that combination led to:\n\n* Three-year ROI of 427%\n* 12x increase in the number of annual releases for revenue generation applications\n* 87% improvement in development and delivery efficiency time\n* Less than six-month payback period\n\n## Understanding DevOps pain points\n\nTo realize the benefits of a single DevOps platform, organizations have to assess their pain points. Here are some common development lifecycle obstacles that affect organizations of all sizes:\n\n* Complex toolchains and processes\n* Inefficient development environments\n* Lack of security skills\n* Rushed development cycles\n* No single source of truth or single code repository\n* Poor software testing practices\n\nAll of these pain points can impede an organization’s ability to manage through a recession and recovery. \n\n## The benefits of a DevOps platform\n\nThe Forrester study found that GitLab Ultimate provided a composite organization, based on interviewed customers, 10 key quantified benefits over a three-year period. While each benefit on its own could have a positive impact on a business’s ability to stay steady and even thrive during difficult economic times, together they are a powerhouse that can eliminate many pain points.\n\nHere are five of those benefits of the GitLab Ultimate Plan:\n\n### Vulnerability management\n\nAs GitLab’s 2022 Global DevSecOps Survey found, [security is top of mind](/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment/) for all DevOps organizations. Yet security at scale can be challenging, especially finding and hiring professionals with the right skills.\n\nA benefit of GitLab Ultimate, according to the Forrester study, is greater efficiency in managing vulnerabilities. The DevOps platform [integrates and automates vulnerability management](/direction/govern/threat_insights/vulnerability_management/) within the development lifecycle. Issues can be identified, logged, triaged, tracked, and remediated – all in the same DevOps application. Developers can address vulnerabilities in real time, avoiding release delays or software defects and bugs. According to Forrester, the composite organization realized savings of “hours a week because developers have access to better context about the vulnerabilities. This in turn means less back and forth between development and QA/security on an issue.”\n\n### Less homegrown tool development/open source solution management\n\nDevOps teams often spend a considerable amount of time creating tools they need from scratch or finding and managing open source options. GitLab reduces [toolchain complexity (a.k.a. debt)](/blog/battling-toolchain-technical-debt/) by building into the platform the tools and features developers need, enabling them to manage their environment as a single application. GitLab Ultimate enabled the Forrester study’s composite organization to shift “from manually intensive tasks requiring the full attention of the developer, security, and operations teams to an environment where they now spend no more than a few hours per day per person on the same tasks.”\n\n### Efficient development\n\nA highly efficient development process impacts the developer experience, which improves retention. GitLab Ultimate enabled the composite organization to develop code faster, deliver higher quality code, enable better collaboration, and improve the ability to monitor applications, according to the Forrester study. Other advantages include: more streamlined processes, better efficiency among developers and non-technical teammates, and improved visibility and collaboration across the SDLC.\n\n### Better code quality\n\nPoor code quality directly affects a company’s ability to attract and retain customers. GitLab enabled the composite organization to have “a single application that streamlines processes to ensure code is tested, scanned, and verified before it is released,” according to the Forrester study. The result is high-quality code (with reduced defects and bugs) that meets security standards.\n\n### More releases, faster\n\nOrganizations want to be able to address customer needs for newer applications, updates, and enhanced feature sets in a timely fashion. With GitLab, the composite organization can “increase the velocity of updates and releases, allowing it to meet customers’ rising digital demands.”\n\nDevOps brought about the following unquantified benefits for the composite organization, according to the Forrester study: more satisfied employees because they are more productive and collaborative; more satisfied customers because of a smoother project workflow, improved release quality, and a faster release frequency; and improved market innovation and competitiveness due to faster development lifecycle and time to market.\n\nWhile DevOps platform benefits are applicable to any economic environment, they are even more so in this time of economic uncertainty. GitLab enables organizations to extract the most out of their DevOps environment and achieve faster, higher quality, and more secure development and release cycles.\n\n> Download the full [Forrester Consulting “Total Economic Impact of GitLab’s Ultimate Plan” study](https://page.gitlab.com/resources-study-forrester-tei-gitlab-ultimate.html) for:\n\n* Additional benefits of GitLab Ultimate Plan\n* Testimonials from GitLab customers Forrester interviewed\n* Assumptions and risks to calculate ROI","devsecops",[707,9,1128],"performance",{"slug":1130,"featured":6,"template":685},"why-the-market-is-moving-to-a-platform-approach-to-devsecops","content:en-us:blog:why-the-market-is-moving-to-a-platform-approach-to-devsecops.yml","Why The Market Is Moving To A Platform Approach To Devsecops","en-us/blog/why-the-market-is-moving-to-a-platform-approach-to-devsecops.yml","en-us/blog/why-the-market-is-moving-to-a-platform-approach-to-devsecops",{"_path":1136,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1137,"content":1143,"config":1149,"_id":1151,"_type":13,"title":1152,"_source":15,"_file":1153,"_stem":1154,"_extension":18},"/en-us/blog/5-problems-you-can-help-us-solve-right-now",{"title":1138,"description":1139,"ogTitle":1138,"ogDescription":1139,"noIndex":6,"ogImage":1140,"ogUrl":1141,"ogSiteName":672,"ogType":673,"canonicalUrls":1141,"schema":1142},"5 UX problems you can help us fix right now","“We spent 40 hours talking to 20 of you. Now we’ve got some issues we’d like your help on.”","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682386/Blog/Hero%20Images/pexels-sevenstorm-juhaszimrus-704767.jpg","https://about.gitlab.com/blog/5-problems-you-can-help-us-solve-right-now","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 UX problems you can help us fix right now\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Leduc-Mills\"}],\n        \"datePublished\": \"2022-07-25\",\n      }",{"title":1138,"description":1139,"authors":1144,"heroImage":1140,"date":1146,"body":1147,"category":1000,"tags":1148},[1145],"Ben Leduc-Mills","2022-07-25"," \n\nWe’ve all been there. You’re sailing along, being productive, and wham! Something inexplicably awful disrupts your workflow. You ask yourself, “How could _anyone_ think this was a good idea?” Maybe it’s a bug, slow performance, or bad design. One of the reasons we conduct [user experience research at GitLab](/handbook/product/ux/ux-research/) is to find these problems and report back to our teams so they can fix them. \n\n![Grumpy cat looking over computer](https://about.gitlab.com/images/blogimages/hhh13-tEMU4lzAL0w-unsplash__1_.jpg)\nWe've all been there\n{: .note.text-center}\n\nWith a product as rich and complex as GitLab, we find _a lot_ of problems. So many, in fact, we often can't fix them as fast as you find them. ([Although we do try!](/releases/2022/05/22/gitlab-15-0-released/#bug-fixes)) The great thing about GitLab is that [**everyone** can contribute](/company/mission/). This is the first in a new series of blog posts where the UX researchers at GitLab transform their findings into some great first contributions that community members can explore. \n\nWe recently spent 2 hours each with 20 people who use GitLab, going through specific tasks related to branch and merge request operations, and, predictably, we found plenty of things to work on (although this research focused on the code creation and review process) - you can check out the full report below:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe style=\"border: 1px solid rgba(0, 0, 0, 0.1);\" width=\"800\" height=\"450\" src=\"https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2FmF555KKsf1m1UyyXbWxXu2%2FBenchmarking-Slides%3Fnode-id%3D943%253A12915%26scaling%3Dscale-down%26page-id%3D40%253A124%26starting-point-node-id%3D943%253A12915\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nWithout further ado, here are five issues we would **love** your contributions on:\n\n1. [Show more branches in the drop down menu while reverting a merge request.](https://gitlab.com/gitlab-org/gitlab/-/issues/358218) \n1. [Increase the discoverability of the insert suggestion feature.](https://gitlab.com/gitlab-org/gitlab/-/issues/368716) \n1. [Fix data loss when switching from inline to side-by-side view on MR creation page.](https://gitlab.com/gitlab-org/gitlab/-/issues/358217) \n1. [Show selected labels within the dropdown menu.](https://gitlab.com/gitlab-org/gitlab/-/issues/322945) \n1. [Improve clarity of text-only buttons -- Move 'mark as draft' onto new line](https://gitlab.com/gitlab-org/gitlab/-/issues/358437) \n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started/) and [our development guide](/community/contribute/development/) and become an all-star contributor! \n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\nContributing to an open source project also brings a ton of proven benefits you might not expect:\n\n- Contributing is one of the most efficient ways to learn, as it is learning by doing and [being guided by merge request coaches](https://handbook.gitlab.com/job-families/expert/merge-request-coach/). Contributing has been proven time and time again to be the best form of learning!\n- Public exposure and explicit appreciation from the open source community, which helps build your public profile And show your expertise ... you never know when that resume might come in handy! 😊 \n- You're in for a treat: **first-time** contributors receive GitLab swag, **regular** contributors (5 MRs or more) are eligible for the [GitLab Heroes program](/community/heroes), and **top** contributors may be invited to join the [GitLab Core team](/community/core-team/).\n\nAnd not only is this beneficial for you, but also for your employer (if you are employed). Because you are growing and learning at a rapid speed from the best, you will get a faster turnaround time when integrating a feature into the platform since you know how the system works. You will get more value from the most precious resource in the universe, time 🕐. Take advantage of this experience today. We are convinced of the benefits and we hope you and/or your employer are too now. Let's aim for the moon together. 🚀 \n\n1,2,3...**let's go!**\n\nCover image by [SevenStorm JUHASZIMRUS](https://www.pexels.com/@sevenstormphotography/) on [Pexels](https://www.pexels.com/photo/123-let-s-go-imaginary-text-704767/)\n{: .note}\n",[1002,266,1003,9,854],{"slug":1150,"featured":6,"template":685},"5-problems-you-can-help-us-solve-right-now","content:en-us:blog:5-problems-you-can-help-us-solve-right-now.yml","5 Problems You Can Help Us Solve Right Now","en-us/blog/5-problems-you-can-help-us-solve-right-now.yml","en-us/blog/5-problems-you-can-help-us-solve-right-now",3,[665,690,715,736,757,780,800,820,840],1754424532255]