[{"data":1,"prerenderedAt":4782},["ShallowReactive",2],{"/en-us/blog/tags/collaboration/":3,"navigation-en-us":19,"banner-en-us":449,"footer-en-us":466,"collaboration-tag-page-en-us":676},{"_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/collaboration","tags",false,"",{"tag":9,"tagSlug":9},"collaboration",{"template":11},"BlogTag","content:en-us:blog:tags:collaboration.yml","yaml","Collaboration","content","en-us/blog/tags/collaboration.yml","en-us/blog/tags/collaboration","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":445,"_type":13,"title":446,"_source":15,"_file":447,"_stem":448,"_extension":18},"/shared/en-us/main-navigation","en-us",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":376,"minimal":407,"duo":426,"pricingDeployment":435},{"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,186,191,297,357],{"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":168},"Product",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/solutions/",[98,123,147],{"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,137,142],{"text":133,"config":134},"Application Security Testing",{"href":135,"dataGaName":136,"dataGaLocation":27},"/solutions/application-security-testing/","Application security testing",{"text":138,"config":139},"Software Supply Chain Security",{"href":140,"dataGaLocation":27,"dataGaName":141},"/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Software Compliance",{"href":145,"dataGaName":146,"dataGaLocation":27},"/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"Measurement",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":27},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[155,159,163],{"text":156,"config":157},"Visibility & Measurement",{"href":152,"dataGaLocation":27,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Value Stream Management",{"href":162,"dataGaLocation":27,"dataGaName":160},"/solutions/value-stream-management/",{"text":164,"config":165},"Analytics & Insights",{"href":166,"dataGaLocation":27,"dataGaName":167},"/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab for",[171,176,181],{"text":172,"config":173},"Enterprise",{"href":174,"dataGaLocation":27,"dataGaName":175},"/enterprise/","enterprise",{"text":177,"config":178},"Small Business",{"href":179,"dataGaLocation":27,"dataGaName":180},"/small-business/","small business",{"text":182,"config":183},"Public Sector",{"href":184,"dataGaLocation":27,"dataGaName":185},"/solutions/public-sector/","public sector",{"text":187,"config":188},"Pricing",{"href":189,"dataGaName":190,"dataGaLocation":27,"dataNavLevelOne":190},"/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":284},"Resources",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"View all resources",{"href":198,"dataGaName":194,"dataGaLocation":27},"/resources/",[200,233,256],{"title":201,"items":202},"Getting started",[203,208,213,218,223,228],{"text":204,"config":205},"Install",{"href":206,"dataGaName":207,"dataGaLocation":27},"/install/","install",{"text":209,"config":210},"Quick start guides",{"href":211,"dataGaName":212,"dataGaLocation":27},"/get-started/","quick setup checklists",{"text":214,"config":215},"Learn",{"href":216,"dataGaLocation":27,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Product documentation",{"href":221,"dataGaName":222,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best practice videos",{"href":226,"dataGaName":227,"dataGaLocation":27},"/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrations",{"href":231,"dataGaName":232,"dataGaLocation":27},"/integrations/","integrations",{"title":234,"items":235},"Discover",[236,241,246,251],{"text":237,"config":238},"Customer success stories",{"href":239,"dataGaName":240,"dataGaLocation":27},"/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":27},"/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":252,"config":253},"TeamOps",{"href":254,"dataGaName":255,"dataGaLocation":27},"/teamops/","teamops",{"title":257,"items":258},"Connect",[259,264,269,274,279],{"text":260,"config":261},"GitLab Services",{"href":262,"dataGaName":263,"dataGaLocation":27},"/services/","services",{"text":265,"config":266},"Community",{"href":267,"dataGaName":268,"dataGaLocation":27},"/community/","community",{"text":270,"config":271},"Forum",{"href":272,"dataGaName":273,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":275,"config":276},"Events",{"href":277,"dataGaName":278,"dataGaLocation":27},"/events/","events",{"text":280,"config":281},"Partners",{"href":282,"dataGaName":283,"dataGaLocation":27},"/partners/","partners",{"backgroundColor":285,"textColor":286,"text":287,"image":288,"link":292},"#2f2a6b","#fff","Insights for the future of software development",{"altText":289,"config":290},"the source promo card",{"src":291},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":293,"config":294},"Read the latest",{"href":295,"dataGaName":296,"dataGaLocation":27},"/the-source/","the source",{"text":298,"config":299,"lists":301},"Company",{"dataNavLevelOne":300},"company",[302],{"items":303},[304,309,315,317,322,327,332,337,342,347,352],{"text":305,"config":306},"About",{"href":307,"dataGaName":308,"dataGaLocation":27},"/company/","about",{"text":310,"config":311,"footerGa":314},"Jobs",{"href":312,"dataGaName":313,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":313},{"text":275,"config":316},{"href":277,"dataGaName":278,"dataGaLocation":27},{"text":318,"config":319},"Leadership",{"href":320,"dataGaName":321,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":323,"config":324},"Team",{"href":325,"dataGaName":326,"dataGaLocation":27},"/company/team/","team",{"text":328,"config":329},"Handbook",{"href":330,"dataGaName":331,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":333,"config":334},"Investor relations",{"href":335,"dataGaName":336,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":338,"config":339},"Trust Center",{"href":340,"dataGaName":341,"dataGaLocation":27},"/security/","trust center",{"text":343,"config":344},"AI Transparency Center",{"href":345,"dataGaName":346,"dataGaLocation":27},"/ai-transparency-center/","ai transparency center",{"text":348,"config":349},"Newsletter",{"href":350,"dataGaName":351,"dataGaLocation":27},"/company/contact/","newsletter",{"text":353,"config":354},"Press",{"href":355,"dataGaName":356,"dataGaLocation":27},"/press/","press",{"text":358,"config":359,"lists":360},"Contact us",{"dataNavLevelOne":300},[361],{"items":362},[363,366,371],{"text":34,"config":364},{"href":36,"dataGaName":365,"dataGaLocation":27},"talk to sales",{"text":367,"config":368},"Get help",{"href":369,"dataGaName":370,"dataGaLocation":27},"/support/","get help",{"text":372,"config":373},"Customer portal",{"href":374,"dataGaName":375,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":377,"login":378,"suggestions":385},"Close",{"text":379,"link":380},"To search repositories and projects, login to",{"text":381,"config":382},"gitlab.com",{"href":41,"dataGaName":383,"dataGaLocation":384},"search login","search",{"text":386,"default":387},"Suggestions",[388,390,394,396,400,404],{"text":56,"config":389},{"href":61,"dataGaName":56,"dataGaLocation":384},{"text":391,"config":392},"Code Suggestions (AI)",{"href":393,"dataGaName":391,"dataGaLocation":384},"/solutions/code-suggestions/",{"text":108,"config":395},{"href":110,"dataGaName":108,"dataGaLocation":384},{"text":397,"config":398},"GitLab on AWS",{"href":399,"dataGaName":397,"dataGaLocation":384},"/partners/technology-partners/aws/",{"text":401,"config":402},"GitLab on Google Cloud",{"href":403,"dataGaName":401,"dataGaLocation":384},"/partners/technology-partners/google-cloud-platform/",{"text":405,"config":406},"Why GitLab?",{"href":69,"dataGaName":405,"dataGaLocation":384},{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Start free trial",{"href":411,"dataGaName":32,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"Gitlab Icon",{"src":416,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":422,"config":423},"Get Started",{"href":424,"dataGaName":425,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"Learn more about GitLab Duo",{"href":61,"dataGaName":430,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":432},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":434},{"src":420,"dataGaName":417,"dataGaLocation":412},{"freeTrial":436,"mobileIcon":441,"desktopIcon":443},{"text":437,"config":438},"Back to pricing",{"href":189,"dataGaName":439,"dataGaLocation":412,"icon":440},"back to pricing","GoBack",{"altText":414,"config":442},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":444},{"src":420,"dataGaName":417,"dataGaLocation":412},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":450,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":451,"button":452,"image":457,"config":461,"_id":463,"_type":13,"_source":15,"_file":464,"_stem":465,"_extension":18},"/shared/en-us/banner","is now in public beta!",{"text":453,"config":454},"Try the Beta",{"href":455,"dataGaName":456,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"altText":458,"config":459},"GitLab Duo Agent Platform",{"src":460},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":462},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":467,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":468,"_id":672,"_type":13,"title":673,"_source":15,"_file":674,"_stem":675,"_extension":18},"/shared/en-us/main-footer",{"text":469,"source":470,"edit":476,"contribute":481,"config":486,"items":491,"minimal":664},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":471,"config":472},"View page source",{"href":473,"dataGaName":474,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":477,"config":478},"Edit this page",{"href":479,"dataGaName":480,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":482,"config":483},"Please contribute",{"href":484,"dataGaName":485,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":487,"facebook":488,"youtube":489,"linkedin":490},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[492,515,571,600,634],{"title":45,"links":493,"subMenu":498},[494],{"text":495,"config":496},"DevSecOps platform",{"href":54,"dataGaName":497,"dataGaLocation":475},"devsecops platform",[499],{"title":187,"links":500},[501,505,510],{"text":502,"config":503},"View plans",{"href":189,"dataGaName":504,"dataGaLocation":475},"view plans",{"text":506,"config":507},"Why Premium?",{"href":508,"dataGaName":509,"dataGaLocation":475},"/pricing/premium/","why premium",{"text":511,"config":512},"Why Ultimate?",{"href":513,"dataGaName":514,"dataGaLocation":475},"/pricing/ultimate/","why ultimate",{"title":516,"links":517},"Solutions",[518,523,525,527,532,537,541,544,548,553,555,558,561,566],{"text":519,"config":520},"Digital transformation",{"href":521,"dataGaName":522,"dataGaLocation":475},"/topics/digital-transformation/","digital transformation",{"text":133,"config":524},{"href":135,"dataGaName":133,"dataGaLocation":475},{"text":122,"config":526},{"href":104,"dataGaName":105,"dataGaLocation":475},{"text":528,"config":529},"Agile development",{"href":530,"dataGaName":531,"dataGaLocation":475},"/solutions/agile-delivery/","agile delivery",{"text":533,"config":534},"Cloud transformation",{"href":535,"dataGaName":536,"dataGaLocation":475},"/topics/cloud-native/","cloud transformation",{"text":538,"config":539},"SCM",{"href":118,"dataGaName":540,"dataGaLocation":475},"source code management",{"text":108,"config":542},{"href":110,"dataGaName":543,"dataGaLocation":475},"continuous integration & delivery",{"text":545,"config":546},"Value stream management",{"href":162,"dataGaName":547,"dataGaLocation":475},"value stream management",{"text":549,"config":550},"GitOps",{"href":551,"dataGaName":552,"dataGaLocation":475},"/solutions/gitops/","gitops",{"text":172,"config":554},{"href":174,"dataGaName":175,"dataGaLocation":475},{"text":556,"config":557},"Small business",{"href":179,"dataGaName":180,"dataGaLocation":475},{"text":559,"config":560},"Public sector",{"href":184,"dataGaName":185,"dataGaLocation":475},{"text":562,"config":563},"Education",{"href":564,"dataGaName":565,"dataGaLocation":475},"/solutions/education/","education",{"text":567,"config":568},"Financial services",{"href":569,"dataGaName":570,"dataGaLocation":475},"/solutions/finance/","financial services",{"title":192,"links":572},[573,575,577,579,582,584,586,588,590,592,594,596,598],{"text":204,"config":574},{"href":206,"dataGaName":207,"dataGaLocation":475},{"text":209,"config":576},{"href":211,"dataGaName":212,"dataGaLocation":475},{"text":214,"config":578},{"href":216,"dataGaName":217,"dataGaLocation":475},{"text":219,"config":580},{"href":221,"dataGaName":581,"dataGaLocation":475},"docs",{"text":242,"config":583},{"href":244,"dataGaName":245,"dataGaLocation":475},{"text":237,"config":585},{"href":239,"dataGaName":240,"dataGaLocation":475},{"text":247,"config":587},{"href":249,"dataGaName":250,"dataGaLocation":475},{"text":260,"config":589},{"href":262,"dataGaName":263,"dataGaLocation":475},{"text":252,"config":591},{"href":254,"dataGaName":255,"dataGaLocation":475},{"text":265,"config":593},{"href":267,"dataGaName":268,"dataGaLocation":475},{"text":270,"config":595},{"href":272,"dataGaName":273,"dataGaLocation":475},{"text":275,"config":597},{"href":277,"dataGaName":278,"dataGaLocation":475},{"text":280,"config":599},{"href":282,"dataGaName":283,"dataGaLocation":475},{"title":298,"links":601},[602,604,606,608,610,612,614,618,623,625,627,629],{"text":305,"config":603},{"href":307,"dataGaName":300,"dataGaLocation":475},{"text":310,"config":605},{"href":312,"dataGaName":313,"dataGaLocation":475},{"text":318,"config":607},{"href":320,"dataGaName":321,"dataGaLocation":475},{"text":323,"config":609},{"href":325,"dataGaName":326,"dataGaLocation":475},{"text":328,"config":611},{"href":330,"dataGaName":331,"dataGaLocation":475},{"text":333,"config":613},{"href":335,"dataGaName":336,"dataGaLocation":475},{"text":615,"config":616},"Sustainability",{"href":617,"dataGaName":615,"dataGaLocation":475},"/sustainability/",{"text":619,"config":620},"Diversity, inclusion and belonging (DIB)",{"href":621,"dataGaName":622,"dataGaLocation":475},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":338,"config":624},{"href":340,"dataGaName":341,"dataGaLocation":475},{"text":348,"config":626},{"href":350,"dataGaName":351,"dataGaLocation":475},{"text":353,"config":628},{"href":355,"dataGaName":356,"dataGaLocation":475},{"text":630,"config":631},"Modern Slavery Transparency Statement",{"href":632,"dataGaName":633,"dataGaLocation":475},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":635,"links":636},"Contact Us",[637,640,642,644,649,654,659],{"text":638,"config":639},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":475},{"text":367,"config":641},{"href":369,"dataGaName":370,"dataGaLocation":475},{"text":372,"config":643},{"href":374,"dataGaName":375,"dataGaLocation":475},{"text":645,"config":646},"Status",{"href":647,"dataGaName":648,"dataGaLocation":475},"https://status.gitlab.com/","status",{"text":650,"config":651},"Terms of use",{"href":652,"dataGaName":653,"dataGaLocation":475},"/terms/","terms of use",{"text":655,"config":656},"Privacy statement",{"href":657,"dataGaName":658,"dataGaLocation":475},"/privacy/","privacy statement",{"text":660,"config":661},"Cookie preferences",{"dataGaName":662,"dataGaLocation":475,"id":663,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":665},[666,668,670],{"text":650,"config":667},{"href":652,"dataGaName":653,"dataGaLocation":475},{"text":655,"config":669},{"href":657,"dataGaName":658,"dataGaLocation":475},{"text":660,"config":671},{"dataGaName":662,"dataGaLocation":475,"id":663,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":677,"featuredPost":4760,"totalPagesCount":4780,"initialPosts":4781},[678,703,724,745,766,794,815,836,857,877,898,919,941,961,980,999,1018,1039,1062,1081,1106,1126,1148,1169,1189,1210,1229,1249,1271,1292,1314,1335,1354,1374,1395,1416,1437,1457,1476,1497,1518,1536,1554,1572,1590,1608,1626,1644,1664,1684,1703,1723,1743,1762,1781,1799,1818,1837,1857,1877,1896,1915,1935,1954,1974,1995,2015,2035,2055,2076,2096,2115,2135,2156,2176,2196,2215,2233,2252,2273,2293,2313,2332,2351,2369,2389,2409,2428,2446,2466,2487,2508,2526,2546,2564,2585,2604,2623,2643,2662,2683,2703,2721,2741,2760,2780,2799,2819,2838,2856,2876,2896,2915,2934,2953,2972,2992,3012,3031,3052,3071,3091,3110,3130,3149,3168,3187,3206,3224,3244,3264,3284,3304,3324,3343,3363,3382,3402,3420,3439,3457,3477,3498,3516,3536,3555,3575,3594,3614,3634,3653,3673,3694,3716,3735,3753,3771,3789,3807,3825,3843,3861,3880,3900,3920,3938,3958,3976,3997,4015,4034,4052,4071,4091,4110,4129,4146,4168,4187,4206,4225,4244,4265,4285,4303,4322,4340,4359,4378,4396,4415,4433,4453,4472,4492,4511,4530,4548,4567,4584,4604,4625,4643,4662,4682,4701,4720,4740],{"_path":679,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":680,"content":688,"config":696,"_id":699,"_type":13,"title":700,"_source":15,"_file":701,"_stem":702,"_extension":18},"/en-us/blog/4-must-know-devops-principles",{"title":681,"description":682,"ogTitle":681,"ogDescription":682,"noIndex":6,"ogImage":683,"ogUrl":684,"ogSiteName":685,"ogType":686,"canonicalUrls":684,"schema":687},"4 Must-know DevOps principles","Learn four key DevOps principles and why they are essential to successful development and deployment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665982/Blog/Hero%20Images/jpvalery-9pLx0sLli4unsplash.jpg","https://about.gitlab.com/blog/4-must-know-devops-principles","https://about.gitlab.com","article","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"4 Must-know DevOps principles\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n \"datePublished\": \"2022-02-11\",\n }",{"title":681,"description":682,"authors":689,"heroImage":683,"date":691,"body":692,"category":693,"tags":694},[690],"GitLab","2022-02-11","The popular software development methodology [DevOps](/topics/devops/) can be a bit confusing to beginners, especially when it encompasses other areas such as security (DevSecOps), business (BizDevOps), and the like. \n\n## So what is DevOps?\n\nDevOps takes two previously separated teams – software development and IT operations – and turns them into one united front that creates secure code while speeding up the software development lifecycle. DevOps fundamentals include a collaborative and communicative culture, automated testing, releases and deployments, and frequent iteration. Another commonly used term in the DevOps space is [DevSecOps](https://about.gitlab.com/topics/devsecops/), which refers to a DevOps practice with a specific emphasis on security.\n\nWhat matters is what’s at the heart of the DevOps methodology – these four key principles that can improve your organization’s software development practice.\n\n1. Automation of the software development lifecycle\n2. Collaboration and communication\n3. Continuous improvement and minimization of waste\n4. Hyperfocus on user needs with short feedback loops\n\n## An examination of key DevOps principles\n\nRoughly 15 years ago, the idea emerged to bring development and operations together in a seamless fashion. In 2009, the term “DevOps” was coined by Patrick Debois, who is considered one of the methodology’s primary gurus. DevOps includes a lot of the principles of [Agile software development](/topics/agile-delivery/), but with a special emphasis on breaking down development and operations silos. \n\nDevOps has continued to grow in popularity since that time, from small businesses to enterprises with legacy systems and nearly every size company in between. Like almost anything else, DevOps can adapt to an organization’s unique needs and environment, adjusting to what’s most important to the business. \n\nAs such, it’s possible to find many different flavors of DevOps, though, at their core, each has the following 4 must-know principles in place:\n\n### Automation of the software development lifecycle\n\nThe North Star for all DevOps teams is automation. Before DevOps, software development was a very manual effort requiring human involvement (and physical handoffs) at every stage of the process. All of this human involvement meant companies were lucky to update or release new code once a year, and many were on an 18- or 24-month release cadence. \n\nToday so-called [“elite DevOps teams”](/blog/how-to-make-your-devops-team-elite-performers/) release code many times a day – and they’re able to do that largely because of automation. \n\nTo understand the power and importance of automation in DevOps, consider software testing, an often overlooked and unappreciated step that is regularly scapegoated for causing release delays. There’s no question software testing is critical; without testing companies risk releasing broken or actually even unsafe code. \n\nBut testing is perhaps the most hands-on of all the steps in DevOps, requiring people to write test cases, run myriad tests, analyze the results, and then circle back with developers for fixes. That’s all a long way of saying [there’s a reason teams point to testing](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/) as the number one reason code isn’t released on time.\n\nEnter automation and the idea that the most basic software tests could happen as the code is written. Test automation dramatically speeds up the entire process and frees software testers to look for potentially more damaging code quality issues. \n\nAlthough testing is one of the most dramatic automation “wins” in DevOps, it’s far from the only one. [Continuous integration](/topics/ci-cd/) automates the process of moving new code into existing code, while [continuous deployment](/blog/how-to-keep-up-with-ci-cd-best-practices/) helps automate releases. And [Infrastructure as Code](/topics/gitops/infrastructure-as-code/) makes it easy to automate the process of provisioning developer environments. \n\n### Collaboration and communication\n\nA good DevOps team has automation, but a top-notch DevOps team also has collaboration and communication. The basic idea of bringing dev and ops together (as well as sec, test, stakeholders, etc.) hinges on teams being able to collaborate. And that can’t happen if there isn’t clear and regular communication.\n\nThis sounds like a deceptively simple principle of DevOps, but, like most things, the devil is in the details. Devs want to write code and move it along into the world; ops professionals focus on tools, compliance, and the cloud; and the security team wants to ensure the code is safe. Dev, ops, and sec don’t have the same priorities, might not speak the same “language,” and are likely to approach problem-solving from very different perspectives. A case in point: [Dev and sec still don’t really get along](/blog/developer-security-divide/), in part because the communication and collaboration gap remains wide.\n\nIt takes effort to bring teams together and often [out-of-the-box thinking](/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together/). And in one of those \"chicken and egg\" situations, teams need to communicate for successful DevOps, but DevOps itself can lead to better communication, and happier developers, according to findings in our [2021 Global DevSecOps Survey](/developer-survey/).\n\n### Continuous improvement and minimization of waste\n\nLeaning heavily on earlier software development methodologies, including [Lean](https://searchsoftwarequality.techtarget.com/definition/lean-programming) and Agile, DevOps also focuses on reducing waste and continuous improvement. Whether it’s automating repetitive tasks like testing so as not to waste time, or reducing the number of steps required to release new code, well-functioning DevOps teams continue to measure performance metrics to determine areas that need improvement. \n\nExpect teams to strive [to continuously improve release times](/blog/why-improving-continuously-speeds-up-delivery/), reduce the [mean-time-to-recovery](https://pipelinedriven.org/article/devops-metric-mean-time-to-recovery-mttr-definition-and-reasoning), and number of bugs found, in addition to a number of other metrics. \n\n### Hyperfocus on user needs with short feedback loops\n\nThe final must-know DevOps principle is the importance of bringing the actual user into every step of this process. Through automation, improved communication and collaboration, and continuous improvement, DevOps teams can take a moment and focus on what real users really want, and how to give it to them. There’s no question that finding a way into the user mind is quite tricky, and [teams can struggle to implement processes](/blog/journey-to-the-outer-loop/) to achieve this. \n\nThe other difficult piece of this is that user feedback, once gathered, must be delivered quickly so time isn’t wasted. That’s why short feedback loops are critical, and why teams need to [put energy into making them even shorter](/blog/journey-to-the-outer-loop/) as time goes on. \n\n## Benefits of a DevOps model and practices\n\nWhat happens if teams do DevOps right? In our 2021 survey, 60% of developers told us they were releasing code at least 2x faster, thanks to DevOps. Other benefits of a DevOps model include improved code quality, faster time to market, and better planning. \n\nAnd for bonus points, survey takers told us that having a successful DevOps practice also made for happier developers, and there’s [scientific data](/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen/) that shows happier devs are more productive. \n\n## What are some challenges of implementing DevOps?\n\nDevOps can be challenging in the begining, particularly if it’s the first time being implemented within an organization. Here are some of the challenges of implementing DevOps. \n\n* **Breaking down the silos.** It may be difficult to break the mentality of development and operations being separate entities. Gather a basic understanding of the roles and responsibilities of a combination DevOps team.\n\n* **Understanding the jargon.** DevOps comes with a lot of shorthand, tech jargon, and SO many acronyms, like CI/CD. Take some time to study and remember that learning on the go is entirely normal and acceptable. \n\n* **Migrating from legacy software.** DevOps can be especially tricky for teams trying to migrate legacy software. Many tools designed for DevOps don’t work with mainframes (as one example) and integrations can be challenging even for experienced DevOps pros. It also doesn’t help that there’s a shortage of mainframe and other legacy programmers.\n\n* **Too many tools.** Teams spend so much time integrating and maintaining tools it’s getting in the way of actually developing, releasing and monitoring code. This is commonly known as the “toolchain tax.”\n\n* **Taming the learning curve frustration.** DevOps is complicated, and learning how it works is a marathon, not a sprint. Practice patience and grace with the team as implementation goes forward and rely on any resources available, such as help documentation and platform representatives – and sometimes plain old trial and error.\n\n## How to get started with DevOps in your organization\n\nWhen preparing to get started with DevOps, the following preperation is required:\n\n1. Map out the goals behind DevOps implementation.\n2. Clarify the roles and responsibilities of each stakeholder involved.\n3. Start basic and grow with experience.\n4. Plam to automate as much as possible.\n5. Plan your toolchain (and remember, toolchains can always be altered).\n6. Set up regular progress checkpoints.\n7. Be prepared to constantly iterate (but after giving something enough time to prove that iterating is necessary). \n\n## What is the future of DevOps?\n\nDevOps adoption and success experienced an enormous “jumpstart” thanks to the global pandemic. Teams moved past some of the cultural “how do we work together?” issues and matured into the “how do we adopt the right technologies?” mindset, based on results from our survey. Use of advanced technologies, including Kubernetes, [DevOps platforms](/topics/devops-platform/), and artificial intelligence (AI)/machine learning (ML) give hints as to what the future of DevOps looks like. \n\nIt’s safe to expect increased automation, smarter AI/ML-powered decision making (starting in places like [code review](/blog/the-road-to-smarter-code-reviewer-recommendations/) and a more thoughtful choice of tools, such as continuing adoption of DevOps platforms to streamline the process.","insights",[695,9,232],"DevOps",{"slug":697,"featured":6,"template":698},"4-must-know-devops-principles","BlogPost","content:en-us:blog:4-must-know-devops-principles.yml","4 Must Know Devops Principles","en-us/blog/4-must-know-devops-principles.yml","en-us/blog/4-must-know-devops-principles",{"_path":704,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":705,"content":711,"config":718,"_id":720,"_type":13,"title":721,"_source":15,"_file":722,"_stem":723,"_extension":18},"/en-us/blog/5-things-i-learned-during-my-30-day-internship-with-gitlab-s-data-team",{"title":706,"description":707,"ogTitle":706,"ogDescription":707,"noIndex":6,"ogImage":708,"ogUrl":709,"ogSiteName":685,"ogType":686,"canonicalUrls":709,"schema":710},"5 Things I Learned During My Summer Internship with GitLab's Data Team","Key lessons learned during my summer internship","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/5-things-i-learned-during-my-30-day-internship-with-gitlab-s-data-team","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 Things I Learned During My Summer Internship with GitLab's Data Team\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Eugenia Hannon\"}],\n \"datePublished\": \"2019-08-22\",\n }",{"title":706,"description":707,"authors":712,"heroImage":708,"date":714,"body":715,"category":716,"tags":717},[713],"Eugenia Hannon","2019-08-22","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n```\nThat is the beginning of knowledge - the discovery of something we do not understand.\n-Leto Atreides II, God-Emperor of Dune\n```\n\n\n## 1. The IRL Mentor\n\n[Asynchronous communication](https://handbook.gitlab.com/handbook/communication/) is the future; it simultaneously puts everyone on the same page and, in order to work well, requires everybody to be on the same page. This takes some time to get the hang of, since our present-day lives are, for the most part, synchronous. I live in the same city as my Internship Manager, [Emilie](https://gitlab.com/emilie), and I believe that was crucial to my success as an intern. Having Emilie as part of both my synchronous and asynchronous life helped me merge the two together in a way that allowed me to learn and do a lot during my short time at GitLab.\n\nBasically, if we understand that Tech has its own [language](https://en.wikipedia.org/wiki/Semiotics), having Emilie to mentor me in person was like spending time with a native-speaker. I was able to see how her tech skills are an integral part of the way she thinks, and she doesn’t waste time second-guessing herself. She also taught me that that is a learned skill--so often we assume folks are born-with-it, but Emilie took the time to illustrate how discipline is the foundation of confidence. Confidence takes time to cultivate asynchronistically, especially if you’re at all prone to Imposter Syndrome, so an IRL mentor like her served as a great example for me.\n\n## 2. Schedule, Schedule, Schedule!\n\nBeing a part of a remote workplace means you have to [schedule](https://www.youtube.com/watch?v=1EjJ55BODn0) everything--especially social calls! I had some great [coffee chats](/company/culture/all-remote/tips/#coffee-chats) with folks from around the world, and it really helped me understand how GitLab works on a macro level. People > product, and productive people run on schedules. This isn’t something I was completely unaware of, but I knew it as well as I know I how to eat a balanced diet with plenty of fresh fruits and veggies (I don’t). It’s not a pattern I had ingrained in me beforehand, because I’ve either flexible work schedules or little-to-no follow-up on projects, so this was, again, something I had to [learn](https://boingboing.net/2015/05/11/the-only-technique-to-learn-so.html).\n\n## 3. Mistake-Making\n\nAs an intern, any [mistake](https://imgflip.com/memetemplate/152344231/Oops-All-Berries) I was capable of making didn’t have any negative ripple effects to any part of the Data Team, so I took that opportunity and ran with it. Throughout my mistake-making, it was reiterated that this was the foundation of learning, an essential part of being human and working with data, and that it didn’t reflect my actual skills or ability. The GitLab Data Team was such a solid team to learn with because they all understood the initial rush of adrenaline and shame that goes along with mistake-making, and they also carried the wisdom of folks who have made mistakes when the stakes were higher--not intern-level, but full-time. Having their support was not only very encouraging, but also helped to develop my mistake-making skills. I’d say I’m about [Bard level](https://screenrant.com/dungeons-dragons-dnd-classes-ranked-power/) in my own personal mistake-making RPG.\n\nThis is my major mistake-making takeaway: the language of tech is [polysemic](https://en.wikipedia.org/wiki/Polysemy), and breaking down denotation versus connotation required a lot of me breaking things. I’ve spent a lot of time with semiotics and much less time with SQL queries, but I found a lot of the same rules apply. There’s generally something non-verbal that’s connoted with ideas that are literally denoted--typed, spoken, etc--and that connotation gets lost in the crosshairs of data. Data is deliberate, but language is inherently unstable, so miscommunication happens, and mistakes are a part of learning how to be a better data analyst. I will never get to a point where I won’t make mistakes--I’ll just be making new, different ones, perhaps less regularly, but they will always be a part of my life.\n\n## 4. Take a Break - The Work isn’t Going Anywhere\n\nThe danger of [burnout](/handbook/paid-time-off/#recognizing-burnout), especially with remote work, is [well documented](/blog/preventing-burnout/) at GitLab. Strong measures are taken to prevent burnout, since you could, in theory, work around the clock if you really wanted to (or felt like it was necessary). I got that in theory, sure, but when I had an ear infection that brought along weird vertigo-like symptoms during the first part of my internship, I felt incredibly guilty for taking days off. I remember shamefully telling Emilie I hadn’t made any progress because I wasn’t feeling well, and that I felt bad, or like I was slacking, or something, and then we had a [Luke-Yoda](https://www.youtube.com/watch?v=E3-CpzZJl8w) moment I’ll never forget: _Please, don’t let that concern you. The work will be here when you’re ready._\n\nAh! That was such an important lesson that I’m sure I’ll be re-learning in various capacities for the rest of my life, but in that exact moment, it was a slack-jawed realization of the best kind. The work will be here when I’m ready! ‘Pushing through’ illness of any kind isn’t what the work is about, and, really, only makes you prone to fuzzy thinking and more mistakes. Even though time happens simultaneously in an asychronistic workplace doesn’t mean that you have to happen simultaneously. We haven’t reached that [dimension](https://www.youtube.com/watch?v=Y90xNI6DyY8) yet.\n\n## 5. Change: The Only Constant\n\nData is [alive](https://www.youtube.com/watch?v=QuoKNZjr8_U). When you’re a data analyst, you need to cultivate an intimate relationship with your data. You have to care for it, tend to it, teach it, help it, develop it, watch it, play with it, get angry with it, love it. It might not always tell you what you want to hear, or do what you want it to do, but it always tells the truth. Just like people, no data set is perfect, and you have to work with it in order to get the information you want, or the task you want it to perform. GitLab is itself an agent of change, a tool for tracking changes and making improvements, pulsing with activity, always updating, alive. GitLab taught me that it’s all a process--beyond the literal beginnings and endings, life is just a series of commits to the Master Branch, so make your [README.mds](https://en.wikipedia.org/wiki/README) good, push, pull, and prosper.\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/qy3MBVaGHz8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n","unfiltered",[9,268],{"slug":719,"featured":6,"template":698},"5-things-i-learned-during-my-30-day-internship-with-gitlab-s-data-team","content:en-us:blog:5-things-i-learned-during-my-30-day-internship-with-gitlab-s-data-team.yml","5 Things I Learned During My 30 Day Internship With Gitlab S Data Team","en-us/blog/5-things-i-learned-during-my-30-day-internship-with-gitlab-s-data-team.yml","en-us/blog/5-things-i-learned-during-my-30-day-internship-with-gitlab-s-data-team",{"_path":725,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":726,"content":732,"config":739,"_id":741,"_type":13,"title":742,"_source":15,"_file":743,"_stem":744,"_extension":18},"/en-us/blog/5-ways-collaboration-boosts-productivity-and-your-career",{"title":727,"description":728,"ogTitle":727,"ogDescription":728,"noIndex":6,"ogImage":729,"ogUrl":730,"ogSiteName":685,"ogType":686,"canonicalUrls":730,"schema":731},"5 ways collaboration boosts productivity and your career","Collaboration is a powerful tool and DevOps pros that learn how to master it will expand their growth opportunities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668473/Blog/Hero%20Images/john-schnobrich-FlPc9_VocJ4-unsplash.jpg","https://about.gitlab.com/blog/5-ways-collaboration-boosts-productivity-and-your-career","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 ways collaboration boosts productivity and your career\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-05-02\",\n }",{"title":727,"description":728,"authors":733,"heroImage":729,"date":735,"body":736,"category":737,"tags":738},[734],"Sharon Gaudin","2022-05-02","\n\nA lot of DevOps professionals might feel confident they’ve got a lock on their DevOps role. They don’t need anyone else chiming in on how to update a software feature or plan a new product.\n\nOther DevOps pros want to focus on learning new programming languages or figuring out how best to use machine learning. They think they don’t have time for so-called soft skills like [communication and collaboration](/blog/six-key-practices-that-improve-communication/).\n\nAt its heart, DevOps is collaboration. It’s a team sport. Of course, staying sharp with hard skills like machine learning, new programming languages, and other cutting-edge technology is fantastic, but don’t ignore soft skills. Enabling teamwork is a [cornerstone of DevOps](/blog/4-must-know-devops-principles/).\n\nMaking this cultural shift means teammates are all pulling in the same direction. It means more, and more diverse, input leads to better, well-rounded products and software. And it also means career development.\n\nHere’s a look at just a few ways a [culture of collaboration](/blog/collaboration-communication-best-practices/) can benefit a DevOps team, software development and deployment, and DevOps professionals’ careers.\n\n## Boosting DevOps professionals’ careers\n \nIt’s clear that [companies are increasingly dependent](/blog/the-top-skills-you-need-to-get-your-devops-dream-job/) on DevOps professionals who are able to not only work with various teams, but who also are able to clearly communicate with colleagues in other departments, like finance and marketing. The [2021 Global DevSecOps Survey](https://learn.gitlab.com/c/2021-devsecops-report?x=u5RjB_) reported that IT professionals working in development, security, and operations all said they need better communication and collaboration skills for their future careers. And nearly 23% said these soft skills will give the biggest boost to their careers. Being able to work across departments, clearly communicate needs and ideas, and work together to innovate better products makes a tech person more valuable to the overall company, leading to [management roles and higher salaries](/blog/soft-skills-are-the-key-to-your-devops-career-advancement/).\n\n## Using the buddy system to iterate faster\n\nThe bedrock of a [DevOps culture is collaboration and joint responsibility](/blog/if-its-time-to-learn-devops-heres-where-to-begin/). And for good reason, because better cooperation leads to more, and more efficient, continuous, iterative development and feature deployment. Cooperation makes a DevOps team more agile so it can adapt to changes in projects and workloads. \n\nWith traditional application development, managers, developers, security professionals, and those on the operations team generally work in silos. They don’t communicate readily or well. They don’t work together on projects or share documentation and knowledge. With DevOps, though, those silos begin to be broken down. And by joining forces, teammates can pool efforts to assess problems, envision solutions, and create and deploy high-quality applications from a single end-to-end application. Breaking down those silos fosters better decision-making and creativity, and increases information and resource sharing. \n\n## Creating better products\n\nBy creating partnerships, DevOps teams are able to more quickly adjust to changing market needs and take on new competitors. Sharing data, and the workload, across disparate teams also empowers them to find out what customers need, what delights them, and the features that need to be created. More input from people with different perspectives and different backgrounds means a company will get software with features that speak to a wider range of users. All of this leads to better products, and that leads to a stronger business.\n\n## Pulling different business teams together\n\nFostering cooperation isn’t just for DevOps team members. A truly collaborative culture also should include colleagues in different parts of the company. Members of the security team, marketing, finance, customer service, and the C-suite all can participate to create better software. Collaboration between DevOps and security, for instance, leads to less duplication of effort, more secure software, and a more secure company. Similarly, someone in customer service would have direct insights into what users like, and don’t like, about current products. Integrating their feedback into ongoing processes will provide the ability to leverage their expertise before code is delivered. \n\n## Taking advantage of everyone’s expertise\n\nBy inviting discussion, input, and assistance from experienced and new team members, as well as from people in different business departments, a culture can be built around learning from and relying on others’ expertise. This enables DevOps professionals to discover other perspectives and contribute beyond what might have once been a narrow focus. Think of everyone’s knowledge and experience as pieces of a shared resource library that can be tapped into for every project.\n \n\n","careers",[695,737,9],{"slug":740,"featured":6,"template":698},"5-ways-collaboration-boosts-productivity-and-your-career","content:en-us:blog:5-ways-collaboration-boosts-productivity-and-your-career.yml","5 Ways Collaboration Boosts Productivity And Your Career","en-us/blog/5-ways-collaboration-boosts-productivity-and-your-career.yml","en-us/blog/5-ways-collaboration-boosts-productivity-and-your-career",{"_path":746,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":747,"content":753,"config":760,"_id":762,"_type":13,"title":763,"_source":15,"_file":764,"_stem":765,"_extension":18},"/en-us/blog/7-tips-on-how-to-successfully-talk-to-execs-about-devsecops",{"title":748,"description":749,"ogTitle":748,"ogDescription":749,"noIndex":6,"ogImage":750,"ogUrl":751,"ogSiteName":685,"ogType":686,"canonicalUrls":751,"schema":752},"7 tips on how to successfully talk to execs about DevSecOps","If you want to begin using DevSecOps to improve software development, you need to get business executives behind your plan. Here are tips to do just that.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670694/Blog/Hero%20Images/how-to-keep-remote-teams-engaged-cover.jpg","https://about.gitlab.com/blog/7-tips-on-how-to-successfully-talk-to-execs-about-devsecops","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"7 tips on how to successfully talk to execs about DevSecOps\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2023-07-12\",\n }",{"title":748,"description":749,"authors":754,"heroImage":750,"date":755,"body":756,"category":757,"tags":758},[734],"2023-07-12","\nIf you want to begin using DevSecOps to speed, secure, and improve software development, you need to get business executives behind your plan. But talking with leadership – especially C-suite executives – isn’t always easy.\n\nSoftware development teams want to use DevSecOps because it will reduce hands-on work, make the development process more efficient, [foster collaboration](/blog/5-ways-collaboration-boosts-productivity-and-your-career/), [improve security](/the-source/security/how-to-strengthen-security-by-applying-devsecops-principles/), and speed development and deployment. Getting executives to understand how that all translates into [business benefits](/blog/five-essential-business-benefits-a-devops-platform-gives-smbs/) is the key here. That’s what will spur them to OK a DevSecOps adoption.\n\n> **Be sure to download our latest guide *[How to drive business success with DevSecOps](https://page.gitlab.com/resources-ebook-devsecops-success.html?utm_campaign=devsecopsplat&utm_content=ebookdevsecopssuccess)* for more advice.**\n\nTo help executives understand the technical and business benefits of [DevSecOps](/blog/its-time-to-put-the-sec-in-devsecops/) there are pitfalls you’ll need to avoid, as well as things you should make sure you do and discuss. Let’s dive into 7 things to consider right from the start.\n\n## 1. Know your audience\nEveryone is different. Some executives want every little detail. Others want a quick overview. And if, for instance, you’re talking with a CEO, focus on reducing costs and how more efficient and faster production can boost revenue and improve time to market. For CIOs, focus on productivity and efficiency. Tell them how automation and artificial intelligence (AI) features will save teams time and hands-on work.\n\n## 2. Find a champion\nIf you’re going to be walking into a boardroom packed with C-suite executives or having a small meeting with a CEO, it helps to have backup. Find an executive who knows the language of business and key business drivers and pitch the idea of using DevSecOps to get her backing. Then she can help you make the pitch to other executives.\n\n## 3. Make sure you have a plan\nBefore talking to an executive, you first need to draft a plan. Create a basic outline that gives you guidance about the key points to touch on, but also leaves room to take questions and feedback. Make sure you listen as much as you talk. Meetings are learning opportunities.\n\n## 4. Don’t geek out on the tech\nRemember that you are talking to business people. It’s easy for a technical person to fall back on using technical lingo and talking about the excitement of using the shiniest tools. But that’s not going to get someone far with most executives. Even a CTO, who is a technical person, is focused on the business – and how any technology is going to support that business or weigh it down. Don't use technical jargon or acronyms. Convey engineering objectives into a language of profit and loss. Tell execs why migrating to a DevSecOps platform will make the software development team, and the company as a whole, more successful.\n\n## 5. Do your homework\nIf you work for a public company, listen to the quarterly reports to learn about immediate business objectives and long-term strategic goals. Have a coffee chat with or shadow someone who works in financial planning, analysis, and/or accounting. Learn from your colleagues how the company makes money and what its business needs are. Understand challenges, like security issues, [compliance issues](/blog/top-5-compliance-features-to-leverage-in-gitlab/), or competitors coming out with new features faster. Then address those challenges. Make sure your presentation focuses on the company’s specific needs and any potential future challenges.\n\n“I would recommend always starting by figuring out the business needs first,” says [Fatima Sarah Khalid](https://gitlab.com/sugaroverflow), developer evangelist at GitLab. “How does this bring value to the organization’s customers and how does this impact the company? Will it save money, unlock a new customer segment, open up new channels, or boost production and efficiency? These are the kind of strategic levers that are most helpful for leadership to hear.”\n\n## 6. Focus on benefits to the executives\nOf course, executives will want to know how DevSecOps will benefit the business that they’re running, but they’ll also want to know how it can benefit them and the specific job they’re doing. Let executives know that a DevSecOps platform will give them visibility into the entire software development lifecycle so they can see where projects slow down or progress, giving them more insight and control. And make it clear that an end-to-end platform fosters a culture where everyone, from customer service to marketing and the C-suite, can collaborate.\n\n## 7. Don’t forget the money\nAs you plan out what to talk about with executives and what business challenges to focus on, remember that money always has to be part of the conversation. Since you likely will be reducing a complex and costly toolchain with the adoption of a DevSecOps platform, estimate the savings in both cost and time that will come from cutting that toolchain. Point out the savings, in terms of money and brand image, by reducing security vulnerabilities. Management also is going to want you to estimate how much it will cost to migrate to a platform, along with the human hours needed, and an adoption timeline.\n\n“Tech people can never forget that executives are very focused on ROI,” says [Ayoub Fandi](https://gitlab.com/ayofan), senior field security engineer at GitLab. “It’s always a central issue. They need to understand if any decision will bring them closer to their business goals. Adopting a DevSecOps platform can be a massive cost reduction. Each year companies spend more money on IT so if they can learn a way to spend less, it’ll be very welcome information.”\n\nRemember that leadership likely is looking for reasons to say yes. You just need to provide them with those reasons – and make sure they’re solid business reasons. Make it clear what an adoption will look like in practice. Show them [case studies](/customers/) of other companies that have made the move.\n\nAnd the impact of enabling executives to understand the benefits of DevSecOps go beyond a single adoption. Learning how to understand an organization’s business needs and strategy, and learning the language of business are [great skills for anyone in tech](/blog/best-advice-for-your-devops-career-keep-on-learning/) to have. Continuing to educate yourself and pursuing knowledge on the business side are top ways to increase your standing in your company, your hireability, and [your paycheck](/blog/four-tips-to-increase-your-devops-salary/).\n\nGet even more advice in our our latest guide *[How to drive business success with DevSecOps](https://page.gitlab.com/resources-ebook-devsecops-success.html?utm_campaign=devsecopsplat&utm_content=ebookdevsecopssuccess)*, available for download now.\n","devsecops",[759,9,737],"DevSecOps",{"slug":761,"featured":6,"template":698},"7-tips-on-how-to-successfully-talk-to-execs-about-devsecops","content:en-us:blog:7-tips-on-how-to-successfully-talk-to-execs-about-devsecops.yml","7 Tips On How To Successfully Talk To Execs About Devsecops","en-us/blog/7-tips-on-how-to-successfully-talk-to-execs-about-devsecops.yml","en-us/blog/7-tips-on-how-to-successfully-talk-to-execs-about-devsecops",{"_path":767,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":768,"content":774,"config":788,"_id":790,"_type":13,"title":791,"_source":15,"_file":792,"_stem":793,"_extension":18},"/en-us/blog/a-benchmarking-framework-for-sast",{"title":769,"description":770,"ogTitle":769,"ogDescription":770,"noIndex":6,"ogImage":771,"ogUrl":772,"ogSiteName":685,"ogType":686,"canonicalUrls":772,"schema":773},"A Google Summer of Code project: creating a benchmarking framework for SAST","Our 2022 Google Summer of Code project helped to create a benchmarking framework for SAST.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677267/Blog/Hero%20Images/benchmarking.png","https://about.gitlab.com/blog/a-benchmarking-framework-for-sast","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"A Google Summer of Code project: creating a benchmarking framework for SAST\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Henriksen\"},{\"@type\":\"Person\",\"name\":\"Martynas Krupskis\"},{\"@type\":\"Person\",\"name\":\"Mark Art\"},{\"@type\":\"Person\",\"name\":\"Dinesh Bolkensteyn\"},{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"},{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n \"datePublished\": \"2022-09-27\",\n }",{"title":769,"description":770,"authors":775,"heroImage":771,"date":782,"body":783,"category":784,"tags":785},[776,777,778,779,780,781],"Michael Henriksen","Martynas Krupskis","Mark Art","Dinesh Bolkensteyn","Isaac Dawson","Julian Thome","2022-09-27","In summer 2022, the [Vulnerability Research team at\nGitLab](/handbook/engineering/development/sec/secure/vulnerability-research/) \n\nlaunched the [Google Summer of Code\n(GSoC)](https://summerofcode.withgoogle.com/) project: \n\n[A benchmarking framework for\nSAST](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gsoc-2022/-/issues/1).\n\n\nThe goal of the project was to create a benchmarking framework, which would\nassess the\n\nimpact and quality of a security analyzer or configuration change before it\nreaches the production environment.\n\n\n## Preliminaries \n\n\n### GitLab SAST\n\n\nAs a complete DevOps Platform, GitLab has a variety of integrated [static\nanalysis (SAST) tools](/direction/secure/static-analysis/sast/) \n\nfor different languages and frameworks. These tools help developers find\n\nvulnerabilities as early as possible in the software development lifecycle.\n\nThese tools are constantly being updated, either by upgrading the underlying\n\nsecurity analyzers or by applying configuration changes.\n\n\nSince all the integrated SAST tools are very different in terms of\n\nimplementation, and depend on different tech stacks, they are all\n\nwrapped in Docker images. The wrappers translate tool-native vulnerability\n\nreports to a [generic, common report\nformat](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format)\nwhich is\n\nmade available by means of the `gl-sast-report.json` artifact. This generic\n\nreport is GitLab's common interface between analyzers and the GitLab Rails\n\nbackend.\n\n\nBenchmarking is important to assess the efficacy of analyzers and helps to\nmake\n\ndata-driven decisions. For example, benchmarking is useful for QA testing\n\n(spotting regressions), for data-driven decision making, and for research by\n\nassessing the progression of the GitLab security feature performance over\ntime.\n\n\n### Google Summer Of Code (GSoC)\n\n\n[Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/) \n\nis a 10-week program that enlists contributors to work on open source\nprojects\n\nin collaboration with open source organizations. For GSoC 2022, GitLab\noffered\n\nfour projects to GSoC contributors. The contributors completed each of the\n\nprojects with the guidance from GitLab team members who mentored them and\n\nprovided regular feedback and assistance when needed.\n\n\n### Terms & Notation\n\n\nIn this blog post, we use the terms/acronyms below to classify findings\nreported by security analyzers.\n\n\n| Acronym | Meaning |\nDescription |\n\n|-------|----------------|--------------------------------------------------------------------|\n\n| _TP_ | True Positive | Analyzer correctly identifies a\nvulnerability. |\n\n| _FP_ | False Positive | Analyzer misidentifies a vulnerability or\nreported a vulnerability where none exist. |\n\n| _TN_ | True Negative | Analyzer correctly ignores a potential false\npositive. |\n\n| _FN_ | False Negative | Analyzer does not report a known\nvulnerability. |\n\n\nFor the figures in the blog post we use the following notation: processes\nare\n\ndepicted as rounded boxes, whereas artifacts (e.g., files) are depicted as\n\nboxes; arrows denote an input/output (IO) relationship between the connected\nnodes.\n\n\n``` mermaid\n\nflowchart TB;\n\nsubgraph legend[ Legend ]\n proc(Process);\n art[Artifact];\n proc -->|IO relation|art;\nend\n\n``` \n\n\n## Motivation\n\n\nThe authors of the paper [How to Build a\nBenchmark](https://dl.acm.org/doi/10.1145/2668930.2688819) distilled the\ndesirable characteristics of a benchmark below:\n\n> 1. Relevance: How closely the benchmark behavior correlates to behaviors\nthat are of interest to consumers of the results.\n\n> 2. Reproducibility: The ability to consistently produce similar results\nwhen the benchmark is run with the same test configuration.\n\n> 3. Fairness: Allowing different test configurations to compete on their\nmerits without artificial limitations.\n\n> 4. Verifiability: Providing confidence that a benchmark result is\naccurate.\n\n> 5. Usability: Avoiding roadblocks for users to run the benchmark in their\ntest environments.\n\n\nThere currently is no standard nor de facto language-agnostic SAST benchmark\n\nsatisfying all the criteria mentioned above. Many benchmark suites focus on\n\nspecific languages, are shipped with incomplete or missing ground-truths, or\n\nare based on outdated technologies and/or frameworks. A ground-truth or\n\nbaseline is the set of findings a SAST tool is expected to detect.\n\n\nThe main objective of the GSoC project was to close this gap and start to\n\ncreate a benchmarking framework that addresses all the desirable\ncharateristics\n\nmentioned above in the following manner:\n\n\n1. Relevance: Include realistic applications (in terms of size, framework\nusage\n and customer demand).\n2. Reproducibility: Automate the whole benchmarking process in CI.\n\n3. Fairness: Make it easy to integrate new SAST tools by just tweaking the\nCI\n configuration and use the [GitLab security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format) as a common standard.\n4. Verifiability: Assemble baseline that includes all the relevant\n vulnerabilities and make it publicly available. The baseline is the north star\n that defines what vulnerabilities are actually included in a test application. \n5. Usability: Benchmark users can just integrate the benchmark as a\ndownstream\n pipeline to their CI configuration.\n\n## A benchmarking framework for SAST\n\n\nThe benchmarking framework compares the efficacy of an analyzer against a\nknown\n\nbaseline. This is very useful for monitoring the efficacy of the analyzer\nthat\n\nparticipates in the benchmarking. The baseline is the gold standard that\nserves\n\nas a compass to guide analyzer improvements.\n\n\n### Usage\n\n\nFor using the framework, the following requirements have to be met:\n\n1. The analyzer has to be dockerized.\n\n1. The analyzer has to produce a vulnerability report that adheres to the\n [GitLab security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format)\n format, which serves as our generic intermediate representation to compare\n analyzer efficacy. \n1. The baseline expectations have to be provided as \n [GitLab security report schema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format)\n so that we can compare the analyzer output against it. \n\nThe framework is designed in such a way that it can be easily integrated\ninto\n\nthe CI configuration of existing GitLab projects by means of a [downstream\npipeline](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n\nThere are many possible ways in which a downstream pipeline can be\ntriggered:\n\nsource code changes applied to an analyzer, configuration changes\n\napplied to an analyzer, or scheduled pipeline invocation. By using the\npipeline,\n\nwe can run the benchmarking frameworks continuously and instantaneously on\nthe GitLab\n\nprojects that host the source code of the integrated analyzers whenever code\nor\n\nconfiguration changes are applied. \n\n\n### Architecture \n\n\nThe figure below depicts the benchmarking framework when comparing an\nanalyzer\n\nagainst a baseline.\n\n\nWe assume that we have a baseline configuration available; a baseline\nconsists\n\nof an application that is an actual test application that includes\n\nvulnerabilities. These vulnerabilities are documented in an expectation file\n\nthat adheres to the [security report\nschema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format).\n\n\nNote that we use the terms baseline and expectation interchangeably. As\n\nmentioned earlier, the benchmarking framework is essentially a GitLab\npipeline\n\nthat can be triggered downstream. The configured analyzer then takes the\n\nbaseline app as input and generates a `gl-sast-report.json` file. The heart\nof the\n\nbenchmarking framework is the `compare` step, which compares the baseline\n\nagainst the report generated by the analyzer, both of which adhere to the\n\n[security report\nschema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format).\n\n\nThe compare step also computes the _TP_, _FN_ and _FP_ that have been\nreported by the\n\nanalyzer and computes different metrics based on this information. The\ncompare\n\nstep is implemented in the\n\n[evaluator\ntool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator). \n\n\n``` mermaid\n\nflowchart LR;\n\nsbx[gl-sast-report.json];\n\nbreport[Report];\n\nconfig[Configuration];\n\n\nconfig --> bf;\n\n\nsubgraph Baseline\n bcollection[app];\n baseline[expectation];\nend\n\n\nsubgraph bf [ Benchmarking Framework ]\n orig(Analyzer);\n compare(Compare);\n orig --> sbx;\n sbx --> compare;\nend\n\n\nbaseline --> compare;\n\ncompare --> breport\n\nbcollection --> orig\n\n```\n\n\nUsing the security report format as a common standard makes the benchmarking\n\nframework very versatile: the baseline could be provided by an automated\n\nprocess, by another analyzer, or manually, which happened to be the case in\nthis\n\nGSoC project.\n\n\n### Scoring\n\n\nThe main functionality of the [evaluator\ntool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\n\nis to compute the overlap/intersection, and difference between a baseline\nand\n\ngenerated report in order to uncover true positives, false positives, and\nfalse\n\nnegatives. \n\n\nThe relationship between _TP_, _FP_, _FN_, _TN_, baseline, and generated\nreport can be\n\nseen in the table below; it includes three columns `analyzer`, `baseline`\nand\n\n`classification`. The column `analyzer` represents the findings included in\nthe\n\nreport generated by the analyzer; column `baseline` represents the findings\n\nincluded in the baseline; column `classification` denotes the\n\nverdict/classification that the [evaluator\ntool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\n\nattaches to the analyzer finding when performing the comparison. The `X` and\n\n`-` denote reported and non-reported findings, respectively.\n\n\n| analyzer | baseline | classification |\n\n| -------- | ------- | ------------- |\n\n| - | - | _TN_ |\n\n| - | X | _FN_ |\n\n| X | - | _FP_ |\n\n| X | X | _TP_ |\n\n\nThe `classification` column in the table above shows that a _TP_ is a\n\nvulnerability existing in both baseline and generated report; similarly, an\n\n_FP_ is a vulnerability detected by an analyzer without a corresponding\n\nbaseline entry, while an _FN_ is a vulnerability present in the baseline but\n\nnot detected by an analyzer. Note, that _TN_ is practically not relevant for\n\nour use-case since the analyzers we are looking at only report unsafe,\n\nvulnerable cases instead of safe, non-vulnerable cases. \n\n\nAt the moment, the `evaluator` tool computes the metrics below:\n\n- Precision: _P_ = _TP_ /( _TP_ + _FP_ )\n\n- Recall: _R_ = _TP_ / ( _TP_ + _FN_ )\n\n- F-Score: _F_ = 2 * ( _P_ * _R_ ) / ( _P_ + _R_ ) \n\n- Jaccard-Index: _J_ = _TP_ / ( _TP_ + _FP_ + _FN_ )\n\n\nA higher precision indicates that an analyzer is less noisy due to the\nlow(er)\n\nnumber of _FPs_. Hence, a high precision leads to a reduction of auditing\neffort\n\nof irrelevant findings. A high recall represents an analyzer's detection\n\ncapacity. F-Score is a combined measure so that precision and recall can be\n\ncondensed to a single number. The Jaccard-Index is a single value to capture\n\nthe similarity between analyzer and baseline.\n\n\nThe [evaluator\ntool](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\n\nsupports the addition of custom metrics via a simple call-back mechanism;\nthis\n\nenables us to add support more metrics in the future that help us to gain\n\nadditional or new insights with regards to the efficacy of our analyzers.\n\n\n### Framework Properties\n\n\nIn principle, the implemented benchmarking framework is language-agnostic:\nnew\n\nanalyzers and baselines can be plugged-in as long as they adhere to the\n\n[security report\nschema](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format). \n\n\nEstablishing baselines is laborious since it requires (cross-)validation, \n\ntrying out attacks on the running baseline application and\n\ncode auditing.\n\n\nFor the GSoC project, we established baselines for the applications below\n\ncovering Java ([Spring](https://spring.io/)) and Python\n\n([Flask](https://flask.palletsprojects.com/)) as they are [ranking high in\nthe most used languages and\nframeworks](https://survey.stackoverflow.co/2022/#technology-most-popular-technologies). \n\nFor a benchmark application to have practical utility, it is important that\nthe\n\napplication itself is based on technology, including programming languages\nand\n\nframeworks, that are used in the industry.\n\n\nFor both of these applications, the baseline/expectations have been\ncollected,\n\nverified and are publicly availabe: \n\n-\n[WebGoat](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/WebGoat/-/tree/baselines). \n WebGoat is a deliberately insecure Web application used to teach security vulnerabilities.\n We chose this as baseline application because it is often used as a benchmark\n app in the Java world and it is based on [Spring](https://spring.io/) which is\n one of the most popular frameworks in the Java world. \n-\n[vuln-flask-web-app](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/vuln-flask-web-app/-/tree/report)\nLike WebGoat, this application is deliberately insecure.\n`vuln-flask-web-app` covers both Python and\n[Flask](https://flask.palletsprojects.com/en/2.2.x/), one of the most\npopular web frameworks in the Python world.\n\n\n## Conclusion\n\n\nThis GSoC project was a first step towards building a FOSS benchmarking\n\nframework that helps the community to test their own tools and to build up a\n\nrelevant suite of baselines covering various languages and frameworks. With\nthe\n\nhelp of the community, we will continue adding more baselines to the\n\nbenchmarking framework in the future to cover more languages and frameworks.\n\n\nIf you found the project interesting, you might want to check out the\nfollowing repositories:\n\n\n-\n[evaluator](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator)\n\n- [WebGoat\nbaseline](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/WebGoat/-/tree/baselines)\n\n- [Vulnerable Flask Web App\nbaseline](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/baselines/vuln-flask-web-app/-/tree/report)\n\n- [Example of downstream pipeline triggering\nevaluator](https://gitlab.com/gitlab-org/secure/gsoc-sast-benchmark/evaluator-downstream)\n\n\nCover image by [Maxim Hopman](https://unsplash.com/@nampoh) on\n[Unsplash](https://unsplash.com/photos/fiXLQXAhCfk)\n\n{: .note}\n","open-source",[9,786,787],"google","open source",{"slug":789,"featured":6,"template":698},"a-benchmarking-framework-for-sast","content:en-us:blog:a-benchmarking-framework-for-sast.yml","A Benchmarking Framework For Sast","en-us/blog/a-benchmarking-framework-for-sast.yml","en-us/blog/a-benchmarking-framework-for-sast",{"_path":795,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":796,"content":802,"config":809,"_id":811,"_type":13,"title":812,"_source":15,"_file":813,"_stem":814,"_extension":18},"/en-us/blog/a-community-driven-advisory-database",{"title":797,"description":798,"ogTitle":797,"ogDescription":798,"noIndex":6,"ogImage":799,"ogUrl":800,"ogSiteName":685,"ogType":686,"canonicalUrls":800,"schema":801},"Community-driven advisory database for dependencies launched","The advisory data can be readily adopted, adapted, and exchanged. Learn more here.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668354/Blog/Hero%20Images/handshake.png","https://about.gitlab.com/blog/a-community-driven-advisory-database","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Introducing a community-driven advisory database for third-party software dependencies\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Art\"},{\"@type\":\"Person\",\"name\":\"Dinesh Bolkensteyn\"},{\"@type\":\"Person\",\"name\":\"Isaac Dawson\"},{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n \"datePublished\": \"2022-02-16\",\n }",{"title":803,"description":798,"authors":804,"heroImage":799,"date":805,"body":806,"category":807,"tags":808},"Introducing a community-driven advisory database for third-party software dependencies",[778,779,780,781],"2022-02-16","GitLab provides a [Dependency\nScanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nfeature that can automatically detect vulnerabilities in your software\n\ndependencies. Dependency Scanning covers various programming languages and\n\nrelies on the [GitLab Advisory\nDatabase](https://gitlab.com/gitlab-org/security-products/gemnasium-db),\nthat\n\nis\n\n[updated](https://gitlab.com/gitlab-org/security-products/gemnasium-db/activity)\n\non a periodic basis by the \n\n[Vulnerability\nResearch](/handbook/engineering/development/sec/secure/vulnerability-research/)\n\nteam at GitLab. The GitLab Advisory Database covers security advisories in\nsoftware packages that have a CVE identifier, as well as malicious packages\nmarked as such by their ecosystem\n([example](https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/blob/master/npm/lodahs/CVE-2019-19771.yml)).\nThe database is an essential part of\n\nthe Dependency Scanning feature, which is\n\n[available](https://about.gitlab.com/pricing/) in GitLab Ultimate\nself-managed\n\nand GitLab Ultimate SaaS.\n\n\nAs of recently, GitLab also provides a _free and open-source_ version of the\n\ndatabase, the [GitLab Advisory Database (Open Source\nEdition)](https://gitlab.com/gitlab-org/advisories-community), a\ntime-delayed\n\n(+30 days) clone of the [GitLab Advisory\nDatabase](https://gitlab.com/gitlab-org/security-products/gemnasium-db).\n\n\nIn the spirit of\n\n[Collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) and\n\n[Transparency](https://handbook.gitlab.com/handbook/values/#transparency), two\nof\n\nthe [GitLab core values](https://handbook.gitlab.com/handbook/values/), we\nshare\n\nthe database with the open-source community in a format that is\n\n[well-documented](https://gitlab.com/gitlab-org/security-products/gemnasium-db#yaml-schema)\n\nand can be easily parsed. The advisory data can be readily adopted, adapted,\nand\n\nexchanged. For example, links to proof of concepts or write-ups, or any\nother\n\ndirectly related information that will benefit the community, can be added\nto\n\nthe `urls` array:\n\n\n```yaml\n\nurls:\n - \"https://hackerone.com/reports/1104077\"\n - \"https://nvd.nist.gov/vuln/detail/CVE-2021-28965\"\n - \"https://www.ruby-lang.org/en/news/2021/04/05/xml-round-trip-vulnerability-in-rexml-cve-2021-28965/\"\n```\n\n\nAdditionally, in our advisories we use [Common Weakness\nEnumeration](https://cwe.mitre.org/index.html) \n\nin conjunction with [Common Vulnerability Scoring\nSystem](https://www.first.org/cvss/) as a standard means \n\nof [communicating\nvulnerabilities](/handbook/engineering/development/sec/secure/products/metrics/),\nas well as their impact/severity, internally and externally.\n\n\nThe [GitLab Advisory\nDatabase](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is\nintegrated\n\ninto GitLab [Dependency\nScanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/).\nOnce \n\nan existing advisory is modified or a new advisory is created, the\ninformation included in the advisory will appear \n\nin the [Vulnerability\nPages](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) \n\nwhere findings/vulnerabilities originating from all [security\nscanners](/stages-devops-lifecycle/secure/),\n\nincluding Dependency Scanning, can be managed at a central place.\n\n\nThe open-source database has recently been integrated into\n\n[Trivy](https://github.com/aquasecurity/trivy), a free and open-source\nsolution\n\nfor [container\nscanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/).\n\nWe are very grateful for [community\ncontributions](https://gitlab.com/gitlab-org/security-products/gemnasium-db#credits) \n\nto the [GitLab Advisory\nDatabase](https://gitlab.com/gitlab-org/security-products/gemnasium-db).\n\nOur community has aided us by suggesting improvements to our data or by\n creating entirely new advisories, allowing everyone to benefit from their\n contributions.\n\nAt GitLab, [everyone can contribute](/company/mission/).\n\nThe [Vulnerability\nResearch](/handbook/engineering/development/sec/secure/vulnerability-research/)\n\nteam at GitLab has made it easy to contribute to both databases. \n\n\nCommunity contributions can be made available in\n\n[advisories-community](https://gitlab.com/gitlab-org/advisories-community)\n\ninstantaneously by means of the [`community-sync`\nflag](https://gitlab.com/gitlab-org/security-products/gemnasium-db#advisory-headers),\n\nwhich has been introduced recently. Using this synchronization, you can make\n\nthe same contribution appear in both databases at the time of a Merge\nRequest\n\n(within one hour after the merge). \n\n\nWe have also used this flag to make the advisories concerning the recent\n\n[log4Shell](/blog/updates-and-actions-to-address-logj-in-gitlab/)\n\nvulnerabilities available to the community immediately after these were made\npublic.\n\nEven though the open-source version of the database is time-delayed,\nparticular\n\nvulnerabilities that have the potential to become widespread and cause\n\ndisruptions to the entire Internet, are pushed into the open-source version\n\nof the GitLab security advisory database.\n\n\nCover image by [Charles Deluvio](https://unsplash.com/@charlesdeluvio) on\n[Unsplash](https://unsplash.com/photos/AT5vuPoi8vc)\n\n{: .note}\n","security",[807,9],{"slug":810,"featured":6,"template":698},"a-community-driven-advisory-database","content:en-us:blog:a-community-driven-advisory-database.yml","A Community Driven Advisory Database","en-us/blog/a-community-driven-advisory-database.yml","en-us/blog/a-community-driven-advisory-database",{"_path":816,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":817,"content":823,"config":830,"_id":832,"_type":13,"title":833,"_source":15,"_file":834,"_stem":835,"_extension":18},"/en-us/blog/a-go-micro-language-framework-for-building-dsls",{"title":818,"description":819,"ogTitle":818,"ogDescription":819,"noIndex":6,"ogImage":820,"ogUrl":821,"ogSiteName":685,"ogType":686,"canonicalUrls":821,"schema":822},"Lingo: A Go micro language framework for building Domain Specific Languages","Design, build and integrate your own Domain Specific Language with Lingo.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682320/Blog/Hero%20Images/typeset.png","https://about.gitlab.com/blog/a-go-micro-language-framework-for-building-dsls","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Lingo: A Go micro language framework for building Domain Specific Languages\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Julian Thome\"}],\n \"datePublished\": \"2022-05-26\",\n }",{"title":818,"description":819,"authors":824,"heroImage":820,"date":825,"body":826,"category":784,"tags":827},[781],"2022-05-26","\n\nDomain Specific Languages (DSL) are small, focused languages with a narrow\ndomain of applicability. DSLs are tailored towards their target domain so that\ndomain experts can formalize ideas based on their knowledge and background.\n\nThis makes DSLs powerful tools that can be used for the purpose of increasing\nprogrammer efficiency by being more expressive in their target\ndomain, compared to general purpose languages, and by providing concepts to\nreduce the cognitive load on their users.\n\nConsider the problem of summing up the balances of different bank accounts in a\nCSV file. A sample CSV file is provided in the example below where the first\ncolumn contains the name of the account holder and the second column contains\nthe account balance.\n\n``` csv\nname, balance\nLisa, 100.30\nBert, 241.41\nMaria, 151.13\n```\n\nYou could solve the problem of summing up balances by using a general-purpose\nlanguage such as [Ruby](https://www.ruby-lang.org/en/) as in the code snippet\nbelow. Apart from the fact that the code below is not very robust, it contains\na lot of boilerplate that is irrelevant to the problem at hand, i.e., summing\nup the account balances.\n\n``` ruby\n#!/usr/bin/env ruby\n\nexit(1) if ARGV.empty? || !File.exist?(ARGV[0])\n\nsum = 0\nFile.foreach(ARGV[0]).each_with_index do |line, idx|\n next if idx == 0\n sum += Float(line.split(',')[1])\nend\n\nputs sum.round(2)\n```\n\nBelow is an example [AWK script](https://en.wikipedia.org/wiki/AWK) that solves\nthe same problem. AWK is a DSL that was specifically designed to address\nproblems related to text-processing.\n\n``` awk \n#!/usr/bin/awk -f\n\nBEGIN{FS=\",\"}{sum+=$2}END{print sum}\n```\n\nThe Ruby program has a size of 208 characters, whereas the AWK program has a size of 56. The AWK program is roughly 4x smaller than its Ruby\ncounterpart. In addition, the AWK implementation is more robust by being less\nprone to glitches that may appear in the CSV file (e.g., empty newlines,\nwrongly formatted data-fields). The significant difference in terms of size\nillustrates that DSLs, by being more focused on solving specific problems, can\nmake their users more productive by sparing them the burden to write\nboilerplate code and narrowing the focus of the language on the problem at\nhand.\n\nSome popular DSLs most software developers use on a regular basis include\n[Regular Expressions](https://en.wikipedia.org/wiki/Regular_expression) for\npattern matching, AWK for text\ntransformation or [Standard Query Language](https://en.wikipedia.org/wiki/SQL)\nfor interacting with databases.\n\n## Challenges when designing Domain Specific Languages\n\nPrototyping, designing and evolving DSLs is a\nchallenging process. In our experience this is an exploratory cycle where you\nconstantly prototype ideas, incorporate them into the language, try them out in\nreality, collect feedback and improve the DSL based on the feedback. \n\nWhen designing a DSL, there are many components that have to be implemented and\nevolved. At a very high level there are two main components: the language\nlexer/parser and the language processor. The lexer/parser\nis the component that accepts input as per the language definition which is\nusually specified specified by means of a language grammar. The parsing/lexing\nphase produces a syntax tree which is then passed onto the language processor.\nA language processor evaluates the syntax tree. In the example we saw earlier,\nwe ran both the Ruby and AWK interpreters providing our scripts and the CSV\nfile as input; both interpreters evaluated the scripts and this evaluation\nyielded the sum of all the account balances as a result.\n\nTools such as parser generators can significantly reduce the effort of\nlexer/parser development by means of code generation. Sophisticated DSL\nframeworks such as [JetBrains MPS](https://www.jetbrains.com/mps/) or\n[Xtext](https://www.eclipse.org/Xtext/) also provide features that help\nimplement custom language support in IDEs. However, if present at all, the\nsupport for building the language processors is usually limited to generating\nplaceholders functions or boilerplate code for the language components that\nhave to be filled-in by the DSL developer. Moreover, such large and powerful DSL\nframeworks usually have a fairly steep learning curve so that they are probably\na better fit for more sophisticated DSLs as opposed to small, easily\nembeddable, focused languages, which we refer to as _micro languages_.\n\nIn some situations, it may be worth considering working around these problems\nby just relying on standard data exchange formats such as `.toml`, `.yaml` or\n`.json` as a means of configuration. Similar to the parser generators, using\nsuch a format may relieve some of the burden when it comes to parser\ndevelopment effort. However, this approach does not help when it comes to the\nimplementation of the actual language processor. In addition, most standard data\nexchange formats are inherently limited to representing data in terms of simple\nconcepts (such as lists, dictionaries, strings and numbers). This limitation\ncan lead to bloated configuration files quickly as shown in the following\nexample.\n\nImagine the development of a calculator that operates on integers using\nmultiplication `*`, addition `+`. When using a data-description language like\nYAML in the example below, you can see that even a small simple term like `1 + 2 * 3 + 5` \ncan be hard to reason about, and by adding more terms the configuration\nfile would get bloated quickly.\n\n``` yaml\nterm:\n add: \n - 1\n - times:\n - 2\n - 3\n - 5\n```\n\nThis blog post is focused on the design of micro languages. The core idea is to\nprovide a simple, extensible language core that can be easily extended with\ncustom-types and custom functions; the language can evolve without having\nto touch the parser or the language processor. Instead, the DSL designer can\njust focus on the concepts that ought to be integrated into the DSL by\nimplementing interfaces and \"hooking\" them into the core language\nimplementation.\n\n## Lingo: A micro language framework for Go\n\nAt GitLab, Go is one of our main programming languages and some of the tools we\ndevelop required their own, small, embeddable DSLs so that users could properly\nconfigure and interact with them. \n\nInitially, we tried to integrate already existing, embeddable and expandable\nlanguage implementations. Our only condition was that they had to be\nembeddable natively into a Go application. We explored several great free and\nopen-source (FOSS) projects such as [go-lua](https://github.com/Shopify/go-lua)\nwhich is Lua VM implemented in Go, [go-yeagi](https://github.com/traefik/yaegi)\nwhich provides a Go interpreter with which Go can be used as a scripting\nlanguage or [go-zygomys](https://github.com/glycerine/zygomys) which is a LISP\ninterpreter written in Go. However, these packages are essentially modules to\nintegrate general-purpose languages on top of which a DSL could be built. These modules ended up being fairly complex. In contrast, we wanted to have basic support to design, implement, embed and evolve DSLs natively into a Go\napplication that is flexible, small, simple/easy to grasp, evolve and\nadapt.\n\nWe were looking for a micro language framework with the properties listed below:\n\n1. Stability: Changes applied to the DSL should neither require any changes to the core lexer/parser implementation nor to the language processor implementation.\n1. Flexibility/Composability: New DSL concepts (data-types, functions) can be integrated via a simple plug-in mechanism.\n1. Simplicity: the language framework should have just\nenough features to provide a foundation that is powerful enough to implement\nand evolve a custom DSL. In addition, the whole implementation of the micro\nlanguage framework should be in pure Go so that it is easily embeddable in Go\napplications.\n\nSince none of the available FOSS tools we looked at was able to\nfulfill all of those requirements, we developed our own micro language framework\nin Go called Lingo which stands for \"**L**ISP-based Domain Specific Languages\n(DSLs) **in Go**\". Lingo is completely FOSS and available in the [Lingo Git repository](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nunder the free and open source space of the [Vulnerability Research Team](https://about.gitlab.com/handbook/engineering/development/sec/secure/vulnerability-research/).\n\n[Lingo](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nprovides a foundation for building DSLs based on Symbolic Expressions (S-expressions), i.e.,\nexpressions provided in the form of nested lists `(f ...)` where `f` can be\nconsidered as the placeholder that represents the function symbol. Using this format,\nthe mathematical term we saw earlier could be written as S-expression `(+ 1 (* 2 3) 5)`. \n\nS-expressions are versatile and easy to process due to their uniformity. In\naddition, they can be used to represent both code and data in a consistent\nmanner.\n\nWith regards to the Stability, Flexibility and Composability properties, \n[Lingo](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo)\nprovides a simple plug-in mechanism to add new functions as well as types\nwithout having to touch the core parser or language processor. From the\nperspective of the S-expression parser, the actual function symbol is\nessentially irrelevant with regards to the S-expression parsing. The language processor is just evaluating S-expressions and dispatching the execution to the interface implementations. These implementations are provided by the plug-ins based on the function symbol.\n\nWith regards to Simplicity, the Lingo code base is roughly 3K lines of pure Go code including the lexer/parser, an\nengine for code transformation, and the interpreter/evaluator. The small size\nshould make it possible to understand the entirety of the implementation. \n\nReaders that are interested in the technical details of\nLingo itself can have a look at the\n[README.md](https://gitlab.com/gitlab-org/vulnerability-research/foss/lingo/-/blob/main/README.md)\nwhere the implementation details and the used theoretical foundations are explained.\nThis blog post focuses on how\nLingo can be used to build a DSL from scratch.\n\n## Using Lingo to design a data generation engine\n\nIn this example we are designing a data-generation engine in Go using\nLingo as a foundation. Our data generation engine may be used to generate structured input\ndata for fuzzing or other application contexts. This example illustrates how\nyou can use Lingo to create a language and the corresponding language\nprocessor. Going back to the example from the beginning, let us assume we would\nlike to generate CSV files in the format we saw at the beginning covering\naccount balances.\n\n``` csv\nname, balance\nLisa, 100.30\nBert, 241.41\nMaria, 151.13\n```\n\nOur language includes the following functions:\n\n1. `(oneof s0, s1, ..., sN)`: randomly returns one of the parameter strings `sX` (0 \u003C= X \u003C= N).\n1. `(join e0, e1, ..., eN)`: joins all argument expressions and concatenates their string representation `eX` (0 \u003C= X \u003C= N).\n1. `(genfloat min max)`: generates a random float number X (0 \u003C= X \u003C= N) and returns it.\n1. `(times num exp)`: repeats the pattern generated by exp num times.\n\nFor this example we are using\nLingo to build the language and the language processor to automatically generate CSV\noutput which we are going to feed back into the Ruby and AWK programs we saw in\nthe introduction in order to perform a stress test on them. \n\nWe refer to our new language/tool as _Random Text Generator_ (RTG) `.rtg`.\nBelow is a sample script `script.rtg` we'd like our program to digest in order\nto randomly generate CSV files. As you can see in the example below, we are\njoining sub-strings starting with the CSV header `name, balance`\nafter which we randomly generate 10 lines of names and balance amounts. In\nbetween, we also randomly generate some empty lines.\n\n```\n(join \n (join \"name\" \",\" \"balance\" \"\\n\")\n (times 10 \n '(join \n (oneof \n \"Jim\" \n \"Max\" \n \"Simone\" \n \"Carl\" \n \"Paul\" \n \"Karl\" \n \"Ines\" \n \"Jane\" \n \"Geralt\" \n \"Dandelion\" \n \"Triss\" \n \"Yennefer\" \n \"Ciri\") \n \",\" \n (genfloat 0 10000) \n \"\\n\" \n (oneof \"\" \"\\n\"))))\n```\n\nOur engine takes the script above written in RTG and generates random CSV\ncontent. Below is an example CSV file generated from this script.\n\n``` csv\nname,balance\nCarl,25.648205\nInes,11758.551\n\nCiri,13300.558\n...\n```\n\nFor the remainder of this section, we explore how we can implement a\ndata generation engine based on Lingo. The implementation of RTG requires\nthe two main ingredients: (1) a float data type and a result object to integrate a float\nrepresentation and (2) implementations for the `times`, `oneof`, `genfloat` and\n`join` functions.\n\n### Introducing a float data type and result objects\n\nLingo differentiates between data types and result objects. Data types indicate how data is\nmeant to be used and result objects are used to pass intermediate results\nbetween functions where every result has a unique type. In the code snippet\nbelow, we introduce a new `float` data type. The comments in the code snippet below\nprovide more details.\n\n``` go \n// introduce float type\nvar TypeFloatId, TypeFloat = types.NewTypeWithProperties(\"float\", types.Primitive)\n// introduce token float type for parser\nvar TokFloat = parser.HookToken(parser.TokLabel(TypeFloat.Name))\n\n// recognize (true) as boolean\ntype FloatMatcher struct{}\n\n// this function is used by the parser to \"recognize\" floats as such\nfunc (i FloatMatcher) Match(s string) parser.TokLabel {\n if !strings.Contains(s, \".\") {\n return parser.TokUnknown\n }\n\n if _, err := strconv.ParseFloat(s, 32); err == nil {\n\treturn TokFloat.Label\n }\n\n return parser.TokUnknown\n}\nfunc (i FloatMatcher) Id() string {\n return string(TokFloat.Label)\n}\n\nfunc init() {\n // hook matcher into the parser\n parser.HookMatcher(FloatMatcher{})\n}\n```\n\nIn addition, we also require a result object which we can use to pass around\nfloat values. This is an interface implementation where most of the functions names\nare self-explanatory. The important bit is the `Type` function\nthat returns our custom `float` type we introduced in the last snippet.\n\n``` go\ntype FloatResult struct{ Val float32 }\n// deep copy\nfunc (r FloatResult) DeepCopy() eval.Result { return NewFloatResult(r.Val) }\n// returns the string representation of this result type\nfunc (r FloatResult) String() string {\n return strconv.FormatFloat(float64(r.Val), 'f', -1, 32)\n}\n// returns the data type for this result type\nfunc (r FloatResult) Type() types.Type { return custtypes.TypeFloat }\n// call-back that is cleaned up when the environment is cleaned up\nfunc (r FloatResult) Tidy() {}\n\nfunc (r FloatResult) Value() interface{} { return r.Val }\nfunc (r *FloatResult) SetValue(value interface{}) error {\n boolVal, ok := value.(float32)\n if !ok {\n return fmt.Errorf(\"invalid type for Bool\")\n }\n r.Val = boolVal\n return nil\n}\nfunc NewFloatResult(value float32) *FloatResult {\n return &FloatResult{\n value,\n }\n}\n```\n\n### Implementing the DSL functions\n\nSimilar to the data type and return object, implementation of a DSL function is\nas simple as implementing an interface. In the example below we implement the\n`genfloat` function as an example. The most important parts are the `Symbol()`,\n`Validate()` and `Evaluate()` functions. The `Symbol()` function returns the\nfunction symbol which is `genfloat` in this particular case. \n\nBoth, the `Validate()` and `Evaluate()` functions take the environment `env`\nand the parameter Stack `stack` as the parameter. The environment is used to store\nintermediate results which is useful when declaring/defining variables. The `stack` includes the input parameters of the function. For\n`(genfloat 0 10000)`, the stack would consist out of two `IntResult` parameters\n`0` and `10000` where `IntResult` is a standard result object already provided by the\ncore implementation of Lingo. `Validate()` makes sure that the parameter can be\ndigested by the function at hand, whereas `Evaluate()` actually invokes the\nfunction. In this particular case, we are generating a float value within the\nspecified range and return the corresponding `FloatResult`.\n\n``` go\ntype FunctionGenfloat struct{}\n\n// returns a description of this function\nfunc (f *FunctionGenfloat) Desc() (string, string) {\n return fmt.Sprintf(\"%s%s %s%s\",\n string(parser.TokLeftPar),\n f.Symbol(),\n\t\"min max\",\n\tstring(parser.TokRightPar)),\n\t\"generate float in rang [min max]\"\n}\n\n// this is the symbol f of the function (f ...)\nfunc (f *FunctionGenfloat) Symbol() parser.TokLabel {\n return parser.TokLabel(\"genfloat\")\n}\n\n// validates the parameters of this function which are passed in\nfunc (f *FunctionGenfloat) Validate(env *eval.Environment, stack *eval.StackFrame) error {\n if stack.Size() != 2 {\n return eval.WrongNumberOfArgs(f.Symbol(), stack.Size(), 2)\n }\n\n for idx, item := range stack.Items() {\n if item.Type() != types.TypeInt {\n\t return eval.WrongTypeOfArg(f.Symbol(), idx+1, item)\n\t}\n }\n return nil\n}\n\n// evaluates the function and returns the result\nfunc (f *FunctionGenfloat) Evaluate(env *eval.Environment, stack *eval.StackFrame) (eval.Result, error) {\n var result float32\n rand.Seed(time.Now().UnixNano())\n for !stack.Empty() {\n max := stack.Pop().(*eval.IntResult)\n min := stack.Pop().(*eval.IntResult)\n\n\tminval := float32(min.Val)\n\tmaxval := float32(max.Val)\n\n\tresult = minval + (rand.Float32() * (maxval - minval))\n }\n\n return custresults.NewFloatResult(result), nil\n}\n\nfunc NewFunctionGenfloat() (eval.Function, error) {\n fun := &FunctionGenfloat{}\n parser.HookToken(fun.Symbol())\n return fun, nil\n}\n```\n\n### Putting it all together\n\nAfter implementing all the functions, we only have to register/integrate them\n(`eval.HookFunction(...)`) so that Lingo properly resolves them when processing\nthe program. In the example below, we are registering all of the custom functions\nwe implemented, i.e., `times`, `oneof`, `join`, `genfloat`. The `main()`\nfunction in the example below includes the code required to evaluate our script\n`script.rtg`.\n\n``` go\n// register function\nfunc register(fn eval.Function, err error) {\n if err != nil {\n log.Fatalf(\"failed to create %s function %s:\", fn.Symbol(), err.Error())\n }\n err = eval.HookFunction(fn)\n if err != nil {\n log.Fatalf(\"failed to hook bool function %s:\", err.Error())\n }\n}\n\nfunc main() {\n // register custom functions\n register(functions.NewFunctionTimes())\n register(functions.NewFunctionOneof())\n register(functions.NewFunctionJoin())\n register(functions.NewFunctionGenfloat())\n register(functions.NewFunctionFloat())\n if len(os.Args) \u003C= 1 {\n fmt.Println(\"No script provided\")\n os.Exit(1)\n }\n // evaluate script\n result, err := eval.RunScriptPath(os.Args[1])\n if err != nil {\n fmt.Println(err.Error())\n os.Exit(1)\n }\n\n // print output\n fmt.Printf(strings.ReplaceAll(result.String(), \"\\\\n\", \"\\n\"))\n\n os.Exit(0)\n}\n```\n\nThe source code for RTG is available\n[here](https://gitlab.com/julianthome/lingo-example). You can find information\nabout how to build and run the tool in the\n[README.md](https://gitlab.com/julianthome/lingo-example/-/blob/main/README.md).\n\nWith approx. 300 lines of Go code, we have successfully designed a language and\nimplemented a language processor. We can now use RTG to test the robustness of\nthe Ruby (`computebalance.rb`) and AWK scripts (`computebalance.awk`) we used\nat the beginning to sum up account balances. \n\n``` bash\ntimeout 10 watch -e './rtg script.rtg > out.csv && ./computebalance.awk out.csv'\ntimeout 10 watch -e './rtg script.rtg > out.csv && ./computebalance.rb out.csv'\n```\n\nThe experiment above shows that the files generated by means of RTG can be\nproperly digested by the AWK script which is much more robust since it can cope\nwith the all generated CSV files. In contrast, executing of the Ruby script\nresults in errors because it cannot properly cope with newlines as they appear\nin the CSV file.\n\nCover image by [Charles Deluvio](https://unsplash.com/@kristianstrand) on [Unsplash](https://unsplash.com/photos/p8gzCnZf39k)\n{: .note}\n\n",[9,828,829],"tutorial","features",{"slug":831,"featured":6,"template":698},"a-go-micro-language-framework-for-building-dsls","content:en-us:blog:a-go-micro-language-framework-for-building-dsls.yml","A Go Micro Language Framework For Building Dsls","en-us/blog/a-go-micro-language-framework-for-building-dsls.yml","en-us/blog/a-go-micro-language-framework-for-building-dsls",{"_path":837,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":838,"content":844,"config":851,"_id":853,"_type":13,"title":854,"_source":15,"_file":855,"_stem":856,"_extension":18},"/en-us/blog/a-snapshot-of-modern-devops-practices-today",{"title":839,"description":840,"ogTitle":839,"ogDescription":840,"noIndex":6,"ogImage":841,"ogUrl":842,"ogSiteName":685,"ogType":686,"canonicalUrls":842,"schema":843},"A snapshot of modern DevOps practices today","We consulted three market research firms for their take on DevOps today and in the future. Here's what they said about modern DevOps practices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668495/Blog/Hero%20Images/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab.jpg","https://about.gitlab.com/blog/a-snapshot-of-modern-devops-practices-today","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"A snapshot of modern DevOps practices today\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-10-31\",\n }",{"title":839,"description":840,"authors":845,"heroImage":841,"date":847,"body":848,"category":757,"tags":849},[846],"Valerie Silverthorne","2022-10-31","At almost 15 years old, DevOps has been around long enough to settle in and take shape at organizations around the world. But what do “modern” DevOps practices look like today, and how are they likely to change? Three market research firms gave us their take on the current generation of DevOps, and what’s coming next. \n\n## BizDevOps anyone?\n\nIf there’s one clear sign of DevOps maturity, it’s the fact that the business side has seamlessly inserted itself into what was forever a bastion of technologies and tech-driven practices. With some of the [bigger DevOps battles well in hand](/developer-survey/) (broader adoption of automation, more frequent deployments, and increased software testing), teams are able to bring in new metrics, including user experience, customer satisfaction, and other business drivers. 451 Research found business objectives and outcomes are the leading priority (51%) for enterprises as they refine, improve, and expand their DevOps implementations. In fact, 451 said business metrics are now almost as important a measure of DevOps success as technical achievements like application performance and quality.(1)\n\nFurther underscoring the way modern DevOps practices have broadened their focus is the increasing interest in value stream management, which looks at the software development lifecycle from idea generation to customer delivery and satisfaction level. Research firm IDC, in its \"Accelerated App Delivery Survey 2021\" (U.S. Results)(3), published January 2022, said value stream management is going to be one of the top investment priorities for DevOps teams this year. \n\n## DevOps and security\n\nBut the focus on business objectives doesn’t mean that work on the tech side of DevOps is done; in fact, DevSecOps and security in DevOps in general continue to be a tricky balance for many teams. IDC, also in its \"Accelerated App Delivery Survey 2021\" (referenced above), notes the cognitive dissonance of DevOps teams saying security is a top priority and feeling confident about their security posture while at the same time acknowledging DevSecOps is only in use for 25% or less of application development on average. \n\nForrester Research, in its \"State of Application Security, 2022\" (May 9, 2022), said: “Savvy security professionals know that to drive application security tool adoption, they must engage developers in the technology decision-making process. With both tooling\ndecision-making and budget moving to development, security pros must redefine\ntheir role in application security and take advantage of the opportunity to become\nmore strategic.”\n\n## The role of DevOps platforms\n\nSecurity is an ongoing substantive issue on DevOps teams but there are also a number of smaller, but still significant, problems teams need to solve, including [toolchain debt](/blog/battling-toolchain-technical-debt/), the challenge of scaling, and the need for a product and platform structure. DevOps platforms can help with all of those challenges.\n\nFor starters, it’s nearly impossible to scale DevOps throughout an enterprise without a DevOps platform supporting the effort. A platform provides a single source of truth for all teams, eliminates handoffs, and allows visibility into every stage of the process. A DevOps platform also helps eliminate the inefficiencies caused by too many tools and toolchains. Our [2022 Global DevSecOps Survey](/developer-survey/) found 69% of teams want to streamline their toolchains to reduce time spent on maintenance/integration and improve developer quality of life.\n\nWhat does a DevOps platform look like in 2022? Forrester Research, in \"The Forrester Guide to DevOps 2022\" (September 14, 2022) said modern DevOps platforms are “integrated and automated; create a software automation abstraction layer; use SLAs to drive continuous improvement; and have cloud platforms as deployment targets of choice.”\n\n## Culture (still) matters\n\nIn the early days of DevOps the talk was **all** about the culture challenge of bringing the vastly different dev and ops teams together. Somewhat surprisingly, market research firms are still talking about culture today, perhaps because the definition of DevOps has expanded to include more than just dev, ops, and even sec: BizDevSecUXTestPlatformLowCodeOps... ad infinitum, apparently.\n\nOrganizations wanting DevOps success must continue to push the importance of culture, collaboration, and communication, IDC reported in its \"Accelerated App Delivery Survey 2021.\" Forrester Research offered a stark assessment in \"The State of DevOps, 2022\" (June 27, 2022): “Never underestimate the importance of cultural transformation. Laggard organizations punish the bearers of bad tidings and don’t understand failure as a learning opportunity. Exorcizing these toxic attitudes is far easier said than done.”\n\n## Modern DevOps means modern technologies\n\nModern DevOps teams continue to incorporate new technologies into their practices. Two standouts: [AI/ML](/blog/why-ai-in-devops-is-here-to-stay/) and [GitOps](/blog/the-ultimate-guide-to-gitops-with-gitlab/). 451 points to rising interest in AIOps specifically to address the “too much information” problem with logs and metrics.(2) \n\n## Looking forward\n\nChange is of course a given and it’s safe to say that DevOps teams will face new organizational structures, new teammates, and complicated technology adoption challenges.\n\n### Cross-functional teams organized around products\n\nAfter years of bringing dev and ops together, some believe it’s time to reach out further. Forrester, in \"The Future of DevOps\" (June 8, 2022), said: “In the future, cross-functional teams, from business stakeholders to operational site reliability engineers (SREs), will organize around products, delivering business value via DevOps platforms.”\n\n### Wider and deeper platforms\n\nAnd those DevOps platforms “will consolidate, extend and deepen,” Forrester predicts in \"The Future of DevOps,\" cited above.\n\n### Introducing new teammates\n\nRoughly 66% of our 2022 DevSecOps Survey respondents told us their DevOps practices include a low code/no code tool. And that’s going to spread to all teams in the coming years. “Citizen development is a logical evolution of how enterprises deliver apps and enable digital business,” Forrester Research said in \"The Future of DevOps.\"\n\n### DevOps on the edge\t\n\nWith the Internet of Things and 5G becoming larger on the horizon, it’s not much of a stretch to predict modern DevOps teams will need to be able to support products with data literally [“on the edge.”](https://www.techtarget.com/searchdatacenter/definition/edge-computing) \n\n- [1] 451 Research, a part of S&P Global Market Intelligence, Mature DevOps Means Business, Jay Lyman, Senior Research Analyst, June 2022\n- [2] 451 Research, a part of S&P Global Market Intelligence, Business Objectives and Benefits Become Top Priority - Highlights from VotE DevOps, Jay Lyman, Senior Research Analyst, April 2022\n- [3] IDC, U.S. Accelerated Application Delivery Survey, Doc #US47924622, Jan 2022\n",[850,9,695],"developer survey",{"slug":852,"featured":6,"template":698},"a-snapshot-of-modern-devops-practices-today","content:en-us:blog:a-snapshot-of-modern-devops-practices-today.yml","A Snapshot Of Modern Devops Practices Today","en-us/blog/a-snapshot-of-modern-devops-practices-today.yml","en-us/blog/a-snapshot-of-modern-devops-practices-today",{"_path":858,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":859,"content":865,"config":871,"_id":873,"_type":13,"title":874,"_source":15,"_file":875,"_stem":876,"_extension":18},"/en-us/blog/a-year-of-iteration",{"title":860,"description":861,"ogTitle":860,"ogDescription":861,"noIndex":6,"ogImage":862,"ogUrl":863,"ogSiteName":685,"ogType":686,"canonicalUrls":863,"schema":864},"2020: A year of iteration","A look at how far Vulnerability Management progressed in 2020 through hard work and lots of iterations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681857/Blog/Hero%20Images/cover-2020-a-year-of-iteration.jpg","https://about.gitlab.com/blog/a-year-of-iteration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"2020: A year of iteration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Wilson\"}],\n \"datePublished\": \"2021-01-18\",\n }",{"title":860,"description":861,"authors":866,"heroImage":862,"date":868,"body":869,"category":716,"tags":870},[867],"Matt Wilson","2021-01-18","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAt GitLab, [we’re all about iteration](https://handbook.gitlab.com/handbook/values/#iteration). It helps us continuously push out product improvements and additional value to our users. One interesting side effect of iteration is that it can make it harder to see the true scope of what you’ve delivered. Rather than a few big bang giant feature releases per year, a steady flow of iterative improvements requires taking a few steps back to look at all the work in aggregate to get a full sense of accomplishment. As we look forward to 2021, it’s worth a look back to see how far the [Threat Insights group](https://about.gitlab.com/handbook/product/categories/#threat-insights-group) has come with [Vulnerability Management](https://about.gitlab.com/direction/govern/threat_insights/vulnerability_management/) in the past year.\n\nThe year 2020 was filled with unprecedented challenges far beyond what most of us have ever experienced. The Threat Insights team formed against a backdrop of uncertainty with a global pandemic just starting to spread. Most of our team joined GitLab last year. We took over a fledgling area of the product that was off to a good start but hadn’t had a dedicated team to push it forward. Many of us—myself included—had security experience yet little to no background in vulnerability management. In short: we faced a daunting challenge.\n\nInitially, progress was slow as we took inventory of the current state of Vulnerability Management. We gathered input from others who worked on existing functionality. Early on, we determined that a major architectural upgrade to how GitLab stored vulnerability data from pipeline jobs was essential to do first. It took several months of hard work that culminated in [Standalone Vulnerability Objects](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#standalone-vulnerability-objects) debuting in GitLab 13.0 in May.\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/2020-a-year-of-iteration/project-security-dashboard-early-2020.png){: .shadow}\nProject-level Vulnerability Management in early 2020\n{: .note.text-center}\n\nYou may be wondering how a post that started by talking about iteration fits with spending a few months for one big change. Sometimes there are necessary exceptions where iterative releases would be more disruptive to users. Because we were changing the underlying storage model for vulnerability data, it was critical to upgrade all components of Vulnerability Management together. Otherwise, the experience for our users would have been inconsistent and confusing. We did still develop the new vulnerability object model iteratively; however, the work was held back behind a (large) feature flag until all pieces were complete and we could publicly release them simultaneously.\n\nThe Standalone Vulnerability Objects release was a major step forward technically. It also brought about another key milestone: Vulnerability Management’s [maturity](https://about.gitlab.com/direction/maturity/) officially moved to Minimal. Reaching Minimal signaled our category now had a complete foundation on which our users could build their vulnerability management and remediation programs. Getting this key piece of architecture in place further marked a turning point in our team’s ability to start quickly delivering new features built on top of it.\n\nTo illustrate how much the team accomplished just since 13.0, here are some highlights from our May-December progress:\n\n* 10 release post-worthy new features\n* Over 40 total new features and enhancements to existing features\n* Numerous new GraphQL endpoints (and one of the first teams to go GraphQL-first)\n* Over 150 bugs squashed\n* Numerous technical and performance improvements\n\nWe transformed the Group- and Project-level Security Dashboards into separate experiences for dashboarding and working with vulnerability lists. We created a personal [Security Center](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#security-center). We made managing vulnerabilities a more seamless part of an integrated DevSecOps workflow with new features like [linking existing issues to vulnerabilities](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#link-existing-issues-to-a-vulnerability), [showing pipeline status on Project Security Dashboards](https://about.gitlab.com/releases/2020/11/22/gitlab-13-6-released/#pipeline-status-in-project-security-dashboard), and adding [Special references for vulnerabilities](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#special-references-for-vulnerabilities). And, perhaps most impressively, Vulnerability Management reached the next maturity level of Viable a mere 7 months after reaching Minimal—and a month ahead of plan. Reaching Viable so quickly is an especially big achievement since it requires successfully passing a [research-based maturity evaluation process](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) with real users.\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/2020-a-year-of-iteration/project-security-dashboard-december-2020.png){: .shadow}\nProject-level Vulnerability Management in December 2020\n{: .note.text-center}\n\nLast year, many of us were stuck at home, our routines becoming monotonous with days seeming to blur together. It’s easy to get lost in the day-to-day. This can make it difficult to see just how much forward progress might actually be happening. Taking time to inventory our accomplishments highlights that we achieved quite a bit in a few short months. This perspective of hindsight makes it clear just how far we’ve come. None of this would have been possible without hard work and dedication by the talented Threat Insights team. As we look forward to 2021, I’m excited about [what lies ahead](https://about.gitlab.com/direction/govern/threat_insights/vulnerability_management/). Expect even more big things—in monthly iterations—from Threat Insights!\n\nCover image by \u003Ca href=\"https://unsplash.com/@marcello54?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Marcello Gennari\u003C/a> on \u003Ca href=\"https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>\n{: .note}\n",[232,807,9],{"slug":872,"featured":6,"template":698},"a-year-of-iteration","content:en-us:blog:a-year-of-iteration.yml","A Year Of Iteration","en-us/blog/a-year-of-iteration.yml","en-us/blog/a-year-of-iteration",{"_path":878,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":879,"content":885,"config":892,"_id":894,"_type":13,"title":895,"_source":15,"_file":896,"_stem":897,"_extension":18},"/en-us/blog/achieve-devsecops-collaboration",{"title":880,"description":881,"ogTitle":880,"ogDescription":881,"noIndex":6,"ogImage":882,"ogUrl":883,"ogSiteName":685,"ogType":686,"canonicalUrls":883,"schema":884},"DevSecOps basics: 5 cross-functional team collaboration goals","Team work makes the (DevSecOps) dream work. Here's what you need to know about collaboration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663594/Blog/Hero%20Images/devsecops-cross-collaboration.jpg","https://about.gitlab.com/blog/achieve-devsecops-collaboration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"DevSecOps basics: 5 cross-functional team collaboration goals\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n \"datePublished\": \"2020-07-01\",\n }",{"title":880,"description":881,"authors":886,"heroImage":882,"date":888,"body":889,"category":693,"tags":890},[887],"Vanessa Wegner","2020-07-01","\n_This is the second in a five-part series on getting started with [DevSecOps](/solutions/security-compliance/). Part one gives you nine ways to [shift security left](/blog/efficient-devsecops-nine-tips-shift-left/). Part three offers concrete steps to add [automated security testing](/blog/devsecops-security-automation/) into the mix. And part four explains how to [build a strong security culture](/blog/security-culture-devsecops/) to support your DevSecOps efforts._\n\nCross-functional collaboration seems like a dry buzzword, but I promise you it’s way better than it sounds. After all, [DevOps](/topics/devops/) is cross-functional collaboration. DevSecOps is too. [In GitLab’s 2020 DevSecOps Survey](/developer-survey/), respondents had a plethora of strong reasons to do DevOps, including code quality, faster time to market, and _happier developers_. But if there are rifts in communication and collaboration, any joint Dev, Sec, or Ops effort will all be for naught. \n\n[Collaboration](/blog/future-merge-requests-realtime-collab/) is a core principle of DevOps but it is even more critical when bringing a third element – security – into the mix. Team members should feel comfortable reaching out across functions, asking questions, and sharing (non-sensitive) information. DevSecOps brings a special meaning to collaboration because of the shift in roles and responsibilities introduced by new security efforts. [Shifting your security practices left](/blog/efficient-devsecops-nine-tips-shift-left/) will require some heavy lifting to truly get your DevSecOps practices off the ground.\n\n## Leading by example\n\nTo begin, leaders from each functional team need to gain a mutual understanding of the other teams’ functions, roadblocks, and goals. Then they should discuss how security will be integrated into dev and ops – both how the lifecycle will flow, and how employees will be onboarded to any new processes. The results of that discussion should be shared across the entire organization to put everyone on the same page. \n\nOrganizational heads will need to set an example for their teams. Employees should understand the collaborative work that is being done at the top, and how their own work is part of that effort. Additional expectations should also be communicated. These, as outlined below, should foster a collaborative environment that requires communication and reliability across teams. \n\n### Cross-functional team goals\n\nIt’s important to start with cross-functional team goals. These can be broad (like \"deliver a secure and stable product at every release\"), or specific (\"add extensive identity verification features while ensuring compliance with GDPR\"). Regardless of what the goal is, it should be made clear that employees across all functions are working together to achieve the same thing – and the cross-functional team will be evaluated as a whole. \n\n### Peer teaching and peer learning\n\nWhen security employees understand the function and goals of Dev and Ops, they’ll be able to give better guidance and instruction on how each role can produce secure work. On the other hand, when Dev and Ops understand the function and goals of security, they’ll find it more logical to incorporate new security practices into their day-to-day work. This way, employees will understand how their goals align with and benefit each other. Employees should be encouraged to help one another learn – and certainly should be encouraged to learn from each other with open minds. \n\n### Centralized information sharing\n\nFor the best possible [DevSecOps](/solutions/security-compliance/) experience, information needs to live and be shared in a central location – preferably [a single platform for the entire DevOps lifecycle](/stages-devops-lifecycle/). Ideally, the entire project team has access to all the information they need, all in the same place. This minimizes context-switching and reduces the likelihood of information getting lost or missed by team members. Keeping change logs, test and scan results, code reviews and other metrics colocated means everyone knows where to find the information they need to get their job done efficiently. \n\n## DevSecOps: Five collaboration goals\n\nWhat does it look like to have strong collaboration across your teams? Qualitative principles are slightly harder to quantify than things like vulnerabilities, but there are plenty of ways to build your team's collaborative muscles and measure their strength:\n\n1. Project planning is a joint effort between Dev, Sec, and Ops. \n1. Employees have access and actively contribute to a single datastore with reporting and visibility across the DevSecOps lifecycle.\n1. Vulnerability management, reporting, and remediation will cost less and happen more quickly than before you began your DevSecOps efforts.\n1. Tools have been consolidated so that development and security can collaborate within the same interface. \n1. Project delays are rarely caused by lack of communication or information sharing. \n\n_How efficient are your DevSecOps practices? [Take our DevSecOps Maturity Assessment to find out.](https://about.gitlab.com/resources/devsecops-methodology-assessment/)_\n\n**Read more about DevSecOps:**\n\n[How CI can get you to DevSecOps faster](/blog/solve-devsecops-challenges-with-gitlab-ci-cd/)\n\n[Why security as code is important](/blog/how-to-security-as-code/)\n\n[How to integrate security into DevOps](/blog/how-to-security-as-code/)\n\nCover image by [Charlie Egan](https://unsplash.com/@charlieegan3) on [Unsplash](https://unsplash.com/photos/qOR762W7OvA)\n{: .note}\n",[891,9,695,807],"agile",{"slug":893,"featured":6,"template":698},"achieve-devsecops-collaboration","content:en-us:blog:achieve-devsecops-collaboration.yml","Achieve Devsecops Collaboration","en-us/blog/achieve-devsecops-collaboration.yml","en-us/blog/achieve-devsecops-collaboration",{"_path":899,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":900,"content":905,"config":913,"_id":915,"_type":13,"title":916,"_source":15,"_file":917,"_stem":918,"_extension":18},"/en-us/blog/adopt-agile-and-devops-for-ibm-z",{"title":901,"description":902,"ogTitle":901,"ogDescription":902,"noIndex":6,"ogImage":708,"ogUrl":903,"ogSiteName":685,"ogType":686,"canonicalUrls":903,"schema":904},"The benefits of DevOps practices for IBM Z","GitLab aims to provide a unified enterprise-wide DevOps platform with enhanced support for IBM Z. Here are three areas that can start to align DevOps and mainframe development.","https://about.gitlab.com/blog/adopt-agile-and-devops-for-ibm-z","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The benefits of DevOps practices for IBM Z\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vick Kelkar\"}],\n \"datePublished\": \"2021-09-10\",\n }",{"title":901,"description":902,"authors":906,"heroImage":708,"date":908,"body":909,"category":910,"tags":911},[907],"Vick Kelkar","2021-09-10","\n\nAs more organizations adopt open source software, [DevOps](/topics/devops/) and cloud computing, teams are moving towards a hybrid approach to application development and deployments. This is a particular challenge for siloed mainframe development teams that typically work within their own development tools – and those tools are are not the same ones used by their distributed developer counterparts. These disparate toolsets are not integrated between build, package, test, and deploy steps. GitLab aims to provide a [unified enterprise-wide DevOps platform](/solutions/devops-platform/) with enhanced support for IBM z/OS® applications. Here are three critical areas to focus on that can help bridge the gap between mainframe and \"modern\" DevOps development.\n\n## Common workflows for hybrid environments\n\nDevOps is naturally aligned to Agile processes with its focus on continuous improvements, freqent releases and adherence to business objectives. As organizations adopt a hybrid infrastructure to meet their needs, it becomes extremely important to have a common workflow (and tools!) for continuous software development. The development workflow should be the same whether you are building a [cloud native](/topics/cloud-native/) container application for Red Hat OpenShift or whether you are refactoring COBOL applications on IBM Z. Ideally, in both scenarios, the same source code management, along with Git commit and merge-request workflows should be used, regardless of the type of application code or where it is deployed. The advantage of using the same software development lifecycle methodology and tools allows an organization to drive an enterprise-wide DevOps strategy. Additionally, this helps organizations to attract mainframe developers, allowing them to move between mainframe and cloud-based application development projects, enhancing developer job satisfaction, growth and retention.\n\n## Security and compliance vs speed\n\nIn an enterprise-wide mission critical application where security and compliance are paramount, a deployment cadence of once a quarter is considered satisfactory, but in a consumer-facing containerized application (using [microservices](https://about.gitlab.com/topics/microservices/)), multiple deployments can be easily achieved in a single day. Release speeds can differ but software security isn't negotiable. Every organization needs to ensure security by making sure best practices are followed for all application development processes. Ultimately, the ideal situation for every organization would be shortened development cycle times, while at the same time enabling developers to identify any security issues ahead of time. Rather than integrating security tools into the complex DevOps toolchain, a single application for the entire software development lifecycle can improve your security risk posture, simplify compliance/audit, and accelerate software development. With [DevSecOps methodologies](/solutions/security-compliance/), security testing becomes an integral part of the software development lifecycle (SDLC) eliminating friction between siloed development and security teams, and dramatically improving code quality and deployment cycle times.\n\n## Increase collaboration and automation\n\nDevOps practices and elastic cloud computing resources helpdevelopers become more self-sufficient as they deploy their applications at scale. They can request identical compute resources on every new release of their application. Automating the deployment steps through a CI/CD pipeline makes rolling out the new version of an application more efficient and less prone to errors. While [CI/CD tooling](/topics/ci-cd/) increases automation for software inspection, development and delivery, resilient systems like IBM Z or RedHat OpenShift Container Platform have their own built-in automation to address application testing, reliability and availability.\n\nMost organizations have a security team that looks at the risk posture of an application. This can range from high availability of applications for business continuity reasons, to a vulnerability in a software library. In most cases, the security team is much smaller than the application development teams and uses different tools to analyze risks. This creates an impediment for organizations to scale and applications to scale in production. Using the same workflow and shared data model between security and development teams allows knowledge sharing and helps break down team silos. For example, a Red Hat OpenShift application developer can create a security Issue in their GitLab Ultimate DevOps Platform, and the security team can comment on that same issue and analyze the risk.\n\nCloud computing and its elasticity offers advantages for certain applications and use cases while on-premise systems like IBM Z offer advantages for high transaction applications and use cases. Red Hat Openshift offers a cloud native approach to application deployments. GitLab Ultimate integrates with container platforms as well as IBM Z environments. This gives customers the flexibility to deploy their application in their desired environment while helping increase automation and Agile practices in their organization.\n\nTo learn more\n\n* Visit[ GitLab Ultimate for IBM z/OS](https://www.ibm.com/products/gitlab-ultimate/zos)\n* Hear GitLab and IBM experts discuss the benefits of integrating GitLab into your DevOps solution -[Automate your Z DevOps CI/CD pipeline with GitLab](https://mediacenter.ibm.com/id/1_djnxx05v)\n* Learn about the management of mainframe apps lifecycle with[IBM Z DevOps and GitLab](https://mediacenter.ibm.com/id/1_oxj8eseu).\n* Take advantage of the[DevOps Acceleration Program](https://ibm.github.io/mainframe-downloads/DevOps_Acceleration_Program/devops-acceleration-program.html) to partner with IBM for a successful transformation\n","culture",[891,9,912],"workflow",{"slug":914,"featured":6,"template":698},"adopt-agile-and-devops-for-ibm-z","content:en-us:blog:adopt-agile-and-devops-for-ibm-z.yml","Adopt Agile And Devops For Ibm Z","en-us/blog/adopt-agile-and-devops-for-ibm-z.yml","en-us/blog/adopt-agile-and-devops-for-ibm-z",{"_path":920,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":921,"content":927,"config":935,"_id":937,"_type":13,"title":938,"_source":15,"_file":939,"_stem":940,"_extension":18},"/en-us/blog/advice-for-women-seeking-careers-in-tech",{"title":922,"description":923,"ogTitle":922,"ogDescription":923,"noIndex":6,"ogImage":924,"ogUrl":925,"ogSiteName":685,"ogType":686,"canonicalUrls":925,"schema":926},"Women in Tech: Use Your Uniqueness as a Career Superpower","GitLab's Women's Team Member Resource Group shares tips on how to make a mark in this industry.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749677856/Blog/Hero%20Images/collaboration.png","https://about.gitlab.com/blog/advice-for-women-seeking-careers-in-tech","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Use your uniqueness as a superpower and other advice for women seeking careers in tech\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Kyla Gradin Dahl\"}],\n \"datePublished\": \"2022-04-04\",\n }",{"title":928,"description":923,"authors":929,"heroImage":924,"date":931,"body":932,"category":910,"tags":933},"Use your uniqueness as a superpower and other advice for women seeking careers in tech",[930],"Kyla Gradin Dahl","2022-04-04","\n\nGitLab's [Women's Team Member Resource Group (TMRG)](/company/culture/inclusion/tmrg-gitlab-women/), a forum for women to find their voice and be heard, celebrated Women's History Month by reflecting on what it means to be a woman in technology, how they arrived here, and who inspires them. We also gathered advice for other women who want to enter or advance in this industry.\n\n## Tips for women in tech\n\nAt GitLab, we work within our [CREDIT values](https://handbook.gitlab.com/handbook/values/#credit) every day. The organization’s [team member resource groups](/company/culture/inclusion/erg-guide/) amplify our value of [Diversity, Inclusion, and Belonging](https://handbook.gitlab.com/handbook/values/#diversity-inclusion). And, aligned with our value of [transparency](https://handbook.gitlab.com/handbook/values/#transparency), we’re able to share the voices of our TMRG here with our wider GitLab community.\n\nBelow are perspectives from:\n- [Jane Gianoutsos](https://gitlab.com/jgianoutsos), Manager, Support Engineering\n- [Michelle Hodges](https://gitlab.com/mwhodges), VP of Global Channels\n- [Taharah Nix](https://gitlab.com/tnix), Associate Paralegal, Employment\n- [Sherrod Patching](https://gitlab.com/spatching), Senior Director, Technical Account Manager\n- [Juliet Wanjohi](https://gitlab.com/jwanjohi), Senior Security Engineer, Security Automation\n\n**What advice would you give to women who are considering a career in technology?**\n\n**Michelle:** Unapologetically go for it. The industry requires diverse collaborators and contributors to make sure that the technology that runs the world, our schools, our homes, etc. is made by people with diverse backgrounds, perspectives, and life experiences. Just by showing up in technology, you make a meaningful impact on the world today and for the future. \n\n**Sherrod:** Honestly, I believe that anyone from any background can be successful and fulfilled in tech. Before pivoting into tech, I started my career as a musician. In tech, we are constantly creating, which is incredibly fulfilling as a creative person.\n\n**Taharah:** I would say that there's a place for everyone in tech. A lot of times people can be intimidated when they think of working for a tech company because they may not have the experience that they think they need. However, just as with any other company, there are a lot of different business needs within the company and all perspectives are necessary. So, I would say think about what you're most comfortable doing and expand from there. There are endless opportunities for learning.\n\n**Juliet:** The first step when considering moving into a career in the technology industry would be to come up with a strategy - explore the different pathways available and identify your area of interest. The next step would be to look at ways of leveling up your skills and knowledge by doing certifications, reading books, and listening to podcasts/audiobooks related to your area of interest. \n\nLeverage your network and community connections by reaching out and having [coffee chats](/company/culture/all-remote/informal-communication/#coffee-chats) with individuals who are in the tech field to get more insight and advice on how they got into the industry and tips that helped them along the way.\n\n**What tips do you have for women working towards being senior leaders?**\n\n**Michelle:** Leadership requires authenticity in self while being focused on the success of those you lead. Know where you want to go and build those experiences into your CV intentionally. Grit and resilience will serve you well - so build them into your wheelhouse.\n\n**Sherrod:** Lead by example, even if you are in an individual contributor role. Some of the best leaders I know led long before they had a team. Know where you are going, determine the milestones to getting there, and follow through on execution.\n\n**Juliet:** Taking the lead in shaping conversations about your career path with your manager is definitely important. You can do this by drawing up a roadmap or a plan of what you aspire to achieve, and where you'd like to be in the future, and being accountable by making a habit of evaluating your progress towards your goal of becoming a senior leader. Another essential tip would be to work towards increasing your sphere of influence and forming a network of professional relationships outside of your immediate team, as this opens a doorway for more collaboration opportunities with other teams and a chance to continually hone and fine-tune your leadership skills.\n\n**Did you have any women mentors (formal or informal) when you were building your career? What was some key advice they gave you and how important do you think mentorship is for future leaders?** \n\n**Michelle:** Your “otherness” is your superpower. You have a unique way of approaching problems, leading people, and showing up in a team setting - lean into that. Don’t let your otherness impact your authenticity. Not always but often, boys are raised to be brave while girls are raised to be perfect. Do not let your desire to be perfect stand in the way of taking risks, being brave, and being authentic. \n\n**Sherrod:** I have had mentors, but not women mentors. I can't advocate enough for having someone further along than you that can help you see things from angles you can't yet see from.\n\n**Juliet:** Yes, and I still do! One key [piece of] advice that I received at the start of my career from one of my mentors was to leap out of my comfort zone and go where the opportunities are. Waiting for your career to build itself rarely works, it is up to you to be committed and work towards getting those opportunities that you feel will uplift you and get you one step closer to your goal. \n\nMentorship is an integral piece for future leaders because it gives them an opportunity to shadow and seek advice from women who have had more experience with climbing the tech career ladder, and can help them map out their career path in accordance with their interests and goals. Having a mentor also gives them the chance to receive honest and constructive feedback on any challenges that they may face, and how they can potentially turn these challenges into growth opportunities!\n\n**What has been the proudest moment in your career so far and why?** \n\n**Michelle:** Seeing previous employees and mentees thrive in their careers.\n\n**Sherrod:** One moment that comes to mind is having led the acquisition of another company in my previous role before GitLab. I led the process and was considerably out of my comfort zone, which is when I learn the most. \n\n**Jane:** I’m proud of:\n- Earning not only the trust but the respect of a team member who was adamant I was the wrong person for the role when I was being appointed to it.\n- The card I received at a farewell saying I was the most effective manager the highly regarded engineer had worked for.\n- The unexpected recommendation and thanks written for me on LinkedIn by someone I had encouraged to notice his leadership skills and who went on to do just that.\n- The call I got from a third party after another person’s farewell from an ex-employer to tell me how much that departing person referred to my influence during their farewell speech.\n- The customer who insisted on coming to my farewell with flowers and champagne.\n- The peer I first worked with in 2005 who I still discuss career growth and life decisions with.\n\n**How important are GitLab’s values in building an inclusive culture for women at GitLab?** \n\n**Michelle:** Vitally important. In the workplace, whether it's GitLab or not, women have a responsibility to drive the change that creates not only an equal workplace but an equitable workplace. Equitable meaning working motherhood, caretaking, many women’s belief they need to be perfect, the imbalance of gender or URG representation, etc. - all these and more need to be accounted for to create a truly equitable work environment \n\nGitLab’s culture provides a space for women to lean into this responsibility, speak up, and make iterative and incremental changes that will impact future generations of women in the workplace and women leadership.\n\n**Sherrod:** Incredibly. I am a wife and a mom of two little girls first and foremost, and GitLab makes it possible to have a career and a career trajectory while also not sacrificing my family. \n\n**Jane:** GitLab has genuinely been life-changing for me. Through necessity, I’ve always been ok with being often the only woman in the tech team or even the company - or at least I thought I was ok with it!\n\nThen I started working here and discovered what it was to have space held for every voice, where I wasn’t reliant on allies to hold space or amplify my voice or sanity-check my suspicions about bad behaviors. Where [microaggressions](https://handbook.gitlab.com/handbook/values/#understanding-the-impact-of-microaggressions) are understood and challenged if they occur, where I don’t have to fight to advocate for the [uniqueness of people](https://handbook.gitlab.com/handbook/values/#quirkiness) but am empowered to support the fulness of all my team and colleagues, where we [normalize talking to each other](https://handbook.gitlab.com/handbook/values/#see-something-say-something) when we see old bad habits in play and where we do that with kindness.\n\nI’ve been moved to tears by people’s kindness, by the depth of inclusion I have come to experience here. I am often left pondering how very different things would have been for me had I experienced this in the early years of my career. I have no doubt mine would have been a very different journey, where I could have expended less energy on battling self-doubt and on healing, and more on growth and contribution.\n\n_The Women’s TMRG also invited [Christie Lenneville](/handbook/product/ux/one-pagers/christie-readme/), GitLab VP of UX, to share her experiences during a live speaker series, open to everyone at the company. You can watch the replay of the conversation below._\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/a10N6xYB7Ps\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n\n",[934,737,9],"inside GitLab",{"slug":936,"featured":6,"template":698},"advice-for-women-seeking-careers-in-tech","content:en-us:blog:advice-for-women-seeking-careers-in-tech.yml","Advice For Women Seeking Careers In Tech","en-us/blog/advice-for-women-seeking-careers-in-tech.yml","en-us/blog/advice-for-women-seeking-careers-in-tech",{"_path":942,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":949,"config":955,"_id":957,"_type":13,"title":958,"_source":15,"_file":959,"_stem":960,"_extension":18},"/en-us/blog/agile-best-practices",{"title":944,"description":945,"ogTitle":944,"ogDescription":945,"noIndex":6,"ogImage":946,"ogUrl":947,"ogSiteName":685,"ogType":686,"canonicalUrls":947,"schema":948},"5 Agile best practices","Make the most out of Agile development with these technical best practices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678597/Blog/Hero%20Images/run-agile-in-gitlab.jpg","https://about.gitlab.com/blog/agile-best-practices","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 Agile best practices\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-08-13\",\n }",{"title":944,"description":945,"authors":950,"heroImage":946,"date":952,"body":953,"category":693,"tags":954},[951],"Suri Patel","2019-08-13","\n\n[Agile development](/solutions/agile-delivery/) can have\na transformative impact on teams and applications. These five best practices can\nhelp your team streamline and accelerate delivery.\n\n## 1. Continuous integration\n\n[Continuous integration](/solutions/continuous-integration/) works by pushing small code chunks\nto an application’s codebase hosted in a Git repository. Every push triggers a pipeline of scripts to build,\ntest, and validate code changes before merging them into the main branch. By\nbuilding and testing each change as early as possible – usually several times a\nday – teams can detect errors as quickly as possible, reduce integration problems,\nand avoid compounding problems, allowing teams to develop faster, with more confidence.\n\n## 2. Retrospectives\n\n[Retrospectives](/blog/how-we-used-gitlab-to-automate-our-monthly-retrospectives/) are conversations about what went well and what went wrong in a\nproject or iteration. One of the most important Agile qualities is continuous\nlearning, and retros provide a transparent way to discuss how various teams\nexperienced a sprint and voice any concerns or ideas.\n\n> “A successful team is a happy team. Bringing down cycle time can help a team be more\nsuccessful because they are shipping value more often, but your team might have more\nimportant things that must be addressed first. Using retrospectives will help you figure\nout what success means to your team, and what needs to be done to achieve\nthat success.” – [Rachel Nienaber](/company/team/#rnienaber), engineering manager, Geo\n\nTo generate the best results from a retrospective, there should be\n[a safe environment for feedback and discussion and a plan for advancing discussion\nfrom facts to\nconclusions](/handbook/engineering/management/group-retrospectives/).\n\n## 3. Pairing\n\nPairing sessions can help team members work through features both large and small,\ninspiring problem-solving and ideation. When pairing, one team member writes code\nwhile the other reviews each line. Pairing results in fewer bugs, increased innovation,\nand skills development. Team members can learn from each other and discover best\npractices. Team members can spontaneously pair or managers can set up a more\n[formal pairing session process](https://gitlab.com/gitlab-com/support/support-training/issues?label_name%5B%5D=pairing) 🍐\n\n## 4. Iterative development\n\nWhen teams iterate with small changes, they can\n[reduce cycle time](/blog/strategies-to-reduce-cycle-times/) and spark rapid feedback cycles.\nBy making the quickest changes possible to improve a user's outcome, teams can add\nuseful functionality with fewer bugs or usability issues since potential problems\nare spotted early. Other benefits of iterative development include faster time to\nmarket, reduced scope creep, and increased morale (i.e. team members can see their\nwork right away rather than wait several releases).\n\n## 5. Burndown charts\n\nIf your team uses a Scrum framework, consider using [burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) to monitor\nsprint progress. Teams can visualize the work scoped in the current sprint to\nunderstand what work has been completed, allowing them to react to risks quickly\nand adapt. This information can help business stakeholders understand that anticipated\nfeatures may be delayed until a future sprint.\n\nEmploying Agile best practices will have a significant positive impact on efficiently\ncreating customer-centric products.\n\nDo you have any best practices that have transformed your team’s development process? We’d love to hear them!\n\nCover image by [Mikael Kristenson](https://unsplash.com/@mikael_k?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/6GjHwABuci4)\n{: .note}\n",[891,9,695,912],{"slug":956,"featured":6,"template":698},"agile-best-practices","content:en-us:blog:agile-best-practices.yml","Agile Best Practices","en-us/blog/agile-best-practices.yml","en-us/blog/agile-best-practices",{"_path":962,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":963,"content":969,"config":974,"_id":976,"_type":13,"title":977,"_source":15,"_file":978,"_stem":979,"_extension":18},"/en-us/blog/agile-for-developers-refactor-code",{"title":964,"description":965,"ogTitle":964,"ogDescription":965,"noIndex":6,"ogImage":966,"ogUrl":967,"ogSiteName":685,"ogType":686,"canonicalUrls":967,"schema":968},"Agile for developers: Refactoring code","The time commitment involved in refactoring may cause hesitation, but the impact on developer productivity and efficiency outweighs the initial discomfort.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680945/Blog/Hero%20Images/refactorpost.jpg","https://about.gitlab.com/blog/agile-for-developers-refactor-code","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Agile for developers: Refactoring code\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-12-18\",\n }",{"title":964,"description":965,"authors":970,"heroImage":966,"date":971,"body":972,"category":300,"tags":973},[951],"2019-12-18","\n\nIt’s difficult to cook in a cluttered, untidy kitchen. You need a specific knife, but it needs to be washed. You need that one mixing bowl, but it’s not in the cabinet where you usually keep it. You can’t find a place for the cutting board, because the countertop has no room. Software development is similar to cooking - you need a tidy codebase to deliver rapidly. If you don’t clean your code as you develop, you can find yourself surrounded by a mess. Fortunately, refactoring code helps you keep your [source code](/solutions/source-code-management/) neat and tidy.\n\n## Refactor code to accelerate Agile delivery\n\nRefactoring simplifies the design of code, without altering its behavior, to increase maintainability and readability. Teams refactor code before adding updates or releasing features in an effort to improve code quality so that future iterations built on original code are not bogged down by confusion and clutter. As such, this process helps to [accelerate Agile delivery](/solutions/agile-delivery/).\n\n> “None of my inventions came by accident. I see a worthwhile need to be met and I make trial after trial until it comes.” — Thomas Edison\n\nRefactoring isn’t a random exercise in which developers tinker with code. It’s a precise process designed to enhance the internal structure of a program’s source code. While it may seem like a tedious task, refactoring has long-term business value. \n\n## How to get started with refactoring\n\nStaring at unrefactored code trying to determine where to start can be a frightening experience. Fortunately, there are a few methods you can use to make refactoring a little easier. \n\n### Incremental refactoring\n\nThe simplest way to get started is to make small improvements. Make a list of the parts of your system that change most often and refactor those areas. Making incremental improvements on the files that your team works with most often can help you steadily work through your code. By targeting the areas that are used most often, refactoring can have a significant impact on your overall system.\n\n### Test-driven development\n\nYou can think of test-driven development as cleaning as you’re coding. If you’d like to revolutionize the way your team develops and make refactoring an integrated aspect of your workflow, you can embrace test-driven development, which incorporates coding, unit tests, and refactoring to program in short development cycles. Developers write a failing automated test to define a new function before writing the smallest amount of code to pass the test. The code is then refactored to an ideal state.\n\n## The benefits of refactoring code\n\nRefactoring prevents code rot, such as bad dependencies between classes, myriad patches, incorrect allocation of class responsibilities, and duplicate code, resulting in a more efficient code base. The time taken to refactor pays dividends, since it’s easier to clean code closer to when it was written rather than rush to fix problems later.\n\nThe time commitment involved in refactoring may cause hesitation, but the impact on developer productivity and efficiency outweighs the initial discomfort. When developers take the time to refactor, they continually maintain a tidy source code so that other developers can easily deliver without running into problems. Refactoring helps create a culture of shared responsibility, trust, and collaboration.\n\nWith refactoring, the QA and debugging stages are simpler, since there is more cohesion to the overall code. Furthermore, software assets can be extended for years, allowing users to experience prolonged value rather than dealing with an unusable system. \n\n## What’s next for your team?\n\nAgile techniques have the power to transform your team’s culture, sparking seamless delivery, innovation, and collaboration. Depending on your team’s challenges, there’s a technique to help your team through it. With [pairing sessions](/blog/agile-pairing-sessions/), your developers can bridge knowledge gaps, increase communication, and develop solutions to challenging problems. By [strengthening group development](/blog/how-to-strengthen-agile-teams-with-tuckmans-model/), you can help your team rebuild after breaking down silos. When your team [embraces an Agile mindset](/blog/agile-mindset/), they’re more flexible and can easily adapt to changes. Refactoring is one step in a journey to help your team cultivate a strong Agile culture. \n\nCover image by [Barn Images](https://unsplash.com/@barnimages?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/t5YUoHW6zRo)\n{: .note}\n",[891,9,912],{"slug":975,"featured":6,"template":698},"agile-for-developers-refactor-code","content:en-us:blog:agile-for-developers-refactor-code.yml","Agile For Developers Refactor Code","en-us/blog/agile-for-developers-refactor-code.yml","en-us/blog/agile-for-developers-refactor-code",{"_path":981,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":982,"content":988,"config":993,"_id":995,"_type":13,"title":996,"_source":15,"_file":997,"_stem":998,"_extension":18},"/en-us/blog/agile-mindset",{"title":983,"description":984,"ogTitle":983,"ogDescription":984,"noIndex":6,"ogImage":985,"ogUrl":986,"ogSiteName":685,"ogType":686,"canonicalUrls":986,"schema":987},"What is an Agile mindset?","Learn how embracing change can help you speed up software delivery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680634/Blog/Hero%20Images/agilemind.jpg","https://about.gitlab.com/blog/agile-mindset","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What is an Agile mindset?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-06-13\",\n }",{"title":983,"description":984,"authors":989,"heroImage":985,"date":990,"body":991,"category":693,"tags":992},[951],"2019-06-13","\n\n\nEnsuring [Agile](/solutions/agile-delivery/) teams use the most [effective strategies](/solutions/agile-delivery/) to reduce cycle time is a\npriority for IT leaders, but what good is a menagerie of techniques if a team’s\napproach to software development doesn’t spark innovation? When it comes to\nbuilding the foundation for accelerating delivery, IT leaders have been incorrectly\nplacing emphasis on collecting tools rather than developing an Agile mindset.\n\n> “The core of Agile is recognizing that we need to get to and maintain an Agile mindset. **If I have an organization with an Agile mindset, and really rock-solid product management, Agile processes and tools will evolve out of that. If you have the Agile mindset and an awesome connection with your customers and are solving their problems, things will evolve in the right way.** You won’t even realize you’re being Agile. It’s just good business.” — [Todd Little](https://www.forbes.com/sites/stevedenning/2016/06/07/the-key-missing-ingredient-in-the-agile-manifesto-mindset/#4fa5917467ff), CEO Lean Kanban\n\nThere are many definitions of an Agile mindset, but the general consensus is that it:\n\n* Views setbacks as learning opportunities\n* Embraces iteration, collaboration, and change\n* Focuses on delivering value\n\n## Agile mindset characteristics\n\nThere’s no definitive list of what makes up an Agile mindset, but with the\nintention of getting you started, here are a few of the most widely accepted\ncharacteristics. Based on your team’s dynamics, your organization’s culture, and\nyour goals, you may adopt other attributes to help your team accelerate delivery.\n\n### Setbacks are learning opportunities\n\nEmpower your team to experiment and be creative so that rather than view a setback\nas a failure, they’ll see it as an opportunity to learn and grow. When your team\nhas the freedom to be innovative – without fear – they’re more likely to solve\nproblems and add to the knowledge base of what works and what doesn’t.\nTaking risks shouldn’t be a rebellious endeavor — it should be your team’s norm.\n\n### Agile values and principles: Iteration, collaboration, and change\n\n**Iteration**: Instill the belief that there’s always room for improvement and\nthat anyone can propose a change or idea. At GitLab, we believe\n[everyone can contribute](/company/mission/#mission) and that [iteration is the fastest\nway to feedback](https://handbook.gitlab.com/handbook/values/#iteration), helping us course correct and\ncreate new features.\n\n**Collaboration**: Finding ways to improve and increase cross-collaboration\nenables frictionless handoffs, helps relieve the burden on teams, and facilitates\na culture of trust and communication. Whether you develop new workflows or use\ndifferent tools, keep an eye out for silos which can work against collaboration.\n\n**Change**: Agile methodology is founded on the ability to adapt to\nunpredictability. If your customers or organization want to pivot soon after a\ndirection is set, your team should be able to do just that. Any\nprocesses or roadblocks that prevent your team’s ability to be flexible and\nembrace change should be removed.\n\n### Deliver value\n\nWe can all agree that teams should deliver value both to customers and the\norganization. But where an Agile mindset makes all the difference is shifting the\nemphasis from the output, which focuses only on the items delivered, to the\noutcome, which is how a feature meets a market need. An Agile mindset helps teams\ncreatively think of how a feature can solve a problem rather than feel pressured\nto deliver a set number of items in a month. It’s the whole “quality over quantity” idea.\n\n## Steps to shift to an Agile mindset\n\nChanging your team’s perspective and the way they approach problems is a difficult\nundertaking. You’re challenging their long-held beliefs while requiring them to\ncomplete tasks and meet deadlines. This is an uncomfortable process in any\nenvironment, but especially in the workplace where an (in)ability to quickly\nshift can impact performance and reputation. Fortunately, there are a few\nmethods to help you navigate these difficulties and enable your team to smoothly\nadopt an Agile mindset:\n\n\n1. **Model behavior**: The most effective way to help your team shift to an Agile\nmindset is to exemplify the behaviors you want to see. To create a\n“no-fault, embrace risk” environment, share your setbacks with the team and tell\nthem what you learned. When someone experiments, praise them for trying something\nnew and discuss the biggest lessons learned. By being transparent and showing your\nteam that this new way of thinking is possible, you become their collaborator.\n1. **Storytelling**: Share how other organizations or teams have benefited from\nan Agile mindset. Understanding what others gained from a new way of\nthinking can help your team feel more enthusiastic about the change.\n1. **Take small steps**: After doing more research about an Agile mindset, you\nmight get excited and feel tempted to change things overnight. Take small steps\nand make minor adjustments in the beginning to help your team acclimate.\n\n## What's the impact?\n\nWith an Agile mindset, teams can quickly adjust to changing market needs, respond\nto customer feedback, and deliver business value. Adopting a new perspective can\npositively change a team’s culture, since the shift permits innovation without fear,\ncollaboration with ease, and delivery without roadblocks.\n\nCover image by [Benjamin Voros](https://unsplash.com/@vorosbenisop?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/X4bgpcGBNAY)\n{: .note}\n",[891,9,695,912],{"slug":994,"featured":6,"template":698},"agile-mindset","content:en-us:blog:agile-mindset.yml","Agile Mindset","en-us/blog/agile-mindset.yml","en-us/blog/agile-mindset",{"_path":1000,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1001,"content":1007,"config":1012,"_id":1014,"_type":13,"title":1015,"_source":15,"_file":1016,"_stem":1017,"_extension":18},"/en-us/blog/agile-pairing-sessions",{"title":1002,"description":1003,"ogTitle":1002,"ogDescription":1003,"noIndex":6,"ogImage":1004,"ogUrl":1005,"ogSiteName":685,"ogType":686,"canonicalUrls":1005,"schema":1006},"Improving pair programming with pairing sessions","Pairing with a teammate can increase delivery. Here we look at what pairing sessions are, what they involve and what they're good for.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665897/Blog/Hero%20Images/incrementalcodedevelopment.jpg","https://about.gitlab.com/blog/agile-pairing-sessions","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Improving pair programming with pairing sessions\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-08-20\",\n }",{"title":1002,"description":1003,"authors":1008,"heroImage":1004,"date":1009,"body":1010,"category":693,"tags":1011},[951],"2019-08-20","\nArya and Sansa. Han and Chewbacca. Harry and Ron. When people team up, great things can happen.\n\n## What is pair programming?\n\nPair programming, an Agile approach to software development, involves two programmers working together at the same workstation. One programmer (called the driver) writes code while the other programmer (called the navigator) reviews code in real time. Pairing sessions can accelerate [Agile delivery](/solutions/agile-delivery/), because teammates work together to find the best solutions to several challenges. \n\nRather than working in silos, team members work together to share knowledge and quickly move through obstacles. Sounds good, right? Well, some organizations view pair programming as an inefficient use of time. After all, why should two developers work on the same piece of code when there’s a mountain of technical debt, an impending release, and lingering OKRs around the corner?\n\n## How to get started with pair programming\n\nThe key to any successful paired programming partnership is open communication and creating a plan together so you can avoid bottlenecks during the project process. \n\nHere are a few things you need to consider as a team before beginning any coding work:\n\n* Have a mutual understanding of what “ready” looks like for this project. Consult each other as well as any stakeholder involved, like a product owner, so that everyone is clear on when to give the projects a final green light. \n* Create a step-by-step project plan. Consider how you will trade off coding and reviewing responsibilities, how you want to handle testing, and any other external help you may need to complete the project. \n* Brainstorm as many potential roadblocks as you can think of in this planning process, and try to come up with potential solutions. You can brainstorm together on paper, talk it out, or go off separately and then share thoughts, but this is an important step. Always be prepared!\n* Agree on the technology you want to use. From computers and keyboards to reliable wifi or a whiteboard, make sure you have all of the tools you need.\n\n## Some pair programming best practices\n\nTo achieve the best outcome of your pair programming experience, we recommend you follow these best practices:\n\n* **ABC (Always be communicating).** Regardless of whether you’ve worked well together in the past or you’re a brand new partnership, the importance of communication can’t be overstated. Two individuals are likely to have different thoughts and opinions along the way. To keep the project (and yourselves) from suffering, establish open and frequent communication practices early.\n* **Take turns.** No single person has to be the only one navigating or driving, and you shouldn’t. Take turns in each role as often as you need to make sure your minds and eyes stay fresh and you keep producing quality work.\n* **Take a break.** Rome wasn’t built in a day, and neither was coding. You and your pair programming partner need to make sure to take breaks so as not to induce burnout. \n* **Get good technology tools.** And remember to click that video on. Oftentimes, pair programming is done remotely. It can help to have an actual facetime conversation, even if it’s virtual, to stay connected and communicative throughout the course of the partnership. \n* **Ask for help.** If there is a part of your project that both of you don’t understand, ask for clarification. Better to ask ahead of project completion than after. \n\n## The case for and against pair programming\n\nThere are benefits and drawbacks to pairing sessions, so a few GitLab team members\nshared their thoughts to help you determine whether pair programming is right for you.\n\n> “I've done pair programming in the past. I love it because it helps to bounce\nideas off people, and I find we often could solve ‘bigger’ problems faster. To me,\nthe downside is measuring/proving that this is a good method of programming since\nmany people see this as inefficient (two people working on the same problem).” –\n[Cynthia Ng](/company/team/#TheRealArty), senior support agent\n\nToday’s developer feels the pressure of delivering at rapid speeds. Sometimes, a\nchallenge is just too complex for one person to solve, and pairing sessions can\nhelp alleviate the difficulties experienced when racing towards a release while\ncarrying a burdensome issue. Talking through solutions and drawing on each other’s\nexperiences can help a pair work towards a new approach.\n\nMeasuring the effectiveness of pairing sessions might be difficult, but there are ways to\nevaluate success. Considering failures in functionality, the number of\nbugs, and improvements in productivity can help teams determine whether pairing\nmakes a difference with delivery.\n\n### The role of engagement and continuous learning in delivery\n\nIT leaders may be reluctant to embrace pairing, since two developers dedicate\ntheir time to a single problem, but it’s important to note researchers have\nfound that\n[90% of new skills learned are lost due to lack of\nengagement](https://www.wsj.com/articles/SB10001424052970204425904578072950518558328),\nand in an Agile framework, a culture of continuous learning helps improve all aspects of delivery.\n\n> “When I was a junior developer, I found it very helpful to talk through my\nthought process and hear how senior developers approached the same problem. But,\nas an introvert, I found it exhausting to do all day, every day.” –\n[Jennie Louie](/company/team/#jennielouie), test automation engineer, Enablement\n\nAgile models often include the value of continuous learning to help everyone –\nfrom C-level to junior level – develop new skills to remain adaptable and productive.\nPairing sessions provide a platform from which teammates can learn in tandem.\n\n> “I’ve never done ‘strict’ pairing with a driver/navigator, only the relaxed kind\nwhere you just chat and sometimes switch keyboards. And while I can't really imagine\npairing full-time, I guess with the right pair and some practice it could indeed be\na great experience.” – [Markus Koller](/company/team/#toupeira), backend engineer, Create:Editor\n\nThe drawbacks to pair programming might make you hesitate, but I encourage you to\ntake a chance on it, especially if you want to accelerate delivery. Here are a\nfew pros and cons of pairing to help you understand the process:\n\n### Advantages of pair programming\n\nDirectly collaborating with a teammate can increase morale and inject fun and\ndiversity in one’s day. By working alongside each other, teammates can learn\ndifferent coding practices, workflow techniques, and new ways of approaching\nproblems, which increases innovation and efficiency and decreases knowledge silos.\n\n> “Pair programming can be great for onboarding, mentoring, and [rubber ducking](https://en.wikipedia.org/wiki/Rubber_duck_debugging)\ndifficult problems, since teammates receive immediate\nfeedback.” – [Andrew Kelly](https://gitlab.com/ankelly), senior security engineer, [Application Security](/topics/devsecops/)\n\nJunior developers benefit when pair programming with senior developers, since they’ll\ngain strong industry knowledge. Meanwhile, senior developers get teaching experience\nand the ability to think critically about solutions.\n\n> “Programming is fairly abstract. When you have to explain a concept verbally, it\noften makes you realize you're missing pieces or that there are better\nways to solve problems than your initial idea.” – [Brandon Lyon](/company/team/#brandon_m_lyon), marketing web developer/designer\n\nRegardless of experience level, everyone can benefit from pairing sessions, since\nthere is no right answer in programming. I consider software development a multi-faceted\nendeavor in which imagination and creativity are driving forces. Based on knowledge,\nexperience, and learning styles, people approach some aspects of code with\na different understanding of how it ties into existing systems. When pairing, people can\ndiscuss these perspectives and assess which approach is best.\n\n### Disadvantages of pair programming\n\nPairing might sound like the solution to many of your delivery problems, but it’s\nnot all roses and rainbows.\n\nGiven the success of pairing, teammates might be tempted to join forces a little\ntoo often. Pair programming can feel inefficient if overdone or used for tasks\nsuch as boilerplate code, smaller and well-defined changes, and [yak shaving](https://www.techopedia.com/definition/15511/yak-shaving).\n\n> “Pair programming is not a silver bullet. Some software solutions just need a\nsingle person to hunker down and work it out before sharing with others.” – [Andrew Kelly](https://gitlab.com/ankelly)\n\nIf teams are just starting out with pairing, it can take practice and patience\nto be a “good pair,” which can be difficult even for experienced pair programmers.\nDo retros after a pairing session to understand what worked well, what didn’t work,\nand how you can improve future sessions.\n\n## See it in action\n\nNow that you know a bit more about pair programming, you might feel ready to take\nthe plunge. At GitLab, we 💖 pairing. Most pairing sessions occur when developers\nwork at the same station, but as an [all-remote company](/company/culture/all-remote/),\nwe’ve found ways to make it work.\n\n> “Remote pair programming can be tougher than in-person pairing. Distance plus the\ntooling isn’t always the best, but it’s not impossible.” – [Andrew Kelly](https://gitlab.com/ankelly)\n\nGitLab’s Support team created a [dedicated project and issue templates for pairing\nsessions](https://gitlab.com/gitlab-com/support/support-training/issues?label_name%5B%5D=pairing).\n\n> “In Support, we do pairing sessions (or group ‘crush sessions’) and find we often\nget through _more_ tickets when working together, so it's something we're tracking\nas a milestone for each quarter.” – [Cynthia Ng](/company/team/#TheRealArty)\n\nOver in engineering, the Frontend team has also been [experimenting with how to support\npair programming](https://gitlab.com/gitlab-org/frontend/general/issues/12). The\nteam has used VSCode live share a few times but enjoys open discussion and sending\npatches to each other.\n\n> “The best format so far is someone posts a \"🍐 request\" in the #frontend_pairs\nSlack channel – people show interest – a time is scheduled on the calendar – then\nwe do somewhat of a mob programming session.” – [Paul Slaughter](/company/team/#pslaughter), frontend engineer, Create:Editor\n\nEvery software team hears the importance of acceleration, and it can be a daunting\nthought, especially when faced with complex problems. The next time you find\nyourself dragging your fingers across the keyboard and dreading that next line of\ncode, consider pairing up with a teammate to tackle issues together.\n\n> “Pairing will look different for everyone. Anything that encourages\ncommunication, engaged knowledge sharing, and breaking our engineering silos is\ngood.” – [Paul Slaughter](/company/team/#pslaughter)\n\nCover image by [Jonathan Mast](https://unsplash.com/@jonathanmast) on [Unsplash](https://unsplash.com/photos/RW6Wz9QaoKk)\n{: .note}\n",[891,9,695,912],{"slug":1013,"featured":6,"template":698},"agile-pairing-sessions","content:en-us:blog:agile-pairing-sessions.yml","Agile Pairing Sessions","en-us/blog/agile-pairing-sessions.yml","en-us/blog/agile-pairing-sessions",{"_path":1019,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1020,"content":1026,"config":1033,"_id":1035,"_type":13,"title":1036,"_source":15,"_file":1037,"_stem":1038,"_extension":18},"/en-us/blog/agile-planning-with-a-devops-platform",{"title":1021,"description":1022,"ogTitle":1021,"ogDescription":1022,"noIndex":6,"ogImage":1023,"ogUrl":1024,"ogSiteName":685,"ogType":686,"canonicalUrls":1024,"schema":1025},"Agile planning with a DevOps platform","How a DevOps platform enables an entirely different way to plan and manage work","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669233/Blog/Hero%20Images/photo-1531403009284-440f080d1e12.jpg","https://about.gitlab.com/blog/agile-planning-with-a-devops-platform","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Agile planning with a DevOps platform\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Cormac Foster\"}],\n \"datePublished\": \"2021-05-19\",\n }",{"title":1021,"description":1022,"authors":1027,"heroImage":1023,"date":1029,"body":1030,"category":1031,"tags":1032},[1028],"Cormac Foster","2021-05-19","\n\nSeveral years ago, a portfolio manager asked me if he needed to learn about “all the stuff the [DevOps](/topics/devops/) people do.” I told him yes, explained why it was worth it to “learn their language,” and discussed how he could extract nuggets of information to help unlock product value. It was good advice at the time, but it didn’t answer the bigger question—“Sure, he *should*, but should he *have to*?” \n\nThe answer to that question is no. He already had a job—managing a P&L for several products. He shouldn’t have to learn another job just to do that one well. \n\nTools are rarely the solution, but they’re often the problem. At the time, without custom integration, lots of digging, manual translation, and a little bit of luck, there just wasn’t a good way to surface all the information the portfolio manager needed to do his job well. At best, he’d receive batched reports from different tools in his DevOps toolchain, with none of them connected to the tools where decisions were made. So putting on a DevOps hat was the best compromise.\n\nTimes have changed for the better. DevOps and Agile have matured. We’ve established best practices, we know how and when to deviate from them, and we have an idea how we’d like to improve them. On the tool side, that means we’re ready to ditch those toolchains for a platform.\n\nGitLab was the first [DevOps platform](/solutions/devops-platform/) — designed as a single application from the beginning — but platform evolution is nothing new. Salesforce combines what used to be a disparate toolchain with massive integration overhead into a CRM platform that anyone, in any role, can use to boost productivity. Recently, the industry seems to have started to endorse the trend toward DevOps platforms. Last year, Gartner identified a new market in its [2020 Market Guide for Value Stream Delivery Platforms](https://about.gitlab.com/analysts/gartner-vsdp21/), in which GitLab was a Representative Vendor. \n\n![Epic roadmap view in GitLab](https://about.gitlab.com/images/blogimages/epic_roadmap.png \"Status rollups in epic roadmaps are always up-to-date\")\n\nWe’re excited to see industry experts recognize that we’ve reached the next stage of evolution. But what does a DevOps platform mean for that portfolio manager, or a product owner, or anyone else focused on the “business” end of business? Quite a lot, actually. It means:\n\n* Accuracy: When the work happens inside the same system of the planning, there is no lost data at API chokepoints, no delayed outputs from batch processes, and no doubt that the status rollups for an epic are anything but up-to-date.\n* Visibility: When you need more than a roll-up of an initiative’s status, a DevOps platform lets you inform your planning by clicking through into any level of detail — down to actual code changes or security and performance scan results.\n* Efficiency: Contextual drilldowns mean never again having to sift through spreadsheets full of useless-to-you data just to find that one thing you need.\n* Actionability: “Reporting” is so 20th century. A DevOps platform lets you learn, plan, and execute in the same system, removing blockers, collaborating, and adjusting course without losing any context or time.\n* Delivery speed: Fewer resources spent maintaining integrations means more developers and ops personnel focused on actually delivering value to your users.\n\nDon’t just take our word for it: look at customers like [British Geological Survey](/customers/bgs/), which uses GitLab to collaborate across roles.\n\n> *“GitLab has become our central place to store code and issues. It's become a mission critical system for our organization.”*\n>\n> **Wayne Shelley**, DevOps integration leader, BGS\n\nIndustry experts are responding to our approach. In its [2021 Magic Quadrant for Enterprise Agile Planning Tools](https://learn.gitlab.com/2021-mq-eapt), Gartner named GitLab a Leader for the first time. We’re proud of the recognition, but we’re even more excited to continue to build on our unique take on Agile planning in the future — and you’re a part of that future. Please read our planning [vision](https://about.gitlab.com/direction/plan/#our-vision-of-a-loveable-solution) and contribute!\n\n_Gartner, Magic Quadrant for Enterprise Agile Planning Tools, Bill Blosen, Mike West, Deacon D.K Wan, Akis Sklavounakis, Keith Mann, Wan Fui Chan, Hassan Ennaciri, 20 April 2021_\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\nCover image by [Alvaro Reyes](https://unsplash.com/@alvarordesign) [](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)on [Unsplash](https://unsplash.com/photos/qWwpHwip31M)\n\n## Read more about the DevOps Platform:\n\n- [The journey to a DevOps Platform](/blog/the-journey-to-a-devops-platform/)\n\n- [How ten steps over ten years led to the DevOps Platform](/blog/how-ten-steps-over-ten-years-led-to-the-devops-platform/)\n\n- [Making the case for a DevOps platform: What data and customers say](/blog/making-the-case-for-a-devops-platform-what-data-and-customers-say/)\n\n- [Welcome to the DevOps Platform era](/blog/welcome-to-the-devops-platform-era/)\n\n- [It's time to build more accessible software. A DevOps platform can help](/blog/how-the-devops-platform-makes-building-accessible-software-easier/)\n","agile-planning",[891,9,695],{"slug":1034,"featured":6,"template":698},"agile-planning-with-a-devops-platform","content:en-us:blog:agile-planning-with-a-devops-platform.yml","Agile Planning With A Devops Platform","en-us/blog/agile-planning-with-a-devops-platform.yml","en-us/blog/agile-planning-with-a-devops-platform",{"_path":1040,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1041,"content":1047,"config":1056,"_id":1058,"_type":13,"title":1059,"_source":15,"_file":1060,"_stem":1061,"_extension":18},"/en-us/blog/align-engineering-security-appsec-tests-in-ci",{"title":1042,"description":1043,"ogTitle":1042,"ogDescription":1043,"noIndex":6,"ogImage":1044,"ogUrl":1045,"ogSiteName":685,"ogType":686,"canonicalUrls":1045,"schema":1046},"How Developer-Centric AppSec Testing Transforms DevOps Teams","Find and fix security bugs faster by implementing developer-centric application security testing in the CI pipeline. And the bonus? Engineering and security will finally be better aligned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681513/Blog/Hero%20Images/stackhawk.jpg","https://about.gitlab.com/blog/align-engineering-security-appsec-tests-in-ci","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How developer-centric AppSec testing can dramatically change your DevOps team\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Joni Klippert\"}],\n \"datePublished\": \"2020-08-21\",\n }",{"title":1048,"description":1043,"authors":1049,"heroImage":1044,"date":1051,"body":1052,"category":1053,"tags":1054},"How developer-centric AppSec testing can dramatically change your DevOps team",[1050],"Joni Klippert","2020-08-21","\n\nSoftware development has accelerated dramatically over the past decade. As [DevOps](/topics/devops/) became pervasive, companies went from shipping software monthly to shipping software to production frequently throughout the day. This happened as engineering teams took ownership of the deployment, performance, and resilience of their software. \n\nAnd it has paid off. Companies that have adopted DevOps are deploying software significantly faster, ultimately driving business value as innovation is more rapidly delivered to customers.\n\nSecurity, however, did not keep up. Security teams typically fell into one of two positions - the blocker of frequent deployments or the team perpetually bringing up issues in last month’s work. The need for a shift in the security model is widely known. It was the subject of the [2019 Black Hat Conference keynote](https://www.blackhat.com/us-19/briefings/schedule/index.html#every-security-team-is-a-software-team-now-17280), stats from GitLab’s [2020 Global DevSecOps Survey](https://about.gitlab.com/resources/downloads/2020-devsecops-report.pdf) make this obvious, and we’ve [shared our opinions](https://www.stackhawk.com/blog/application-security-is-broken/) at StackHawk.\n\nI believe there is a solution (or at least a *huge* step in the right direction)... developer-centric [application security](/topics/devsecops/) tooling in the CI pipeline.\n\n## The CI pipeline aligns engineering and security\n\nWhile some in the industry have been debating the term DevSecOps, leading companies have started adopting developer-first security tooling that brings alignment through the CI pipeline. Instrumented correctly, it ensures that security bugs are caught before they hit production and that the fix cycle is drastically shortened.\n\nThe legacy model has security teams running application security tests against production environments. These sort of checks are great if they are your backstop. But if this is the primary way of assessing your application’s security posture, you need to catch up with modern engineering practices. \n\nModern teams are running checks on each microservice that makes up the customer facing application, catching bugs in pipeline, and equipping developers with the information to self serve fixes and triage issues. Fix times are significantly shorter, as developers are still in the context of the code they were working on. By testing microservices vs. the end state application, the underlying bugs are much easier to find and fix. And with developer-centric tooling, developers can fix bugs themselves instead of cycling through siloed internal processes. This structure better aligns each function with their best skill sets. Engineers know the application the best and are most equipped to fix, and security teams are able to focus on strategy instead of Jira ticket creation.\n\nThe key is to get the instrumentation right (read: don’t break the build for stupid stuff).\n\n## Application security tests in CI\n\nThat sounds great in theory, but what does it look like in practice? Getting started is actually more simple than it seems. We suggest adding three application security tests to start:\n\n## Software composition analysis (SCA)\n\nSCA identifies the open source dependencies in your code base and compares that against a database of known security vulnerabilities. Some tools automatically create pull requests to patch outdated libraries. Open source use is exponentially growing, especially with chained dependencies. SCA is incredibly important, but also can be noisy with non-exploitable findings.\n\nSome of the leading vendors in the space are [GitLab](/) and [Snyk](https://snyk.io/), with up and comers like [FOSSA](https://fossa.com/) also worth paying attention to.\n\n## Dynamic application security testing (DAST)\n\nDAST runs security tests against your running application, from localhost to CI to production. The beauty of DAST is that it most closely resembles what an attacker would see, by attacking your running application and reducing false positives. The two things to be sure of as you start testing with DAST is that your scanner is finding all of your paths and API endpoints and that it is able to scan as an authenticated user.\n\nGitLab provides DAST checks for Ultimate tier customers. If you want more robust scanning options and additional functionality to manage and fix bugs, [StackHawk](https://www.stackhawk.com) is the only place to turn (obviously I’m biased here). Other solutions include legacy vendors such as [Rapid7](https://www.rapid7.com/) or open source leader [ZAP](https://www.zaproxy.org/).\n\n## Secrets detection\n\nFinally, you’ll want to ensure that you have detection for leaked secrets in code. This tooling looks for credentials, keys, or other secrets that may have unintentionally been committed to the code base by developers. GitLab includes [secret detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) in their GitLab Ultimate security tooling.\n\n## Getting started\n\nOftentimes, the thought of adding application security tests to the development workflow feels insurmountable. With a long list of priorities, engineering leadership will sometimes put this off. The reality, however, is that it is not that hard.\n\nAt StackHawk, we see many customers completing their first successful scans within 15 minutes of sign up and instrumentation in CI is literally as easy as adding [a few lines of YAML](https://docs.stackhawk.com/continuous-integration/) to your build.\n\nHere is our recommended playbook of how to get started with AppSec in CI. While this is specific to StackHawk, the principles can be applied to other tools as well.\n\n### Step 1: local testing and config\nAfter signing up and grabbing your API key, start iterating on [configuration](https://docs.stackhawk.com/hawkscan/configuration/) while testing against your application on localhost. This allows you to quickly adjust config and get successful authenticated scans running.\n\n### Step 2: non-blocking CI instrumentation\nAfter you’ve ironed out the configuration locally, add the test to your CI pipeline. At this point, it is strongly recommended to instrument as a non-blocking test so that you can triage any existing findings and smooth out any kinks.\n\n#### Step 3: bug triage - fix critical issues in flight, backlog and discuss the rest\nAfter your first non-blocking CI run, start triaging any initial findings. Any bugs marked as High criticality should likely be fixed with some sense of urgency. Lows and Mediums should be triaged depending on your application and the bugs, either quickly addressed or added to a backlog for review. Existing findings should not be the blocker for you instrumenting checks to ensure that new bugs don’t get shipped to production.\n\n#### Step 4: switch to blocking tests\nAfter ironing out config locally and in CI, and then triaging initial findings, it is time to finalize the roll out. Switch the StackHawk test to blocking mode to ensure that new security bugs don’t hit production. You can set the scanner to break on High or Medium and High, which depends on your business and the nature of the application. With this in place, you can be confident that production-ready applications have been scanned for security.\n\n## Cultural shifts: it is more than CI\nThe CI pipeline is the natural hingepoint to start aligning engineering and security. A cultural shift, however, is absolutely needed. (If you're doubtful about this, here's a frank look at why [dev and sec don't get along](/blog/developer-security-divide/).) Modern engineering teams recognize that delivering a secure application is part of quality engineering. Engineers aren’t comfortable shipping applications with UI bugs, and they shouldn’t accept security holes either. \n\nSecurity, on the other hand, needs to shift from the blocker to speedy development and to the enabler of safety in an environment of high speed delivery. Modern security engineers are ensuring that their teams are working with safe-by-default frameworks, are equipped with developer-centric tooling, and that there are proper integration tests for business logic that can’t be tested by external tooling.\n\nWhile there is significant catch up needed, it is encouraging to see the leading software teams out there testing application security on every build.\n\n## Dig deeper\n\nTo learn more about adding AppSec tests to your CI build, join me at my [How Security Belongs in DevOps](https://sched.co/dUWD) talk at GitLab Commit on August 26th. You can also always sign up for a [free StackHawk trial or demo](https://www.stackhawk.com) or talk to your GitLab sales representative about the security features in GitLab Ultimate. And for the best of both worlds, check out more details on running [automated security testing with StackHawk in GitLab](https://docs.stackhawk.com/continuous-integration/gitlab.html).\n\n_Joni Klippert is founder & CEO of StackHawk, a software-as-a-service company built to help developers find and fix security vulnerabilities in their code. Joni has been building software for developers for more than 10 years, previously serving as VP Product, VictorOps from seed stage to acquisition by Splunk. Joni is a Colorado native and holds an MBA from the University of Colorado. She currently lives in Denver with her fiance Jason and Whippet \"Q\"._\n\nCover image by [Adi Goldstein](https://unsplash.com/@adigold1) on [Unsplash](https://unsplash.com)\n{: .note}\n\n\n\n","engineering",[108,9,695,807,1055,912],"testing",{"slug":1057,"featured":6,"template":698},"align-engineering-security-appsec-tests-in-ci","content:en-us:blog:align-engineering-security-appsec-tests-in-ci.yml","Align Engineering Security Appsec Tests In Ci","en-us/blog/align-engineering-security-appsec-tests-in-ci.yml","en-us/blog/align-engineering-security-appsec-tests-in-ci",{"_path":1063,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1064,"content":1070,"config":1075,"_id":1077,"_type":13,"title":1078,"_source":15,"_file":1079,"_stem":1080,"_extension":18},"/en-us/blog/an-ode-to-stable-counterparts",{"title":1065,"description":1066,"ogTitle":1065,"ogDescription":1066,"noIndex":6,"ogImage":1067,"ogUrl":1068,"ogSiteName":685,"ogType":686,"canonicalUrls":1068,"schema":1069},"An ode to stable counterparts","Our workflow model streamlines decision making, cultivates trust, and promotes cross-functional collaboration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679002/Blog/Hero%20Images/stablecounterparts.jpg","https://about.gitlab.com/blog/an-ode-to-stable-counterparts","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"An ode to stable counterparts\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2018-10-16\",\n }",{"title":1065,"description":1066,"authors":1071,"heroImage":1067,"date":1072,"body":1073,"category":693,"tags":1074},[951],"2018-10-16","\n_They said [this model](/handbook/leadership/#stable-counterparts) would help us thrive._\n_To foster trust, familiarity, and drive,_\u003Cbr/>\n_We would work side-by-side, knitting our workflows_\u003Cbr/>\n_And supporting one another in our highs and lows._\u003Cbr/>\n\n_Before we embarked on our journey, I fretted and fussed._\u003Cbr/>\n_With a furrowed brow, I felt a careful trust_\u003Cbr/>\n_In my leadership who often discussed_\u003Cbr/>\n_The need to readjust lest we combust._\u003Cbr/>\n\n_We shipped and scaled and detailed_\u003Cbr/>\n_Our results._\u003Cbr/>\n_Seamlessly soaring towards Two and Twenty,_\u003Cbr/>\n_Our managers said, “In their progress, that_\u003Cbr/>\n_team exults.”_\u003Cbr/>\n_We collaborate, update, and accelerate with flair._\u003Cbr/>\n\n_And now I must declare:_\u003Cbr/>\n_I have drawn the ace of hearts_\u003Cbr/>\n_With my team of stable counterparts!_\u003Cbr/>\n\nAt GitLab, we adopted a stable counterparts model to facilitate cross-functional\nconnections in the hope that working with the same people would increase the\nspeed of communication, build trust, and encourage iteration. In a stable\ncounterparts model, every team works with the\n[same team members](/handbook/engineering/development/dev/create/source-code-be/#stable-counterparts),\nincluding frontend engineers, UX designers, and test automation engineers, for\neach release, creating a smaller team within GitLab.\n\n## The benefits of stable counterparts\n\nThe ability to build long-term relationships is the foundational benefit of\nhaving stable counterparts. Repeated interactions helps us understand personal\nworkflows and communication styles, so we know how to most effectively work with\nour counterparts. Knowing how to best communicate with someone is a great benefit\nwhen working in high pressure situations or resolving conflict. Consistent\ncollaboration means faster results and more efficient processes.\n\nIn addition to building long-term relationships, we’ve noticed a few other\ninteresting benefits to having stable counterparts.\n\n- **Enabling a faster workflow**: There are some product areas that are easy to\nunderstand because every team member engages with them, but there are some that\nare challenging, such as [CI](https://docs.gitlab.com/ee/ci/),\n[security](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports),\nor [Kubernetes](https://docs.gitlab.com/ee/user/project/clusters/index.html),\nthat require domain knowledge that can be harder for a team member to quickly\nfathom without a certain amount of pre-knowledge. When a stable counterpart has\ndeveloped deeper understanding in complex areas, others know who to quickly\nconsult when confronted with a specific technical challenge, an insight that\ndrives velocity since team members are no longer blocked trying to determine who\ncan offer assistance.\n- **Promoting long-term brainstorming**: In traditional workflow models, product\nmanagers often have individual meetings with engineering managers, UX designers,\nand frontend managers in which brainstorming through ideas and talking about\nlong-term goals happens in silos. With stable counterparts, discussion benefits\nfrom cross-functional perspective, enhancing ideas, and igniting creativity,\nwhich can take place over several milestones.\n- **Increasing familiarity and comfort with problems**: Working with a rotating\nset of team members can result in a lack of comprehensive historical knowledge\non an issue, causing delays while team members digest information and become\nacquainted with the state of a solution. By working with the same people over\nseveral releases, we’re able to provide context early and implement learnings\nto solve problems in the right way.\n\n## Let’s talk about workflow impact\n\nWorking with stable counterparts has helped the team develop a faster and more\niterative workflow. We’re more focused in that we can pick up on discussions and\nitems that we tinkered with in previous releases. We now approach problems with\na deeper understanding, since we have long-term insight into why changes are\nimportant. Taking context from release to release and retaining that knowledge\nensures that we develop thoughtful solutions, especially since we feel a higher\nsense of ownership of projects because we’ve been involved throughout every stage.\n\nThis model has also resulted in better dependency management. We spend a lot of\ntime doing upfront investment into project planning and prioritization, so teams\nhave visibility into collaboration with backend and frontend. This makes it\neasier to see whether we need more backend or frontend resources in certain areas\nand to allocate engineers as needed.\n\n## Sounds great, but what are the drawbacks?\n\nThis model could lead to engineers feeling like they’re feature factories, so\nleadership must actively work to keep their team on an edge so that there’s a\nhealthy balance between product features and other tasks that are more complex\nor exciting.\n\nWhen working with stable counterparts, there’s a potential for conflict and\npersonality issues. If personal communication styles or workflows don’t align,\ninteractions can become tense and handoffs can be fraught with friction. When\npairing stable counterparts, leadership should consider personalities,\ncommunication styles, and workflows to ensure that a team, at baseline, can work\nwell together.\n\nWorking with the same people for too long means that we’re not exposed to a\nbroader audience and may not have fresh ideas come into conversations. It’s\npossible that teams become comfortable with the way things are and ideas are no\nlonger questioned. We haven’t encountered this problem at GitLab yet, since we’re\n[growing](/jobs/) so quickly that every team frequently has a change or new addition,\nwhich is accompanied by a variety of new questions and unique feedback. For\nteams that don’t have as much growth, it can be useful to invite other team\nmembers to provide perspective and question long-held beliefs.\n\n## Advice for other teams\n\nIf your team is interested in adopting a similar model, we suggest starting\nsmall and breaking teams into smaller components. For teams that are unaccustomed\nto an interdisciplinary model with agile teams, it can be a difficult adjustment,\nso it’s important that teams are structured around either a specific initiative\nor area of the product. To determine whether this is a model that could benefit\nyour organization, consider selecting a problem and pairing the same 4-5 team\nmembers, including a product manager, a UX designer, and a few engineers, for\nseveral releases until the problem is solved. Working together for several\nreleases helps team members nurture a strong, stable relationship, so it’s\nimportant that they’re given enough time to learn about and from each other.\n\nAlthough stable counterparts has worked well for GitLab’s workflow, it’s\nimportant to be sure that this is the model that fits _your_ company’s needs.\nDeveloping a workflow depends on strategy, targets, and the maturity level of an\norganization. These are all variables that need to be considered when building\nor changing a process. This setup wouldn’t have worked for GitLab 12 months ago,\nbut it works now, so continue to experiment and examine options as your team and\norganization develop. Whether you pursue a stable counterparts model or some other\nsetup, remember to select an approach that complements your organization and the\nproduct you’re building.\n\n_The writer is grateful to [Jeremy Watson](/company/team/#d3arWatson),\n[Liam McAndrew](/company/team/#lmcandrew), [John Jeremiah](/company/team/#j_jeremiah), and\n[Tim Zallman](/company/team/#tpmtim) for sharing their experiences as stable counterparts._\n",[912,934,9],{"slug":1076,"featured":6,"template":698},"an-ode-to-stable-counterparts","content:en-us:blog:an-ode-to-stable-counterparts.yml","An Ode To Stable Counterparts","en-us/blog/an-ode-to-stable-counterparts.yml","en-us/blog/an-ode-to-stable-counterparts",{"_path":1082,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1083,"content":1089,"config":1100,"_id":1102,"_type":13,"title":1103,"_source":15,"_file":1104,"_stem":1105,"_extension":18},"/en-us/blog/async-sketching",{"title":1084,"description":1085,"ogTitle":1084,"ogDescription":1085,"noIndex":6,"ogImage":1086,"ogUrl":1087,"ogSiteName":685,"ogType":686,"canonicalUrls":1087,"schema":1088},"Running an Asynchronous Sketch Workshop for UX","How to generate ideas with team members in multiple time zones","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669734/Blog/Hero%20Images/sketch-cover.jpg","https://about.gitlab.com/blog/async-sketching","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Running an Asynchronous Sketch Workshop for UX\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jacki Bauer\"},{\"@type\":\"Person\",\"name\":\"Inchul Yoo, Sunjung Park\"}],\n \"datePublished\": \"2020-03-27\",\n }",{"title":1084,"description":1085,"authors":1090,"heroImage":1086,"date":1093,"body":1094,"category":716,"tags":1095},[1091,1092],"Jacki Bauer","Inchul Yoo, Sunjung Park","2020-03-27","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nMany companies that normally work together in person have been suddenly thrust into an all-remote world. That can be scary for anyone, but especially for UX designers who rely heavily on face-to-face collaboration with their cross-functional peers.\n\nIf you’re in this situation, you may be thinking: How can I ideate without a whiteboard? How do I lead my team through sketching exercises without paper? WHAT DO I DO WITH ALL OF MY SHARPIES AND STICKY NOTES?!\n\nAt GitLab, our entire company is all remote and globally distributed. We’re used to finding ways to sketch, think and brainstorm asynchronously, so we can accommodate team members who live in time zones all over the world.\n\nYou need just a few ingredients.\n## Clear, simple guidelines and instructions\nGuidelines are really important in any design thinking activity, but when you’re asynchronous, they become extra important, because participants can’t ask clarifying questions or observe what others are doing. So it’s the designer’s role to communicate the activity’s purpose and goal, along with clear instructions and a sense of psychological safety. \n\nAnd just like with in-person activities, you also might want to provide timing advice. For example, consider how you want an individual's ideas to influence others. You might want to give everyone a day to ideate and then ask everyone to drop in their ideas at the same time, so they don’t inadvertently influence each other. Or, you might ask people to intentionally play off the ideas of others. It’s ultimately up your judgement about the goals of the session.\n\n\n## Shared understanding of context\nThe team should already understand some basics about the product or context they work in and the audience they are designing for. If you’re working with a newly formed team, you might try a couple synchronous workshops to get everyone on the same page.\n\n\n## A place for everyone to contribute their ideas\nThis one is easy. There are a lot of tools you can use, including Mural, Google Drive, or even \nSlack. At GitLab, we use Mural, and we also work within our own product to run collaborative design sessions. \n\nAll you need is a place where team members can quickly and easily add text, photos of sketches, images, or even videos, and then freely discuss them. To encourage creativity, you’ll likely want to pick a tool that offers flexibility. \u2028\u2028\u2028\n\n![Illustration of a sketch and chat windows](https://about.gitlab.com/images/blogimages/sketching-session.jpg){: .shadow.medium.center}\n\n## Facilitate team communication\nWhen a team meets in person, they get a lot of non-verbal feedback that can be really useful. People might smile at each other, nod when they hear a good idea, or sigh when someone suggests something that won’t work.\n\nIt’s important to offer a way to surface these reactions when you can’t use immediate nonverbal communication. As the team shares their ideas, provide supportive comments (that will encourage others to do the same). You might also use emojis to enhance communication.\n\n## Step just a little outside your comfort zone\nThis last one is important in any kind of design thinking environment. If you’re a designer working with a product or a client team, it’s likely that many (or most) of the participants in your sessions are not designers. Some participants might hate drawing, and some might be terrified of the idea of uploading something they drew to the internet. \n\nThis is where it helps to work with a team that has already established some rapport. As the designer and session leader, it’s also your job to set a relaxed and casual tone and a low bar for participation. \n\nAt GitLab we say “Everyone can contribute,” and we value action and results over perfection. Let people know it’s OK to not be perfect. As an example, this is how one designer at GitLab set the rules for her team sketching session:\n\n**Rules for the game**\n* This is a 10-minute activity in total. You don't have to spend more than 5 minutes for each round.\n* Let's not think about layouts such as the top-header, GitLab logo, and left menu.\n* There are no right or wrong answers.\n* It doesn't have to be beautiful. (You will be surprised to see how ugly mine is.)\n* For round 2, you don't need to fill in all the blanks if it is hard for you. It's not an exam. :-)\n\nTo see this method in action, you can read through this [issue](https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4944) from February 2020. Believe it or not, this team was doing this exercise for the first time!\n\nCover image by [Mounzer Awad](https://unsplash.com/@mounzaw_) on [Unsplash](https://unsplash.com/s/photos/sketching)\n{: .note}\n\n",[9,1096,1097,1098,1099],"design","remote work","UI","UX",{"slug":1101,"featured":6,"template":698},"async-sketching","content:en-us:blog:async-sketching.yml","Async Sketching","en-us/blog/async-sketching.yml","en-us/blog/async-sketching",{"_path":1107,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1108,"content":1114,"config":1120,"_id":1122,"_type":13,"title":1123,"_source":15,"_file":1124,"_stem":1125,"_extension":18},"/en-us/blog/athlinks-cuts-runtime-in-half-with-giltab",{"title":1109,"description":1110,"ogTitle":1109,"ogDescription":1110,"noIndex":6,"ogImage":1111,"ogUrl":1112,"ogSiteName":685,"ogType":686,"canonicalUrls":1112,"schema":1113},"Athlinks cuts runtime in half with GitLab","Athlinks, a time management solution platform, shares how moving from Jenkins to GitLab cut CI runtimes in half.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671909/Blog/Hero%20Images/Athlinks_running.jpg","https://about.gitlab.com/blog/athlinks-cuts-runtime-in-half-with-giltab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Athlinks cuts runtime in half with GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n \"datePublished\": \"2019-12-17\",\n }",{"title":1109,"description":1110,"authors":1115,"heroImage":1111,"date":1117,"body":1118,"category":784,"tags":1119},[1116],"Brein Matturro","2019-12-17","\nIf you’ve ever run a [Spartan race](https://www.spartan.com/en), then you’ve likely used Athlinks, the only suite of time management solutions for a variety of racing events. The [Athlinks](https://www.athlinks.com) platform includes race registration, timing, scoring, results -- everything from the check-in process to the orange wrist bands worn by participants. The solution stores over 300 million race results at any given time.\n\n## Athlinks previous DevOps tools run short\n\nThe Athlinks DevOps team previously had experience with several Agile planning tools, including Jira, Rally, and VersionOne. All of the tools they tried didn’t exactly fit what the team needed. They were looking for a tool that offers transparency and a voice for other parts of the business. “(We wanted) to give transparency and a voice to what engineering is working on so that other departments can have input into what is going on,” says Christopher Annannie, engineering manager, Athlinks.\n\n## Athlinks sprint to GitLab CI from Jenkins\n\nAthlinks started using GitLab CE in 2015, migrating over from GitHub. In January of 2018, the team adopted EE and after doing a GitLab CI proof of concept, they moved to Ultimate and away from [Jenkins](/blog/migrating-from-jenkins/). “We quickly discovered that we really wanted the full suite of tools for the Agile and the product side, so we went to GitLab Ultimate,” explains Aaron Rorvig, DevOps manager.\n\nThe group previously had about 300 jobs in Jenkins and now are at less than 40. “We use a wide variety of languages and technologies -- pretty much every operating system, both Android and iOS. We’re all over the place and we use GitLab CI for all of it,” Aaron says. The Athlinks team estimates a 50% savings across the board, both in code and in time spent running jobs.\n\n## A win for Athlinks collaboration and communication\n\nSince all of the issues, the code, and [CI pipelines](/blog/defend-cicd-security/) are inside of GitLab, it provides a single view from start to finish. Each team can view all the issues and the labeling helps everyone understand what stage each project is in, how much work has been done, and what the next steps are. “GitLab is not necessarily all that opinionated about how you do issue tracking,” Christopher says. Everything can be tracked, even when the teams don’t use the same issue tracking, it can all exist in one place.\n\nThe issue templates provide structure for the all departments to understand what they need to fill out. “Engineering will get to it quicker without so much back and forth before a problem is actually solved,” Christopher says.\n\nThe communication among the marketing, DevOps and engineering teams is improving. “We’re getting marketing involved in this so we get better about communicating all the new features we’ve deployed this month, so that timers, race directors, and athletes will actually know about the work we’re doing,” Christopher says.\n\nWant to learn more about Athlink’s transition from Jenkins to GitLab? Watch the presentation here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/Dy_a79_PsNk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Ben Stern](https://unsplash.com/@benst287) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[108,9,891],{"slug":1121,"featured":6,"template":698},"athlinks-cuts-runtime-in-half-with-giltab","content:en-us:blog:athlinks-cuts-runtime-in-half-with-giltab.yml","Athlinks Cuts Runtime In Half With Giltab","en-us/blog/athlinks-cuts-runtime-in-half-with-giltab.yml","en-us/blog/athlinks-cuts-runtime-in-half-with-giltab",{"_path":1127,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1128,"content":1134,"config":1142,"_id":1144,"_type":13,"title":1145,"_source":15,"_file":1146,"_stem":1147,"_extension":18},"/en-us/blog/best-practices-customer-feature-request",{"title":1129,"description":1130,"ogTitle":1129,"ogDescription":1130,"noIndex":6,"ogImage":1131,"ogUrl":1132,"ogSiteName":685,"ogType":686,"canonicalUrls":1132,"schema":1133},"How to incorporate private customer needs into a public product roadmap","We've had lots of experience documenting and tracking private customer feature requests effectively. Here's our best advice and how to get the most out of GitLab issues and issue trackers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/best-practices-customer-feature-request","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to incorporate private customer needs into a public product roadmap\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"},{\"@type\":\"Person\",\"name\":\"Neil McCorrison\"}],\n \"datePublished\": \"2021-09-23\",\n }",{"title":1129,"description":1130,"authors":1135,"heroImage":1131,"date":1138,"body":1139,"category":1053,"tags":1140},[1136,1137],"Christina Hupy, Ph.D.","Neil McCorrison","2021-09-23","\n\nEffectively communicating a customer’s private needs to product teams is essential to a product’s success, but it can be a tricky undertaking.\n\nTeams can face several challenges in communicating and tracking customers' requests, including protecting customer confidentiality, tracking priority and progress, and making sure the product team is getting actionable feedback that can be incorporated into product milestones.\n\nThis blog post shares GitLab's best practices and lessons learned, as well as a video conversation between GitLab CEO [Sid Sijbrandij](/company/team/#sytses) and Fleet CEO [Mike McNeil](https://www.linkedin.com/in/mikermcneil/).\n\nIn line with GitLab's [open core model](/company/stewardship/) and [transparency value](https://handbook.gitlab.com/handbook/values/#transparency), our product roadmap is public and the product team uses [public issue trackers](/gitlab-com/Product/-/issues) for feature requests and to plan the work. Because the issues are public, customers and community members can see how the product team works, what direction we are headed, and what the priorities are. Contributors can even decide to create a feature themselves.\n\nEver wonder what a DevOps Platform could do for your team? [Here's what you need to know](/solutions/devops-platform/)\n\nWhen a customer indicates a feature request to a technical account manager (TAM), the manager searches for the relevant open feature request in the product teams' issue tracker and adds a comment with generic details about the customer such as number of users and product. If an issue for that feature request does not already exist, the technical account manager can create an issue with the [Feature Proposal](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Proposal%20-%20lean) issue template then and add the customer’s request as a comment.\n\nFor example, the comment should include the following:\n\n> Hello `@product-manager`, an Ultimate customer with 1500 users (`salesforce-link`) would like to see this feature prioritized, ideally within the next 6 months. They need this feature in order to X, which is important to them because Y, and they do not currently have a workaround. Additionally, releasing this feature would result in an estimated 250 additional users.\n\nThe TAM includes a link to the account in the customer relationship management system (CRM), in GitLab’s case Salesforce, so the internal teams can view the details. We even have a [feedback template](/handbook/product/how-to-engage/#feedback-template) to ensure the proper details are captured in the comment. The comment is public but the record in the CRM is private.\n\nThe product manager reviews the request and responds. Relevant [labels](/handbook/customer-success/csm/product/#priority-of-feature-requests) are added based on priority. For example, labels include **critical requests**, **high-priority requests**, **low priority requests** or **promised to a customer**. Milestones can be assigned to track timelines and make sure the feature ships on time. The feature tracking issue should be maintained regularly and acts as the single source of truth on the customer needs. These issues can also be reviewed for metrics on previously delivered feature requests.\n\n**Elevating your DevOps skills? Join us at [Commit at KubeCon - Oct. 11!](/events/commit/)**\n\nIn this case, a noisy feature request issue with comments from customers is a good thing. It helps the product manager directly see where the action is and how customers would benefit, and it also helps when prioritizing what feature ships next. Seeing direct input from the customers provides context and also creates developer empathy and connection with the end user. Additional team members, including [solution architects](https://handbook.gitlab.com/job-families/sales/solutions-architect/) find it useful to subscribe to these issues, keeping them automatically updated on progress and discussion by the product team.\n\n**Getting the product team involved early on is essential** to the success of this workflow. Another essential element is that the CSMs bring their customers'feedback directly to the issue where the work is being planned and prioritized.\n\n**Contributing to GitLab:** Once a product manager has triaged an issue and applied the appropriate [Product Development Workflow](/handbook/product-development-flow/) labels, it may be deemed that the feature is ready for the customer or community to help build the feature directly. Our motto is \"Everyone Can Contribute\", and the ~\"Accepting Merge Requests\" label ([handbook](/handbook/engineering/quality/triage-operations/#sts=Accepting%20merge%20requests)) is a great way to identify when a feature is ready for a community contribution. Customers who wish to contribute back to GitLab can ask for a [Merge Request Coach](https://handbook.gitlab.com/job-families/expert/merge-request-coach/) to help guide them through the process to ensure timely review and alignment with our engineering best practices.\n\nGitLab learned early on that creating a separate issue for customer feedback can get complicated and ends up being disjointed from where the product managers are doing their work.\n\nIn summary, best practices for delivering customer feature requests to the product team include:\n\n* Ensure the feedback is directly where the product managers are working and prioritizing features.\n* Provide only generic details on the customer with a link to internal confidential information, but provide as much detail as possible regarding the customer's use case and business need.\n* Share the feature request issue back with the customer. If they feel inclined, they can comment and add details. This builds trust between the customer, their account team, and the product team.\n* Labels and milestones are essential for tracking. If something is critical to the customer, make sure the labels and milestones indicate as such.\n* The feature request issue should act as the single source of truth for the customers' needs; aggregating this information elsewhere results in a disconnect between the need and the work.\n\nWatch the full discussion between Sid and Mike:\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/JH2cFhoUzsI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\nSid discussing GitLab's best practices on tracking customer feedback with Fleet CEO Mike McNeil\n{: .note}\n\n",[912,829,1141,9],"customers",{"slug":1143,"featured":6,"template":698},"best-practices-customer-feature-request","content:en-us:blog:best-practices-customer-feature-request.yml","Best Practices Customer Feature Request","en-us/blog/best-practices-customer-feature-request.yml","en-us/blog/best-practices-customer-feature-request",{"_path":1149,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1150,"content":1156,"config":1163,"_id":1165,"_type":13,"title":1166,"_source":15,"_file":1167,"_stem":1168,"_extension":18},"/en-us/blog/biggest-obstacles-to-getting-work-done",{"title":1151,"description":1152,"ogTitle":1151,"ogDescription":1152,"noIndex":6,"ogImage":1153,"ogUrl":1154,"ogSiteName":685,"ogType":686,"canonicalUrls":1154,"schema":1155},"Why deadlines get missed (and how to fix it)","These are the biggest obstacles preventing developers from getting work done – and how to tackle them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671344/Blog/Hero%20Images/obstacles-to-getting-work-done.jpg","https://about.gitlab.com/blog/biggest-obstacles-to-getting-work-done","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why deadlines get missed (and how to fix it)\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n \"datePublished\": \"2017-06-27\",\n }",{"title":1151,"description":1152,"authors":1157,"heroImage":1153,"date":1159,"body":1160,"category":693,"tags":1161},[1158],"Rebecca Dodd","2017-06-27","\nIt's not just unnecessary meetings or outdated tools – developers are more concerned with communication and culture issues preventing them from getting work over the finish line in time. So how do you combat this problem?\n\n\u003C!-- more -->\n\nIn the past, the software development process has followed a linear path, with teams doing their work and then handing off responsibility for a project to whoever takes on the next stage, giving little (if any!) thought to how others will manage when their turn comes. This creates a disconnect between the team making the decisions and the team executing them, which can lead to mismanaged expectations and delayed releases.\n\n## What are the biggest obstacles to getting work done?\n\nIn our [Global Developer Survey](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html), we asked developers what prevents them from meeting deadlines, and the responses were a combination of the obvious: unnecessary meetings (16.25 percent) and being forced to use inappropriate or outdated tools (6.16 percent); as well as more concerning, systemic issues, which point toward the breakdown in communication between developers and product owners.\n\nUnclear direction came in tops with over 47 percent and unrealistic deadlines followed with 21.29 percent. These issues also manifest in [code getting released too early](/blog/why-code-is-released-too-early/). So how do you combat this?\n\n## Introduce DevOps practices\n\n Adopting elements of the DevOps approach instead, and taking a more collaborative attitude towards setting deadlines and deciding on what will go into the next release means that all participants and stakeholders can weigh in on the decision and flag potential problems or delays.\n\n### Work on smaller releases\n\nWorking more [iteratively](https://handbook.gitlab.com/handbook/values/#iteration) helps to prevent bottlenecks as you approach a deadline, as you're trying to fit less into each release. Stripping a new feature or package down to its smallest components (the Minimum Viable Changes) helps to clarify what exactly you're working on and what the expectations are, so the way forward is clearer to everyone involved.\n\nTo find out more about iteration and Minimum Viable Changes, check out [How to Shorten the Conversation Cycle](/blog/how-to-shorten-conversation-cycle/).\n\n### Create cross-functional teams\n\nWhen teams interact throughout the development process, instead of just handing off to each other, you create a culture in which everyone feels responsible for the final outcome rather than just their portion of a project. From the early planning phases, through development, testing and review, involving the right stakeholders and experts at the right times results in better mutual understanding of different teams' unique motivations and pressures. This helps everyone to take these factors into account when deciding on deadlines or what to include in a release, so the direction is clear and the timeline realistic.\n\n### Encourage collaboration\n\nFor those cross-functional teams to be effective, collaboration is critical. If you've been working in siloed teams without much interaction, this can be a challenge to implement. But making everyone feel comfortable to share their ideas and contribute means you get more diverse perspectives on what you're working on and ensures that you take advantage of every team's expertise and factor in any limitations too. [Here are three ways we try to foster collaboration at GitLab](/blog/ways-to-encourage-collaboration/).\n\nDownload our [Global Developer Report](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) to learn more about what developers want and need to do their jobs more efficiently.\n{: .alert .alert-gitlab-orange}\n\nCover image: “[Brickwall](https://unsplash.com/collections/834185/obstacles?photo=9OEE8Ktcaac)” by [Namrod Gorguis](https://unsplash.com/@namroud)\n{: .note}\n",[1162,912,9],"webcast",{"slug":1164,"featured":6,"template":698},"biggest-obstacles-to-getting-work-done","content:en-us:blog:biggest-obstacles-to-getting-work-done.yml","Biggest Obstacles To Getting Work Done","en-us/blog/biggest-obstacles-to-getting-work-done.yml","en-us/blog/biggest-obstacles-to-getting-work-done",{"_path":1170,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1171,"content":1177,"config":1183,"_id":1185,"_type":13,"title":1186,"_source":15,"_file":1187,"_stem":1188,"_extension":18},"/en-us/blog/building-a-handbook-first-remote-learning-culture",{"title":1172,"description":1173,"ogTitle":1172,"ogDescription":1173,"noIndex":6,"ogImage":1174,"ogUrl":1175,"ogSiteName":685,"ogType":686,"canonicalUrls":1175,"schema":1176},"Building a Handbook First Remote Learning Culture","An overview on how to build a handbook first remote learning culture","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/building-a-handbook-first-remote-learning-culture","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Building a Handbook First Remote Learning Culture\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Josh Zimmerman\"}],\n \"datePublished\": \"2020-12-22\",\n }",{"title":1172,"description":1173,"authors":1178,"heroImage":1174,"date":1180,"body":1181,"category":716,"tags":1182},[1179],"Josh Zimmerman","2020-12-22","\n{::options parse_block_html=\"true\" /}\n\nLearning & Development (L&D) is a vital function of any organization’s People or HR team. When most professionals think of L&D, they may remember sitting in the back of a conference room hearing a corporate trainer deliver slides, or maybe accessing self-paced training once or twice a year, or perhaps taking a survey on how to grow their skills. At GitLab, L&D is a huge priority and we do it differently than most organizations!\n\nSince GitLab is [all-remote](https://about.gitlab.com/company/culture/all-remote/) and our [Handbook](https://handbook.gitlab.com/handbook/) is our primary source of learning, you may be asking yourself, how does L&D create and reinforce a remote learning culture?\n\n[GitLab’s Handbook](https://handbook.gitlab.com/handbook/) is over 8,000 pages long, and it grows every day. We consider each page to be a source of learning & development material. Pages are for training new team members on GitLab processes, culture, ways of working, and much more. The Handbook is publicly available worldwide, and anyone can [learn about GitLab's Remote working culture](/company/culture/all-remote/building-culture/) and [DevOps](/topics/devops/). It’s a ton to digest, and from a learning perspective, the text-based format can lean heavily on reading and video. For GitLab to scale L&D, we need to make our Handbook more consumable where it is easy to learn new things!\n\nI joined GitLab eight months ago from management consulting to help build a learning culture. It’s an exciting opportunity. Our team is growing fast. We deliver more resources to the community, and we are helping team members learn more by introducing new handbook first learning modalities. I wanted to share my thoughts on some of the biggest takeaways on building a handbook first remote learning culture. Consider these ingredients to scaling L&D:\n\n## Build a Learning Infrastructure\n\nGitLab’s Handbook is our primary source of training material. Every piece of content pulls from the handbook. As GitLab continues to grow, we needed to invest in a learning technology infrastructure that can enable personalized/self-service learning. By taking material in the handbook, we can apply a [level of interactivity](https://about.gitlab.com/handbook/people-group/learning-and-development/interactive-learning/) to allow various learning styles to consume bite-sized content. We recently invested in a [Learning Experience Platform (LXP)](https://about.gitlab.com/handbook/people-group/learning-and-development/#gitlab-learn-edcast-learning-experience-platform-lxp) by [EdCast](https://gitlab.edcast.com/log_in?auto_sso=true) that will significantly improve our ability to provide certifications, assessments, and self-service learning.\n\nWe also invested in a content library from LinkedIn Learning for off-the-shelf content. Team members will have access to the library for courses that can supplement GitLab’s customized learning content. There's also our use of Articulate 360, which we use to [build interactive handbook first courses](https://about.gitlab.com/handbook/people-group/learning-and-development/interactive-learning/) in the LXP.\n\nThe L&D team has pursued various certification programs that complement our values, such as [Tracom Corporations Social Styles](https://tracom.com/social-style-training/model) facilitator and [Crucial Conversations certification from VitalSmarts](https://www.vitalsmarts.com/crucial-conversations-training/). Our plan is to equip the L&D team with as many tools to design and deliver scalable training. By continuing to invest in learning technologies, we want our team members to know that growing your skills is a top priority for the future of GitLab.\n\n## Design Social Learning Experiences\n\nRemote work can have [some drawbacks](https://about.gitlab.com/company/culture/all-remote/drawbacks/). One of those challenges may be a lack of connection with your coworkers. GitLab L&D uses our live learning courses as an opportunity to build relationships and a sense of community with team members. There may not be a lot of forums outside of [coffee chats](https://about.gitlab.com/company/culture/all-remote/informal-communication/#coffee-chats), [AMAs](https://handbook.gitlab.com/handbook/communication/ask-me-anything/), [group conversations](https://about.gitlab.com/handbook/group-conversations/), or [1-1 meetings](https://about.gitlab.com/handbook/leadership/1-1/) where team members can **Learn From Others**. We have started to adapt our [live learnings](https://about.gitlab.com/handbook/people-group/learning-and-development/#live-learning) to serve as networking activities where team members work on scenarios in small groups, get to know one another, and share lessons learned. We’ve noticed increased engagement across learners and an atmosphere of encouraging collaboration. Social Learning is the cornerstone of how we will design learning experiences. We can’t expect participants to pay attention to slides for 25 to 50-minute sessions, so we decided to throw out most of them! Team members want to network and build connections during sessions. Why not use learning as a forum to do just that?\n\n## Prioritize Leadership Buy-In and Sponsorship.\n\nGitLab’s CEO, Sid, is very passionate about L&D. He wants to be part of our learning initiatives and share knowledge from his experience growing the organization. Sid has partnered with L&D on recording interviews and [advocating for up-leveling our handbook first learning content](https://about.gitlab.com/handbook/people-group/learning-and-development/#handbook-first-training-content). In order to scale, we receive executive support from Sid and the rest of the e-group on essential initiatives. Our leadership is behind us. Without their support for learning, it would be difficult for L&D to grow and show our people we are invested in them.\n\n## Change Management for Learning & Development\n\nAsking team members to [take time out to learn new skills](https://handbook.gitlab.com/handbook/organizational-change-management/) takes time and energy. Everyone at GitLab is incredibly busy, and carving out time to reskill, and upskill requires a proactive approach. We use GitLab communication vehicles such as Slack channels and Issues to spread various [learning initiatives](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/). With the introduction of new tools, technology, initiatives, and courses, L&D has to conduct [continuous change management](https://handbook.gitlab.com/handbook/organizational-change-management/#introduction) with a heavy focus on communications and enablement. Some of those methods include a [monthly continuous learning call](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#monthly-continuous-learning-call-overview) and quarterly newsletter, where we highlight what’s happening in the L&D space.\n\n## Focus on Developing your Leaders\n\nOne of my first initiatives at GitLab was developing a [manager enablement program](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/). The program’s focus is to reinforce behaviors through a set period of time, 3 weeks, to train our leaders on remote management practices. We applied neuroscience techniques so that participants can learn at their own pace through positive engagement and social learning. We also recognized that learners might have various attention span ranges, so why not create a program that allows participants to complete activities through [daily challenges](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/#week-1) that take 20 minutes to complete. The program is bite-sized, blended for different learning styles, flexible, and engaging with the focus on equipping managers with critical skills.\n\nBy focusing on managers as a key priority for L&D, we were able to pilot a program and iterate on future deliveries rapidly. We now have a group of managers who are learning ambassadors that can advocate for learning initiatives in the future.\n\n## Reinforce GitLab Values\n\n[C.R.E.D.I.T.](https://handbook.gitlab.com/handbook/values/#credit) is the acronym GitLab uses for our six values. One way for us to reinforce our values is by threading them throughout our curriculum design and development. The values serve as the cornerstone to how GitLab operates as a Remote organization. I’m lucky to work for an organization that takes them so seriously, and it makes my job as an L&D professional easier. By rooting learning in our values, we can reinforce behaviors.\n\n## Prove L&D is a high-value organization\n\nL&D is a relatively new organization within GitLab. Our team considers ourselves strategic enablers. We are striving to develop a mindset that feels responsible for driving strategy and leading change. Think bigger and broader by being proactive in understanding GitLab’s goals, methods, and operations. We have a goal to align every aspect of L&D with the rest of the company. By piloting and [iterating new initiatives](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/), we let the organization know that we are here to enable behavioral change that directly increases results!\n\nWe have a colossal charter set out for us in L&D. But with the strong encouragement from our leadership, we know that building a handbook first remote learning culture is top of mind. Hopefully, some of the points outlined in this blog will equip you with a few tips on building a learning culture within your organization.\n\nTo learn more, check out our handbook page, [GitLab Learning and Development](https://about.gitlab.com/handbook/people-group/learning-and-development/), or contact learning@gitlab.com to speak with a member of our team.\n",[9,934,1097,268],{"slug":1184,"featured":6,"template":698},"building-a-handbook-first-remote-learning-culture","content:en-us:blog:building-a-handbook-first-remote-learning-culture.yml","Building A Handbook First Remote Learning Culture","en-us/blog/building-a-handbook-first-remote-learning-culture.yml","en-us/blog/building-a-handbook-first-remote-learning-culture",{"_path":1190,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1191,"content":1197,"config":1204,"_id":1206,"_type":13,"title":1207,"_source":15,"_file":1208,"_stem":1209,"_extension":18},"/en-us/blog/building-an-award-winning-culture-at-gitlab",{"title":1192,"description":1193,"ogTitle":1192,"ogDescription":1193,"noIndex":6,"ogImage":1194,"ogUrl":1195,"ogSiteName":685,"ogType":686,"canonicalUrls":1195,"schema":1196},"How we're building an award-winning culture at GitLab","We're proud to see GitLab recognized as one of Inc. Magazine's Best Workplaces in 2019!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670139/Blog/Hero%20Images/gitlab-contribute-team-photo.png","https://about.gitlab.com/blog/building-an-award-winning-culture-at-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we're building an award-winning culture at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Betsy Church\"}],\n \"datePublished\": \"2019-05-16\",\n }",{"title":1192,"description":1193,"authors":1198,"heroImage":1194,"date":1200,"body":1201,"category":300,"tags":1202},[1199],"Betsy Church","2019-05-16","\n\nWe’re delighted to share that GitLab has been named one of [Inc. Magazine’s Best Workplaces in 2019](https://www.inc.com/best-workplaces)!\n\nIn its fourth annual ranking for the private company sector, Inc.’s Best Workplaces list recognizes companies that have created exceptional workplaces through vibrant cultures, employee engagement, and stellar benefits.\n\nAlong with nearly 2,000 other participating companies, GitLab submitted an initial application followed by an anonymous employee survey, which gathered information about our team members’ confidence in the future, management effectiveness, trust, perks, and more.\n\nThere are many reasons we’re proud of the culture we’ve built and continue to sustain at GitLab, but we think it’s best to hear about it straight from our people.\nHere’s what a few of our [team members](/company/team/) from across the globe value most about life at GitLab:\n\n\n> “GitLab has a world-class team and industry-changing product velocity. I'm constantly learning from the people around me, and I've yet to hear anyone reject an idea because ‘It's just too hard.’ As a UX practitioner, we're often used to seeing our efforts get pushed down a backlog, but at GitLab, we see product refinements continually (and quickly) delivered into production. It's exciting and motivating.” [_– Christie Lenneville, UX Director_](/company/team/#clenneville)\n\n\n> “Working for GitLab is about something bigger than myself – it's bigger than my team, it's bigger than the employees – it's about partnering with the entire community to create better software.\nSimultaneously I get to help blaze a new trail – scaling an amazing culture with remote teams from around the globe.”\n[_– Joel Krooswyk, Manager, Customer Success_](/company/team/#JoelKroos)\n\n\n> “There are so many things that make GitLab special.\nTo start, of course, it's the people. I think this is due to the unique way in which we work – totally remotely from all around the globe.\nThere is a better chance of obtaining the best talent for the role when there aren't restrictions placed on location.\nThe flexibility also allows me to have time back for my family and life.\nThe stress is lower, I am happier working, and the overall work-life balance is just better here.”\n[_– Candace Byrdsong Williams, Diversity, Inclusion and Belonging Partner_](/company/team/#cwilliams3)\n\n\n> “Working at GitLab gives me confidence because we work with the highest level of transparency.\nBeing able to work remotely not only saves me on average two hours of daily commute time, but also makes it so efficient to respond to customers on time at any time.” [_– Xiaogang Wen, Solutions Architect_](/company/team/#xiaogang_gitlab)\n\n\n> “I love working at GitLab for a variety of reasons, but the flexibility in creating work-life harmony in my life tops my list.\nI work closely with our executive team here, and they have been so supportive and encouraging when family-related conflicts arise.\nThey are constantly reminding me that “family first” is our mantra, and give me ease of mind to take time away when needed.\nOutside of that, Sid, our co-founder and CEO, told me if it’s a beautiful day out and I just want to go enjoy it, I should do that.\nMoments like these make me so proud to be a part of the GitLab team.” [_– Cheri Holmes, Manager, Executive Assistant_](/company/team/#cheriholmes)\n\n\nWe celebrate this news as many of our team members are returning home from [GitLab Contribute](/events/gitlab-contribute/), the next iteration of our company [summits](/company/culture/contribute/previous/).\nHere's a glimpse of the fun we had together in New Orleans:\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/xdtPNXtkBhE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nThank you to all of our team members around the globe who contribute to making GitLab a great place to work.\n\nInterested in joining our fast-growing, [all-remote](/company/culture/all-remote/) team? [Check out our vacancies](/jobs/).\n",[1097,9,1203,934],"news",{"slug":1205,"featured":6,"template":698},"building-an-award-winning-culture-at-gitlab","content:en-us:blog:building-an-award-winning-culture-at-gitlab.yml","Building An Award Winning Culture At Gitlab","en-us/blog/building-an-award-winning-culture-at-gitlab.yml","en-us/blog/building-an-award-winning-culture-at-gitlab",{"_path":1211,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1212,"content":1218,"config":1223,"_id":1225,"_type":13,"title":1226,"_source":15,"_file":1227,"_stem":1228,"_extension":18},"/en-us/blog/can-an-smb-or-start-up-be-too-small-for-a-devops-platform",{"title":1213,"description":1214,"ogTitle":1213,"ogDescription":1214,"noIndex":6,"ogImage":1215,"ogUrl":1216,"ogSiteName":685,"ogType":686,"canonicalUrls":1216,"schema":1217},"Can an SMB or start-up be too small for a DevOps platform?","It may sound counter-intuitive but even a very small company or startup can take advantage of the power of a DevOps platform. Here's how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668213/Blog/Hero%20Images/innersourcing-improves-collaboration-within-an-organization.jpg","https://about.gitlab.com/blog/can-an-smb-or-start-up-be-too-small-for-a-devops-platform","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Can an SMB or start-up be too small for a DevOps platform?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-04-06\",\n }",{"title":1213,"description":1214,"authors":1219,"heroImage":1215,"date":1220,"body":1221,"category":757,"tags":1222},[734],"2022-04-06","\n\nIf you work in an IT team of five people – or maybe you’re even a team of one – it’s easy to think your business is simply too small to use DevOps.\n\nBut that’s not the case. A start-up or small and medium-sized business (SMB) is never too small to take advantage of a DevOps platform. \n\nIn fact, DevOps is [a great fit for a lot of SMBs](https://page.gitlab.com/resources-ebook-smb-beginners-guide-devops.html), or small and medium-sized enterprises (SMEs). Here’s how to understand if it will work for your team or organization and how it could help grow your business in a competitive environment.\n\n## The size of the business isn’t the issue\n\nLet’s be clear. If you are developing software, you need a DevOps platform. Size isn’t really the issue. No matter how small your business and your tech team, if you are iterating on software features, building applications, or automating parts of your product-related systems, then you do need DevOps. DevOps will even work for a team of one.\n\nHere’s how a DevOps platform can help an SMB:\n\n### Start small to foster innovation\n\nOne of the key aspects of DevOps is that it creates a [collaborative atmosphere](/blog/collaboration-communication-best-practices/), even beyond the software and IT teams. Adopting a single, end-to-end DevOps platform when your company is small or your start-up is just getting off the ground will enable and encourage everyone – whether they’re in a technical role or work in accounting, sales or as a business manager – to all work together. And that will foster innovation by bringing in ideas from people in a range of demographics and business interests. And innovative ideas will help new businesses get a foot in the door and help all SMBs grow into more successful and bigger companies.\n\n### Optimize your SMB for speed\n\nTo get established in the market, start-ups and small businesses need to deliver compelling products quickly, and be able to efficiently support them. DevOps will enable your team to [move from planning to production](/blog/pipelines-as-code/) faster and with greater ease. A DevOps platform extends through the entire software development lifecycle, from planning all the way through to launching new features, conducting analysis, and gathering feedback. Simply put, DevOps will optimize your organization for speed, which is just what SMBs and SMEs need.\n\n### Use DevOps to take on the “deep pockets”\n\nAs an SMB, you likely don’t have the deep pockets and market penetration of your more-established competitors. How do you boost your odds when taking them on? One way to increase your competitiveness is to use DevOps to boost speed and efficiency as you create new products, new services, and new ways to communicate with your customers. When you can deploy innovative ideas faster than your competitors, you’ll have a definite advantage.\n\n### Decrease your workload with automation\n\nWhen you have fewer hands to take on a huge workload, you need a way to not only speed production but to ease the number of tasks you’re facing – and all the headaches that come along with them. The [automation that is part of a DevOps platform](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/) will mean less manual work when it comes to processes like design, testing, development, deployment, and monitoring. Automation helps small teams free up time to handle all the other projects on their to-do lists. \n\n### Build security into software from the get-go\n\nWhen a company is getting started, it’s the perfect time to use DevOps to help build security into the code and processes from the very beginning. Small companies and startups need to “shift left” and focus on [security at the earliest stages](/blog/want-secure-software-development-our-top-5-tips-to-bring-dev-and-sec-together/). When security is baked in from the start, you won’t have to go back in later on to fix problems that could jeopardize your customers and your business.\n\n### Use DevOps to avoid silos\n\nMaybe your company is small enough that silos aren’t a problem… yet. But as a company grows, people often naturally separate off into [silos or groups that do not communicate with or understand each other](/blog/developing-a-successful-devops-strategy/). And they definitely don’t work well together. By fostering collaboration among IT teams and even non-technical groups across the business, a DevOps platform makes it easier to keep these silos from forming in the first place, and to break them down if they do form. As companies grow from 10 employees to 100 (or more), DevOps will help an organization stay connected and collaborative as it expands.\n\n### Start early to ensure collaboration \n\nIt’s easier to create a collaborative culture from the very beginning – when a company is still a start-up or an SMB – than to overhaul a large, established organization. Instilling an environment of [communication and collaboration](/blog/if-its-time-to-learn-devops-heres-where-to-begin/) is less disruptive and easier to manage in a company of 10, 25, or even 100 than in a much larger and complex business that is adding hundreds of employees a year. SMBs have the “nimble” advantage, meaning that change is easier than for larger competitors. \n\nSo there is no company too small to take advantage of a DevOps platform.\n",[695,9,9],{"slug":1224,"featured":6,"template":698},"can-an-smb-or-start-up-be-too-small-for-a-devops-platform","content:en-us:blog:can-an-smb-or-start-up-be-too-small-for-a-devops-platform.yml","Can An Smb Or Start Up Be Too Small For A Devops Platform","en-us/blog/can-an-smb-or-start-up-be-too-small-for-a-devops-platform.yml","en-us/blog/can-an-smb-or-start-up-be-too-small-for-a-devops-platform",{"_path":1230,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1231,"content":1237,"config":1243,"_id":1245,"_type":13,"title":1246,"_source":15,"_file":1247,"_stem":1248,"_extension":18},"/en-us/blog/celebrating-17-years-of-git",{"title":1232,"description":1233,"ogTitle":1232,"ogDescription":1233,"noIndex":6,"ogImage":1234,"ogUrl":1235,"ogSiteName":685,"ogType":686,"canonicalUrls":1235,"schema":1236},"Celebrating 17 years of Git","Here's the history, tips, tricks and even a mea culpa to help celebrate the 17th anniversary of Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679424/Blog/Hero%20Images/gitbirthday.jpg","https://about.gitlab.com/blog/celebrating-17-years-of-git","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Celebrating 17 years of Git\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-04-07\",\n }",{"title":1232,"description":1233,"authors":1238,"heroImage":1234,"date":1239,"body":1240,"category":693,"tags":1241},[846],"2022-04-07","\n\nSeventeen years ago, the Linux community embraced Git as its universal open source version control solution. Created by Linus Torvalds, Git replaced BitKeeper, a proprietary but free-of-charge option that worked, to a point, until it didn’t (and ultimately started costing a fee).\n\nIn the years since, there’s been little to no agreement on what the term “Git” actually means but there’s no disputing its rockstar status in the DevOps world. Tens of millions developers rely on Git’s fast and seamless branching capabilities every single day. In fact, 85% of DevOps professionals who took our [2021 Global DevSecOps Survey](/developer-survey/) said they use Git for source control.\n\nSo, to honor this anniversary, we share our favorite Git tips and tricks and look back at the origins of its name, its 15th anniversary celebration, and even a declaration from one of our own who was certain Git would _never be in his toolkit_. No, really.\n\n## The origin of the name Git\n\nThere’s not much quirky or charming about the world of DevOps, but the theories around the origin of the name Git may be an exception. Torvalds claimed to have named Linux after himself, and he said Git (British slang for “jerk”) was no different. “I’m an egotistical b*stard, and I name all my projects after myself,” he [said at the time](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git). \n\nThe source code’s README takes the story in a different direction: Git is easy to pronounce, not used by UNIX, and could sound like “get.” It could be [British shade-throwing](http://www.peevish.co.uk/slang/english-slang/g.htm?qa=150&ss360SearchTerm=git#git), or it could stand for “global information tracker” (the choice of those happily working with a functioning tool). And for those frustrated with Git, there’s also “goddamn idiotic truckload of sh*t.”\n\n## Tips and tricks for better Git\n\nIs it possible to improve on a tool that so many use every single day? Actually, it is, starting with 15 ways [to get a better Git workflow](/blog/15-git-tips-improve-workflow/). Learn how to:\n\n- autocomplete commands\n- use Git blame more efficiently\n- reset files\n- understand the plugins\n\nAlso, Git can help [keep merge requests tidy and humming along](/blog/start-using-git/).\n\nFor an exhaustive look at how GitLab uses Git internally, including .gitconfig on steroids, the lowdown on aliases, and command line tips, we’ve [gathered a life-changing list](/blog/git-tips-and-tricks/). Also, here’s our take on [why (and how) to keep your Git history clean](/blog/keeping-git-commit-history-clean/) and how to do it using [interactive rebase](/blog/keep-git-history-clean-with-interactive-rebase/).\n\n## Remembering the 15th anniversary celebrations\n\nLandmark anniversaries always make people reflect, and Git’s 15th in 2020 was no exception. Not only was there [an actual party – Git Merge 2020](/blog/git-merge-fifteen-year-git-party/), our staff developer evangelist Brendan O’Leary admitted the unthinkable: Back in the day, he was [never ever going to use Git](https://www.computerweekly.com/blog/Open-Source-Insider/GitLab-guru-15-years-later-were-still-learning). Brendan, who obviously has learned his lesson, also teamed up with GitHub’s distinguished software engineer Jeff King to talk about [Git’s impact on software development](https://www.infoq.com/news/2020/04/git-fifteen-anniversary-qa/).\n\n## Practical Git\n\nAlthough there’s a lot to learn about Git, Brendan and other developers consistently stress the simplicity is what sets it apart. So here are three of our most bookmarked pages of straightforward Git advice:\n\n[6 common Git mistakes and how to fix them](/blog/git-happens/)\n[Understand the new Git branch default name](/blog/new-git-default-branch-name/) \n[A guide to Git for beginners](/blog/beginner-git-guide/)\n\nSo make sure to raise a glass to 17 years of Git and its many benefits.\n",[1242,695,9],"git",{"slug":1244,"featured":6,"template":698},"celebrating-17-years-of-git","content:en-us:blog:celebrating-17-years-of-git.yml","Celebrating 17 Years Of Git","en-us/blog/celebrating-17-years-of-git.yml","en-us/blog/celebrating-17-years-of-git",{"_path":1250,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1251,"content":1257,"config":1265,"_id":1267,"_type":13,"title":1268,"_source":15,"_file":1269,"_stem":1270,"_extension":18},"/en-us/blog/cern-connect-global-researchers",{"title":1252,"description":1253,"ogTitle":1252,"ogDescription":1253,"noIndex":6,"ogImage":1254,"ogUrl":1255,"ogSiteName":685,"ogType":686,"canonicalUrls":1255,"schema":1256},"CERN uses GitLab to remove the obstacles around global researchers","Learn how GitLab helps particle physics laboratory CERN manage over 7,000 projects globally","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670719/Blog/Hero%20Images/cern.jpg","https://about.gitlab.com/blog/cern-connect-global-researchers","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"CERN uses GitLab to remove the obstacles around global researchers\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Kim Lock\"}],\n \"datePublished\": \"2018-10-12\",\n }",{"title":1252,"description":1253,"authors":1258,"heroImage":1254,"date":1260,"body":1261,"category":693,"tags":1262},[1259],"Kim Lock","2018-10-12","\n\nCERN is the European Organization for Nuclear Research. Using highly sophisticated\ninstruments, the organization’s physicists and engineers study the fundamental particles\nthat are the building blocks of the universe. This organization was looking for a way to\novercome the challenges associated with managing thousands of projects with numerous contributors\nlocated all around the world.\n\nTo assist with these challenges, the [CERN IT department searched for a streamlined solution](https://about.gitlab.com/customers/cern/) for\ncode review. In addition to having the capacity to get a large number of projects and users up and\nrunning quickly, they were also looking for their selection to be easy for those users who are less\nexperienced with Git. GitLab met their requirements and they began utilizing these features.\n\nCERN chose to make the move to GitLab for their code hosting needs approximately three years ago. CERN\nhas long been a strong advocate for open source software, and solutions enabling data sovereignty. GitLab’s\nopen core, self-managed model was attractive to the organization because of these desires.\n\n### Today CERN has more than 12,000 users using GitLab and runs 120,000 CI jobs per month\n\n“It’s clearly a powerful tool to do our operations, code collaboration and record discussions on our\ndevelopment and deployment process. We can do more because we can handle more complex projects. As an\nindividual, I’m able to be involved with several large projects because I can rely on GitLab, and the\nother development tools that we have deployed around GitLab, to keep track of things. This is my perception\nas a GitLab user for three years: it’s not that I can do new things, but I can do more because of the\nefficiency of the tool,” said Alex Lossent, Version Control Systems Service Manager, CERN IT department\n\nThe team at CERN's IT department recently sat down with us to share the details of how GitLab is helping\nthem bridge the gaps of working and communicating in a global workspace. “We have this main analysis code on\nGitLab with millions of lines of code. Each team of physicists also has their own repositories with their\nspecific data analysis. And the on-premise nature of GitLab is really useful because we can access other CERN\nservices, data storage and other information that we wouldn’t have on GitHub,” Lukas Heinrich, a partner\nphysicist currently studying at New York University, explained.\n\nYou can learn more about CERN's story and how they are using GitLab in this case stuy [Particle physics laboratory uses GitLab to connect researchers from across the globe](https://about.gitlab.com/customers/cern/)\n",[1263,1264,9,1097],"user stories","code review",{"slug":1266,"featured":6,"template":698},"cern-connect-global-researchers","content:en-us:blog:cern-connect-global-researchers.yml","Cern Connect Global Researchers","en-us/blog/cern-connect-global-researchers.yml","en-us/blog/cern-connect-global-researchers",{"_path":1272,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1273,"content":1279,"config":1286,"_id":1288,"_type":13,"title":1289,"_source":15,"_file":1290,"_stem":1291,"_extension":18},"/en-us/blog/cern-contributor-post",{"title":1274,"description":1275,"ogTitle":1274,"ogDescription":1275,"noIndex":6,"ogImage":1276,"ogUrl":1277,"ogSiteName":685,"ogType":686,"canonicalUrls":1277,"schema":1278},"GitLab Code Contributor: Daniel Juarez","Daniel Juarez shares his experience contributing to GitLab from CERN.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673096/Blog/Hero%20Images/contributors-cover.png","https://about.gitlab.com/blog/cern-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Daniel Juarez\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-06-19\",\n }",{"title":1274,"description":1275,"authors":1280,"heroImage":1276,"date":1282,"body":1283,"category":784,"tags":1284},[1281],"Ray Paik","2019-06-19","\n\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm excited to introduce [Daniel Juarez](https://gitlab.com/danieljg) from [CERN](https://home.cern/).\n\n### Can you tell us about you do at CERN and what Geneva is like?\n\nI started working at CERN in September 2017 as an associate for the Version Control Systems team. I came to CERN from the [University of Oviedo](http://www.uniovi.es/en) in Spain, as the university has an arrangement with CERN to give its students an opportunity to work here. One of my main responsibilities is to improve, maintain, and support the GitLab setup at CERN, as well as the continuous integration (CI) infrastructure.\n\n[Geneva](https://www.google.com/maps/place/Geneva,+Switzerland/@46.2050241,6.1089833,13z) feels like an extension of CERN, as you can meet people from all over the world with so many international organizations in the city. It may not be the best place in the winter if you are not into skiing, but the city has a wonderful lake and is full of life in the summer.\n\n![Daniel Juarez](https://about.gitlab.com/images/blogimages/Daniel_Juarez.jpeg){: .shadow.small.right.wrap-text}\n\n### How long have you used GitLab and why did you decide to make contributions?\n\nI first used GitLab when I joined CERN. Contributing to GitLab is part of my job, and [my first merge request (MR)](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/965) was on [the Runner project](https://gitlab.com/gitlab-org/gitlab-runner).\n\nIn addition to MRs, I create issues and work with the GitLab team to find solutions. A good example is the [storage performance issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/11556) that we ran into recently.\n\n### Do you plan/coordinate contributions to GitLab at CERN or is contribution done on an individual basis? Any advice for GitLab customers who want to make contributions?\n\nWe keep track of our current GitLab issues and improvement areas in our internal Jira instance, and from there we organize who will submit an MR or open an issue with GitLab. We have a few other GitLab contributors at CERN, like [Alex Lossent](https://gitlab.com/alexcern) and [Borja Aparicio](https://gitlab.com/baparici).\n\nIn terms of advice for others, I encourage people to ping GitLab team members, such as product managers or maintainers, if you feel like your MRs or issues are not being picked up in a timely manner. You can find GitLab team members either on the [team page](/company/team/) or the [product categories page](https://handbook.gitlab.com/handbook/product/categories/). It's also helpful to note how many users are being impacted by your issue. Even though only one person from your organization may be commenting on an issue or MR, it could actually have an impact on thousands of people.\n\n### What has been your experience when contributing to GitLab?\n\nGitLab team members are always eager to help. They show interest in community issues and MRs, which is highly appreciated. Engagement from the GitLab team has helped us improve the service we provide to ~16,000 GitLab users at CERN.\n\nHowever, we are concerned about the large number of open issues at GitLab. Even if issues have the `customer` label, we are concerned that sometimes they could be forgotten.\n\n### Are there any community contributions (MRs) to GitLab that you thought were particularly interesting/useful?\n\nFrom CERN, we were definitely happy to have [SAML support](/releases/2015/06/22/gitlab-7-12-released/) a few years ago. We also found [Shared CI Runners for groups](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646) to be helpful, because some of our users were required to have the same runner registered against multiple projects instead of having it per group. This clearly improved the service for many of our users that rely on private runners and cannot use our shared infrastructure.\n\n### What do you like to do when you're not working?\n\nI love playing video games no matter the genre. Recently, I started watching bad movies and learning to cook new dishes (usually at the same time). I find that cooking helps me digest the bad movies!\n\n### Anything else you want to share with the community?\n\nDo not be afraid to submit MRs! It might look difficult in the beginning, but GitLab team members will do their best to help your changes \"go upstream\" to GitLab. I learned that wider community members are also willing to help.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],"contributors",{"slug":1287,"featured":6,"template":698},"cern-contributor-post","content:en-us:blog:cern-contributor-post.yml","Cern Contributor Post","en-us/blog/cern-contributor-post.yml","en-us/blog/cern-contributor-post",{"_path":1293,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1294,"content":1300,"config":1308,"_id":1310,"_type":13,"title":1311,"_source":15,"_file":1312,"_stem":1313,"_extension":18},"/en-us/blog/chris-hill-devops-enterprise-summit-talk",{"title":1295,"description":1296,"ogTitle":1295,"ogDescription":1296,"noIndex":6,"ogImage":1297,"ogUrl":1298,"ogSiteName":685,"ogType":686,"canonicalUrls":1298,"schema":1299},"How Jaguar Land Rover embraced CI to speed up their software lifecycle","Inspiration, persistence, an attitude of continuous improvement – how adopting CI helped this vehicle company implement software over the air.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667619/Blog/Hero%20Images/chris-hill-jlr-does.jpg","https://about.gitlab.com/blog/chris-hill-devops-enterprise-summit-talk","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How Jaguar Land Rover embraced CI to speed up their software lifecycle\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n \"datePublished\": \"2018-07-23\",\n }",{"title":1295,"description":1296,"authors":1301,"heroImage":1297,"date":1302,"body":1303,"category":1304,"tags":1305},[1158],"2018-07-23","\n\n[CI/CD](/topics/ci-cd/) gets us pretty excited anyway, but it's not often we get to talk about how it improves something as cool as a luxury car. Chris Hill, Head of Systems Engineering for Infotainment at Jaguar Land Rover, recently shared his own team's journey from feedback loops of 4-6 weeks to just 30 minutes, in this inspiring talk from [DevOps Enterprise](/stages-devops-lifecycle/) Summit London 2018.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/CEvjB-79tOs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Key takeaways from Chris' talk\n\n### What's needed for transformation\n\n\u003Cdiv class=\"panel panel-default twitter-block\"> \u003Ca class=\"twitter-block-link panel-body\" href=\"http://twitter.com/share?text=%22Driving change within an enterprise requires three qualities: inspiration, persistence, and an attitude of continuous improvement.%22 – @chillosuvia via @gitlab&url=https://about.gitlab.com/blog/chris-hill-devops-enterprise-summit-talk/&hashtags=\" rel=\"nofollow\" target=\"_blank\" title=\"Tweet!\"> \u003Cspan class=\"twitter-text pull-left\"> \"Driving change within an enterprise requires three qualities: inspiration, persistence, and an attitude of continuous improvement.\" – @chillosu via @gitlab \u003C/span> \u003Cspan class=\"click-to-tweet\"> Click to tweet! \u003Ci class=\"fab fa-twitter\">\u003C/i> \u003C/span> \u003C/a> \u003C/div>\n\n### How you respond to complaints matters\n\n> \"Equally if not more important than the complaint itself, is the response or reaction to the complaint. 'Can I bring a complaint, that I know my voice is heard and that somebody cares about resolving my issue?'\"\n\n> \"'I asked the ops team three weeks ago to add a build dependency on the build servers, and it still hasn't been added. I'm just going to go back to building on my own.' This complaint obviously is a knife right to the heart because you feel like you've started to regress. But what I like about this complaint is it led to a behavioral change as well as a technical change. We decided instead of continuing the same direction, to move to ephemeral Docker containers to run all of our builds. With ephemeral Docker containers we defined every piece of build infrastructure as code. We used packer recipes to find a Docker container, and every app developer could now change the underlying infrastructure which built their application. They were empowered. They now had the self service to do their lifecycle on their own. And you're never going to receive the ops complaint because you've handed over the keys.\"\n\n### Efficient feedback loops are critical\n\n> \"Our feedback loops were 4-6 weeks. Could you imagine writing code today and six weeks from now being told whether or not it works or is broken? I don't remember the shirt that I wore yesterday, let alone what I had for breakfast this morning, let alone what I wrote six weeks ago, and chances are I've been working on features for the last six weeks, and for me to try to unpick what I was thinking at that point could be a huge context-switch penalty.\"\n\n> \"Infotainment also had a significantly higher number of contributors – up to 1,000 contributors. And what we noticed is that contributions don't come linearly, they come in bursts. We actually found that Thursdays were the day that most of our developers committed on. And when we had manual code reviews, if we didn't have reviewers ready on a Thursday, we would create our own backlog.\"\n\n### Deployments don't have to be limited to a traditional release cycle\n\n> \"How could we change the game? Instead of ditching the combustion engine, we ditched the dealership visits, and we implemented software over the air. And this huge Linux distribution that we build upwards towards 700 times per day in a continuous integration pattern, on a dev branch or a master branch, or a release branch, we can now deliver to every vehicle in the form of small, incremental deltas. We can also deliver it to the vehicle while you're driving, and not interrupt your daily life. In fact I showed Gene yesterday, we started a download and an install while I was driving, and the entire thing happened in the background. Jeff even made the comment, 'This is blue-green deployment for vehicles.'\"\n\n> \"One of my favorite indicators is deploys per day, per developer. But I was always embarrassed to share ours because it was always below one. All of our new software wouldn't actually make it to vehicles; it was always batched together. Now I'm happy to say we can deploy, and we have been in our engineering environment, 50-70 times per day of each individual piece of software to a target or to a vehicle.\"\n\n> \"No longer are deployments limited to a traditional software release cycle. We've now skirted every single process to get a technician a new piece of software, and bother somebody else's day – one of our owners – to come into a dealership and spend an hour waiting for their vehicle to be done. We've now empowered the customer to be their own technician.\"\n","customer-stories",[695,9,1306,1263,1307,1141],"CI","automotive",{"slug":1309,"featured":6,"template":698},"chris-hill-devops-enterprise-summit-talk","content:en-us:blog:chris-hill-devops-enterprise-summit-talk.yml","Chris Hill Devops Enterprise Summit Talk","en-us/blog/chris-hill-devops-enterprise-summit-talk.yml","en-us/blog/chris-hill-devops-enterprise-summit-talk",{"_path":1315,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1316,"content":1322,"config":1329,"_id":1331,"_type":13,"title":1332,"_source":15,"_file":1333,"_stem":1334,"_extension":18},"/en-us/blog/cofounder-relations",{"title":1317,"description":1318,"ogTitle":1317,"ogDescription":1318,"noIndex":6,"ogImage":1319,"ogUrl":1320,"ogSiteName":685,"ogType":686,"canonicalUrls":1320,"schema":1321},"Co-founders: Key conversations build lasting relationships","Our CEO sits down with leadership psychologist Banu Hantal to discuss his relationship with GitLab co-founder Dmitriy Zaporozhets.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680642/Blog/Hero%20Images/cofounders_phone.jpg","https://about.gitlab.com/blog/cofounder-relations","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The secret to an enduring co-founder relationship? Have those crucial conversations\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2019-06-21\",\n }",{"title":1323,"description":1318,"authors":1324,"heroImage":1319,"date":1326,"body":1327,"category":300,"tags":1328},"The secret to an enduring co-founder relationship? Have those crucial conversations",[1325],"Sara Kassabian","2019-06-21","\n\nIn the latest installment of our [Pick Your Brain](/blog/tags.html#pick-your-brain) series, leadership psychologist [Banu Hantal](https://www.banuhantal.com/) interviews our CEO [Sid Sijbrandij](/company/team/#sytses) about his relationship with co-founder and engineering fellow [Dmitriy Zaporozhets](/company/team/#dzaporozhets). In their discussion, Sid shares GitLab’s origin story and talks about how transparent communication with Dmitriy helps keep their partnership strong.\n\n## The beginning of GitLab\n\nDmitriy and Sid’s partnership started in the same place as most modern-day relationships: online. Dmitriy started GitLab while he was working elsewhere, and within a year of GitLab’s launch, 300 people had contributed code.\n\nSid saw that GitLab had potential as a service and started GitLab.com independently of Dmitriy. Sid didn’t need Dmitriy’s permission to do this, because [GitLab was (and partially remains) open source](/blog/gitlab-is-open-core-github-is-closed-source/), but reached out to Dmitriy to let him know about the next iteration of the project. Dmitriy was gracious and celebrated the fact that Sid was expanding the impact of GitLab.\n\nFor about a year, Sid invested in building GitLab.com while also working as a consultant until Dmitriy posted a tweet saying, “I want to work on GitLab full time.” That tweet changed GitLab’s story.\n\n“It was quite unusual to post that to the entire world. He was employed and everything,” says Sid. “I emailed Dmitriy and I said ‘Hey, I saw your tweet, how much do you want to earn to start working on GitLab?’”\n\nBy this time, there were a few big companies that were using GitLab.com and they were asking Sid to add new features to the product. Once Dmitriy came on board, it was possible to build those features quicker.\n\n“I went to the local Western Union money office, and when I said I wanted to wire money from the Netherlands to the Ukraine, they were like, ‘Do you know this person or is this someone you met over the internet?’”\n\n“You didn’t even know what Dmitriy looked like?!” exclaims Banu.\n\n“At that point my mental image of Dmitriy was like a pink mob boss because that was his avatar,” says Sid, but that didn’t last for long. They finally met in person in Krakow shortly after making plans to commit their efforts to GitLab full time.\n\n## Communication makes for happy co-founders\n\n\"Do you think having a mostly remote relationship is an advantage or disadvantage?\" asks Banu.\n\n\"I don't think it matters that much,\" says Sid. \"I think you do the same things, and you've got to make sure there's regular communication. To this day we have a call every single week. When there’s something important he gets a heads up so he doesn’t feel misinformed.\"\n\nIf there is an issue that is clearly contentious, Sid says, they put all the information on the table and discuss the problem directly.\n\n“I think surprises are really bad. You want to make sure if there’s something important that you get a heads up, and that there is a regular cadence of communication.”\n\nThough Dmitriy and Sid rarely get the chance to interact in person today, there is very little conflict in their relationship.\n\n## What to do when one co-founder is the CEO\n\n“What you don’t want is the [Peter Principle](https://en.wikipedia.org/wiki/Peter_principle), where the only way for an engineer to advance is to become a manager,” says Sid. “And then, oftentimes, you lose a great engineer and get a bad manager.”\n\nSo, they elected to structure GitLab the company so there are more leadership opportunities for engineers by offering a dual-career track. While Sid is co-founder and CEO of the company, Dmitriy is a co-founder and engineering fellow. A fellowship offers a path to advancement for engineers that does not involve people management.\n\nThough GitLab was first built as an alternative to GitHub, it has since expanded its technical capabilities ten-fold, explains Sid. In fact, it was Dmitriy that first built the [CI solution](/solutions/continuous-integration/) and continuous testing framework which is a core component to our product today.\n\n“I was like, he can do whatever he wants – he’s a co-founder and so far his hunches pay off. At a certain point someone contributed to that and then they joined the company and said, 'Let’s integrate the two products.' First Dmitriy told him he was wrong, and then together they came to me and I told them they were wrong, and we ended up doing it and it was the best thing that ever happened to GitLab.”\n\n“How would you describe your relationship with Dmitriy?” asks Banu.\n\nThere are three dimensions to the partnership between Sid and Dmitriy. They are co-founders, there is a hierarchical relationship with Sid as CEO, and of course, a friendship.\n\n“I think it’s frequently better to fall in love with each other’s work and then build a relationship based on that, rather than fall in love with the person and then try to build a business,” says Sid. “Friendships based on business tend to last longer than businesses based on friendships.”\n\nWatch the full conversation between Sid and Banu here:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/gpQKtSKMzkI?start=6\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nPhoto by [Pavan Trikutam](https://unsplash.com/@ptrikutam) on [Unsplash](https://unsplash.com/photos/71CjSSB83Wo)\n{: .note}\n",[934,787,9],{"slug":1330,"featured":6,"template":698},"cofounder-relations","content:en-us:blog:cofounder-relations.yml","Cofounder Relations","en-us/blog/cofounder-relations.yml","en-us/blog/cofounder-relations",{"_path":1336,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1337,"content":1342,"config":1348,"_id":1350,"_type":13,"title":1351,"_source":15,"_file":1352,"_stem":1353,"_extension":18},"/en-us/blog/collaborating-on-a-cross-stage-feature",{"title":1338,"description":1339,"ogTitle":1338,"ogDescription":1339,"noIndex":6,"ogImage":924,"ogUrl":1340,"ogSiteName":685,"ogType":686,"canonicalUrls":1340,"schema":1341},"How we tested a feature that affected (almost) all parts of GitLab","Crowd-sourcing testing across teams","https://about.gitlab.com/blog/collaborating-on-a-cross-stage-feature","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we tested a feature that affected (almost) all parts of GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aakriti Gupta\"}],\n \"datePublished\": \"2021-03-17\",\n }",{"title":1338,"description":1339,"authors":1343,"heroImage":924,"date":1345,"body":1346,"category":716,"tags":1347},[1344],"Aakriti Gupta","2021-03-17","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn 13.9 Team Geo [released Maintenance Mode](https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#maintenance-mode), which was a large, cross stage and cross team project, a few milestones in the making.\n\nThis feature allows system administrators to put GitLab in a read-only mode. All parts of the system are affected and testing such a wide scope was challenging.\n\n## Why was testing this feature hard?\n\nAs we started testing with the QA team, it was clear that no one individual or team could know enough about the entire product to design a comprehensive QA plan. The more we tested, the more features we found to test - it was soon becoming an impossibly long list of tests to write for our small team.\n\nWe needed to prioritize manually testing the most important features, and save working on automated tests for another iteration.\n\nBut, what were the most important things to test?\n\nThis is where we decided to crowd-source testing. [We rolled-out discussion issues](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=closed&author_username=aakriti.gupta&search=crowd-sourced+maintenance+mode+testing) to each of the 13 stages and asked them to contribute the three most important features that they own, that we should prioritise testing.\n\nWe used these issues to share knowledge of maintenance mode, and responsibility of its development, testing and documentation.\n\nThe response was overwhelming!\n\nProduct managers and engineers from across the development department contributed to our list of tests and collaboratively reviewed and improved documentation. They proactively asked how their features would behave and in some cases, even started MRs to fix the documentation.\n\nThe conversations helped us hone our plan for future iterations of this feature.\n\n## What we learned\n1\\. **Test iteratively and collaboratively**\n\nGet QA and developer teams working together early, instead of after development is almost done, or worse - after release. GitLab's [Quad planning](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning/) process was introduced last year to foster better collaboration between Quality, Development, UX, and Product teams. As [Jennie from QA](https://gitlab.com/jennielouie) chalked out a plan for QA together with developers, she found a few edge cases that would have otherwise been discovered too late.\n\n2\\. **Don’t hesitate to ask other teams to contribute**\n\nWhen we rolled out a dozen plus issues to all development teams, we were not sure if we’d get even a few responses, but we were overwhelmed with the interest, response and active participation that came from all the teams.\n\n3\\. **Communicate well**\n\nGive people enough and succinct information. When requesting help from other teams, help them prioritize the request by explaining the why.\n\n4\\. **Documentation as a form of developer communication**\n\nAs we worked through large documentation MRs, I realized the documentation was not only important for system administrators, but for developers of GitLab as well. Developers wanted to know how maintenance mode affected their features.\n\n5\\. **Iterate**\n\nKeep the discussions short-lived and focused on the most important aspects. Do not draw out the conversations too long, and move pending conversations over to follow-up issues.\nAs we learned of new test cases, [Nick from QA](https://gitlab.com/nwestbury) and I created follow-up test issues to resolve together with DRIs.\n\n6\\. **The more, the merrier**\n\nWhile the discussions started only with Engineering Managers and Product Managers, they often invited engineers in their conversations and this brought more eyes to the project and helped us answer a lot of unknowns.\n",[9,934,1097,1055,912],{"slug":1349,"featured":6,"template":698},"collaborating-on-a-cross-stage-feature","content:en-us:blog:collaborating-on-a-cross-stage-feature.yml","Collaborating On A Cross Stage Feature","en-us/blog/collaborating-on-a-cross-stage-feature.yml","en-us/blog/collaborating-on-a-cross-stage-feature",{"_path":1355,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1356,"content":1362,"config":1368,"_id":1370,"_type":13,"title":1371,"_source":15,"_file":1372,"_stem":1373,"_extension":18},"/en-us/blog/collaboration-communication-best-practices",{"title":1357,"description":1358,"ogTitle":1357,"ogDescription":1358,"noIndex":6,"ogImage":1359,"ogUrl":1360,"ogSiteName":685,"ogType":686,"canonicalUrls":1360,"schema":1361},"Improving DevOps with Better Communication & Collaboration","The most important skills for a DevOps pro? Collaboration and communication. We share some of our best blogs, articles, and videos to help you work better, together.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681779/Blog/Hero%20Images/chatbubble.jpg","https://about.gitlab.com/blog/collaboration-communication-best-practices","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Improving DevOps and software development with communication and collaboration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2020-11-23\",\n }",{"title":1363,"description":1358,"authors":1364,"heroImage":1359,"date":1365,"body":1366,"category":693,"tags":1367},"Improving DevOps and software development with communication and collaboration",[1325],"2020-11-23","\n\nWe believe that the best software developers, companies, and products are those that embrace collaboration and transparency in communication, which is why we’ve compiled some of our best blog posts, articles, and videos about the topic in this blog collection.\n\nBut first, has your engineering team adopted a [DevOps](/topics/devops/) strategy? [Start here if you need help communicating why DevOps is the best approach](/blog/devops-stakeholder-buyin/) to stakeholders outside the engineering team.\n\n## What is DevOps collaboration?\n\nCollaboration is as important to DevOps as automation and nearly as hard to achieve. Software development was traditionally split into very different functions that didn’t work together; the advent of DevOps, bringing dev and ops together, was designed to change all of that. \n\n## Why collaboration in software development matters\n\nWe unpack three key reasons why collaboration is an essential skill for software developers.\n\n### 1. Your future as a software developer is bright if you embrace collaboration\n\nWhile some might consider teamwork and communication to be soft skills, the results of our [2020 DevSecOps](/developer-survey/) survey reveal a consensus among developers, security pros, ops team members, and testers that collaboration and communication are the most important skills for a DevOps professional.\n\n\"You can’t have one brain that knows it all,\" explains [Darwin Sanoy](/company/team/#DarwinJS), senior solutions architect, Americas, at GitLab. \"You need communication and collaboration to work together.\" Read more to learn about how to [brush up on soft skills to future-proof your DevOps career](/blog/future-proof-your-developer-career/) .\n\n### 2. The best way to practice collaborative software development? In open source communities\n\nGitLab is an open-core product with [open source and source-available code](/handbook/marketing/strategic-marketing/tiers/#open-source-vs-source-available). This means that community contributors can push changes to our open source codebase, and can view our proprietary, source-available code. Anyone who has been a part of an open source community can tell you that they’re very global, so you could be living in Mexico and [collaborating on an MR with someone in Poland](/blog/gitlab-hero-devops-platform/). Global collaboration without needing a passport is enriching and unique, but sometimes cultural differences can give way to miscommunication. The best way to embrace working in open source communities is to practice mindful communication and always [assume positive intent](https://handbook.gitlab.com/handbook/values/#assume-positive-intent). Most of the time, conflict is the result of misunderstanding, not malevolence.\n\nEarlier this year at [GitLab Commit Virtual](https://www.youtube.com/playlist?list=PLFGfElNsQthYQaTiUPQcu4O0O20WHZksz), we shared some communication hacks to help you seem approachable and invite dialog while contributing to open source communities. Watch the video below to learn all about it.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/XTBWX-evVEA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nAnd while open source and security might seem like a strange coupling, we found that community contributions helped fortify our GitLab Secure product. [Read the blog post](/blog/integrating-with-gitlab-secure/) to learn more about how inviting contributions from our open source community helped users extend our product to suit their needs.\n\n### 3. Why can’t dev and sec be friends?\n\nTeamwork doesn’t always come easily, particularly when you’re on opposite sides of the DevOps lifecycle. While at GitLab, dev and sec teams do work well together, this isn’t the case on every engineering team.\n\n[Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab, and [Ethan Strike](/company/team/#estrike), security manager for Application Security, [talk candidly about their respective objectives and how it’s better to integrate security into the development process](/blog/developer-security-divide/), as opposed to tacking it onto the end.\n\n## Best practices for developers\n\nWe explain why code review and pair programming are two methods that help engineering teams ship more stable code.\n\n### Code reviews for all\n\nFast feedback is one of the pillars of collaborative software development practices, and code reviews are an essential component. Whether you’ve been coding for 10 years or 10 weeks, having more than one person review your work is critical for catching errors and shipping stable code. But that doesn’t mean code reviews are simple. [Read our blog post on the challenges of code review](/blog/challenges-of-code-reviews/) to learn tips on how to overcome the hurdles, and [watch the demo on how to use GitLab for code review](https://page.gitlab.com/resources-demo-scm.html). [Phil Hughes](/company/team/#iamphill), staff frontend engineer for the Create: Code Review team summarizes [four tips to make code review more efficient and less painful](/blog/efficient-code-review-tips/). But all in all, we believe that despite the challenges of code review, it’s absolutely worth any hassle.\n\nWhile you’re at it, [check out our blog post where we share some of our ideas about the future of merge requests and code review](/blog/future-merge-requests-realtime-collab/) with GitLab. Not all of the ideas will necessarily be implemented, but it will give you some insight as to our vision moving forward.\n\n### Use the buddy system\n\nPair programming is basically code review in real time, and it is also one of the pillars of [Agile software development](/solutions/agile-delivery/). Typically it is done with two programmers at the same workstation, but when you’re on a a globally distributed team like we are at GitLab, that workstation exists in the virtual realm instead of IRL. In pair programming, one programmer creates the code (the driver) while the other person reviews the code (the navigator).\n\n>\"Programming is fairly abstract. When you have to explain a concept verbally, it often makes you realize you're missing pieces or that there are better ways to solve problems than your initial idea.\" – [Brandon Lyon](/company/team/#brandon_m_lyon), marketing web developer/designer\n\nThat’s not to say pair programming is the ideal workflow for everyone, one developer said that, as an introvert, pair programming is tiring. But one of the key benefits is that it speeds up the software development process and allows you to ship more stable code, faster. Read more about [the upsides and downsides to pair programming for Agile software development](/blog/agile-pairing-sessions/).\n\n## Best practices for collaboration on non-engineering teams\n\nThe tools and strategies you use to communicate may vary based on where you sit in your company, but there are a few best practices that engineering teams use that can be applied to non-engineering teams, such as pairing up on design, code production, and even writing projects. Check out some of our blog posts about [how to use GitLab for collaborative project management within and across teams](/blog/collaboration-in-product-planning/).\n\n* [**How designers collaborate sychronously**](/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab/): Pair designers, coffee chats with team members across GitLab, weekly UX showcases, calls with product designers and product managers, and other strategies.\n* **How Marketing uses GitLab for project management**: In [part one](/blog/gitlab-for-project-management-one/), we explain why the architecture of GitLab is so effective for project management, even for users in non-technical roles. In [part two](/blog/gl-for-pm-prt-2/), we share some real-life examples of how we use GitLab was used for successful project management.\n\n### Other inventive ideas for collaboration\n\nIn a stroke of genius, our Support team recognized that the weekly team all-hands meeting was getting a bit dull, and decided to change up the format and distribute it as a [podcast instead](/blog/how-we-turned-40-person-meeting-into-a-podcast/). The podcast format allowed team members to listen to the weekly update asynchronously, which is an essential component of communication for a globally distributed team such as ours. This is a great example of how thinking outside the box can improve how information is disseminated.\n\n## Some challenges with DevOps collaboration\n\n- **Maintaining security.** Security and compliance are critical for successful DevOps, but these areas have traditionally been siloed, making collaboration tricky at best.\n- **Too many people on a project**. Large and busy teams can struggle with communication and collaboration.\n- **Lots of communication options.** Using email, instant messaging, tickets, Zoom recordings, and more to house project info can cause things to slip through the cracks. \n- **Dealing with different personality types and working styles.** Individual needs and preferences can vary wildly and it can be a struggle to keep everyone on the same page.\n\n## Want more information on collaborative software development?\n\nTrust us, you’ll want to [bookmark this page](/topics/version-control/software-team-collaboration/) so examples of best practices for collaboration are just a click away for the times when you’re feeling stumped or siloed.\n\n[Watch the webcast](/webcast/collaboration-without-boundaries/) to learn how to bring cross-functional teams together using GitLab to deliver more stable software, faster.\n\nCover image by [Volodymyr Hryshchenko](https://unsplash.com/@lunarts?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/V5vqWC9gyEU)\n{: .note}\n",[9,695],{"slug":1369,"featured":6,"template":698},"collaboration-communication-best-practices","content:en-us:blog:collaboration-communication-best-practices.yml","Collaboration Communication Best Practices","en-us/blog/collaboration-communication-best-practices.yml","en-us/blog/collaboration-communication-best-practices",{"_path":1375,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1376,"content":1381,"config":1389,"_id":1391,"_type":13,"title":1392,"_source":15,"_file":1393,"_stem":1394,"_extension":18},"/en-us/blog/collaboration-in-product-planning",{"title":1377,"description":1378,"ogTitle":1377,"ogDescription":1378,"noIndex":6,"ogImage":1174,"ogUrl":1379,"ogSiteName":685,"ogType":686,"canonicalUrls":1379,"schema":1380},"Successful collaboration approaches in product planning","Collaboration can be hard, but we've found a few tips and tricks that help us succeed here at GitLab.","https://about.gitlab.com/blog/collaboration-in-product-planning","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Successful approaches for team collaboration between Design, Product, Engineering, and Quality\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n \"datePublished\": \"2020-06-03\",\n }",{"title":1382,"description":1378,"authors":1383,"heroImage":1174,"date":1385,"body":1386,"category":716,"tags":1387},"Successful approaches for team collaboration between Design, Product, Engineering, and Quality",[1384],"Jason Yavorska","2020-06-03","\nWithin the CI/CD sub-department here at GitLab we've been focusing on improving collaboration between each of the internal teams that contribute to our success as we move through our [product process](/handbook/product-development-flow/): Design, Product, Writing, Quality, and Engineering. We've noticed a few key points that really seem to make a big difference: \n\n## Team collaboration: Understand the problem you're trying to solve early\n\nTry to recognize early when you don't understand the problem to solve, or if there's disagreement. And even when you think you have the solution, test it out a bit and explore some edge cases (or you'll have to loop back around again). As an important benefit, a good understanding of the problem to solve will help you come up with the [smallest but valuable iteration](https://handbook.gitlab.com/handbook/values/#iteration).\n\n### Don't make it one person's job to lead the way or get things started\n\nWe expect an active contribution from everyone on the team around defining the problem and coming up with the solution for it. Everyone has an [important role to play](/handbook/product/product-processes/#pm-em-ux-and-set-quad-dris) - Product Manager, Product Designer, Quality, and Engineering. \n\nWhile Product Managers should be able to clearly articulate why something is prioritized, they should not be seen as the only facilitator of product advancement. It's a team effort, and everyone at GitLab is expected to be a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one). \n\n### Take advantage of everyone's different expertise\n\nSometimes, a bit of research will really align to one area of expertise. Maybe there's a business opportunity for the Product Manager, a complex visualization of data for the designer, or a hard technical challenge for the engineer - each of these can cause that person to go off and lead the way for that aspect. But they should have the support of the rest of the group. In all other cases, understanding the problem and coming up with a solution (whether using the product validation flow or just informally in an issue) is a team effort, and everyone is equally important.\n\nFollowing these principles will help your team both build trust and learn to recognize when more analysis is needed instead of pushing ahead too early. It will also help you to achieve more than any one person can do on their own.\n",[1096,1388,1055,807,9],"product",{"slug":1390,"featured":6,"template":698},"collaboration-in-product-planning","content:en-us:blog:collaboration-in-product-planning.yml","Collaboration In Product Planning","en-us/blog/collaboration-in-product-planning.yml","en-us/blog/collaboration-in-product-planning",{"_path":1396,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1397,"content":1403,"config":1410,"_id":1412,"_type":13,"title":1413,"_source":15,"_file":1414,"_stem":1415,"_extension":18},"/en-us/blog/collaboration-techniques-for-distributed-teams",{"title":1398,"description":1399,"ogTitle":1398,"ogDescription":1399,"noIndex":6,"ogImage":1400,"ogUrl":1401,"ogSiteName":685,"ogType":686,"canonicalUrls":1401,"schema":1402},"Synchronous collaboration for async distributed teams","The strategic exercise supported meaningful reflection as well as alignment in setting goals.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682962/Blog/Hero%20Images/collaboration-techniques-blog-post.jpg","https://about.gitlab.com/blog/collaboration-techniques-for-distributed-teams","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n \"datePublished\": \"2022-01-19\",\n }",{"title":1404,"description":1399,"authors":1405,"heroImage":1400,"date":1407,"body":1408,"category":693,"tags":1409},"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously",[1406],"Amelia Bauerly","2022-01-19","\nIn a remote, asynchronous company, is there ever a time when teams need to collaborate synchronously?\n\nWe recently asked ourselves that question on the Monitor team. It had been three years since we started thinking about how to build out Incident Management as a team, and a lot had happened in that time. We’d built out a range of new features and created the broad outlines for a complete incident management workflow with GitLab. We’d achieved a lot.\n\nWe had also been through a number of changes as a team, and we had several possible paths ahead of us. It felt like an appropriate moment to step back and take stock of where we’ve been, what we’ve done, and where we still need to go. However, given our team's geographical distribution, we realized we needed to think creatively about how best to create space for reflection as a team.\n\n## Opting for a Lightning Decision Jam\n\nOutside of regularly scheduled team meetings, our team adheres to the standard GitLab practice of prioritizing [asynchronous communication](https://handbook.gitlab.com/handbook/communication/asynchronous-communication). Because our team is distributed around the world, this model usually works great for us. But, given the amount of time that had passed since we had all gathered together, this time around, we decided it might actually be nice to gather synchronously.\n\nOwing to the time zone differences we'd face, we wouldn’t have a lot of time together. We needed to find a structure that would allow us to do some reflection as a team in a limited amount of time.\n\nEnter: [Lightning Decision Jam](https://uxplanet.org/lightning-decision-jam-a-workshop-to-solve-any-problem-65bb42af41dc).\n\nA Lightning Decision Jam (LDJ) is a quick way for teams to come together to collaboratively identify problems and challenges, and then work together to ideate on solutions for those challenges – all in one hour. This format would give us space to check in with each other as a team about the work that we’ve been doing, while keeping those discussions constrained in a way that would (hopefully) respect the fact we’d all be gathering at different times in our days.\n\n## How the LDJ worked?\n\nWe hosted the session on [Zoom](https://zoom.us), and a majority of our team members were able to join the call synchronously. We met with the team members unable to join prior to the main LDJ session so they could participate as well. We also recorded the session so they could review the larger discussion afterward. We used [Mural](https://www.mural.co/) to collaborate during the session.\n\nThe session itself involved a series of time-boxed, individual brainstorming exercises, where each team member generated sticky notes in response to a prompt. Some of the brainstorming exercises included questions like:\n\n- What is moving us forward?\n- What’s gone well?\n- What are the challenges that are holding us back?\n- How might we address those challenges?\n\nAfter each person generated their sticky notes, the ideas were shared with the group. After all the ideas were shared, we used [dot voting](https://www.nngroup.com/articles/dot-voting/) to surface the ideas that had the most traction within the group.\n\n## What the LDJ taught us\n\nThere were a few things we observed as we conducted this exercise as a team.\n\nAt GitLab, we work in a monthly cadence. We have a large backlog of features to implement, and an ever-growing list of things to improve. All of these factors, taken together, can make it easy to focus on the things that aren’t yet where we'd like them to be, or that still need to be done.\n\nThat being the case, simply taking some time to reflect on what we’ve done well was a worthwhile exercise. Holistically thinking about what we’ve built over the past few years and taking a moment to pause and celebrate the things that we’d achieved as a team was a beneficial thing for us to do together.\n\nSpending time thinking about the main challenges we face as we move forward was also a useful exercise. Importantly, though, we didn't just focus on the challenges; we also spent time ideating on solutions and voting together, as a team, on which solutions seemed the most meaningful to action. These additional steps helped us to re-align and re-focus on the path ahead.\n\nOf course, we could have done some reflection on these topics outside of an in-person, synchronous session. The benefit of doing this as part of the LDJ was that we all got to spend some time together as a team, brainstorming and collaborating in real-time. Especially now, due to the global circumstances and the pandemic more generally, being able to see, hear, and spend time with each other has a certain intrinsic value, especially in terms of team cohesion. Furthermore, the strict structures of the LDJ meant that we could spend some time discussing these topics in a focused way. While we didn’t get to discuss everything as thoroughly as we would have liked, it at least gave us space and the opportunity to start the conversation.\n\n## What’s next?\n\nThe result of the LDJ was a set of GitLab issues that outline the opportunities we identified. These issues already have ideas attached to them that have been vetted by the team, so they are immediately actionable. The hope is that we can start experimenting with the ideas we've generated in upcoming milestones, and that these ideas will help us address our larger goal of increasing the number of people using our features.\n\nWe also conducted an asynchronous [plus-delta exercise](https://www.lucidmeetings.com/glossary/plus-delta) to identify opportunities for improving similar sessions in the future. In particular, there was interest in conducting the entire LDJ asynchronously, so everyone can participate at their leisure, perhaps having team members spend 5-10 minutes on five consecutive days to complete all of the exercises independently. This may also give people the room to reflect on the questions more deeply than we can do in a live, in-person session.\n\nMy hope, though, is that this is just the first of these kinds of collaborative workshops that we can do as a team. Experimenting with different ways of thinking about problems, and different ways of interacting, should help keep us feeling aligned and engaged with the path ahead. It also gives everyone a chance to have a voice in what we do, which, for me, may well be the most important thing.\n\nCover image by [MaxBender](https://unsplash.com/photos/iF5odYWB_nQ) on [Unsplash](https://unsplash.com)\n",[1096,9,1097],{"slug":1411,"featured":6,"template":698},"collaboration-techniques-for-distributed-teams","content:en-us:blog:collaboration-techniques-for-distributed-teams.yml","Collaboration Techniques For Distributed Teams","en-us/blog/collaboration-techniques-for-distributed-teams.yml","en-us/blog/collaboration-techniques-for-distributed-teams",{"_path":1417,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1418,"content":1424,"config":1431,"_id":1433,"_type":13,"title":1434,"_source":15,"_file":1435,"_stem":1436,"_extension":18},"/en-us/blog/collaborative-course-environment-gitlab-grav",{"title":1419,"description":1420,"ogTitle":1419,"ogDescription":1420,"noIndex":6,"ogImage":1421,"ogUrl":1422,"ogSiteName":685,"ogType":686,"canonicalUrls":1422,"schema":1423},"Creating open course environments with GitLab and Grav CMS","Guest author Paul Hibbitts shares how he combines GitLab with the flat-file CMS Grav to provide an open, collaborative and flexible environment that partners with his institution's LMS.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678561/Blog/Hero%20Images/open-course-environment.jpg","https://about.gitlab.com/blog/collaborative-course-environment-gitlab-grav","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Enabling an open and collaborative course environment with GitLab and the Grav CMS\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Paul Hibbitts\"}],\n \"datePublished\": \"2017-10-12\",\n }",{"title":1425,"description":1420,"authors":1426,"heroImage":1421,"date":1428,"body":1429,"category":784,"tags":1430},"Enabling an open and collaborative course environment with GitLab and the Grav CMS",[1427],"Paul Hibbitts","2017-10-12","\n\nTech-savvy educators! Do you want to:\n\n- Share your course materials more openly?\n- Support collaborative editing by students and fellow educators?\n- Deliver a better multi-device experience of your course materials?\n- Be able to update your online course materials in as little as 30 seconds?\n- And, in general, move beyond the constraints of your current Learning Management System?\n\n\u003C!-- more -->\n\nIf this sounds like you, then the combination of an institutionally hosted instance of [GitLab]() and a modern flat-file (no database) Content Management System such as [Grav](https://getgrav.org/) might be your answer!\n\nAs an educator and software interaction designer, I am always striving to deliver a better experience for my students, both in person and online. In the past several years this has led me to ‘flipping’ the Learning Management System, where I use an alternative platform instead of the LMS as the primary online environment. Many instructors (including myself) have taken this approach in the past using a traditional platform such as WordPress, but I found significant new benefits from partnering the LMS with a more modern platform that was built to take full advantage of the open and collaborative ecosystem (i.e. Git, GitLab, GitHub, etc.) we now have.\n\nWith the above approach, direct links are provided to any appropriate LMS elements and sensitive student data remains in the LMS. Common elements across multiple courses, like calendars, assignments, discussion forums, and grades are still stored in the LMS for single-point access by students. While perhaps not suited for university-wide adoption, this is a very viable and productive approach for individual instructors and their students while we wait for more open and adaptable institutional-level tools to become available.\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course1.png\" alt=\"Open and Collaborative Flipped LMS Approach Using GitLab and the Grav CMS\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>Open and Collaborative ‘Flipped’ LMS Approach Using GitLab and the Grav CMS\u003C/small>*\n\nFortunately, my university ([Simon Fraser University](http://www.sfu.ca/), or SFU, in Burnaby, BC, Canada) also provides an institutionally hosted instance of GitLab which not only gives me an ideal workspace for my online course materials, but also supports single sign-on so my students can easily contribute to these materials as well. By combining GitLab with the modern flat-file CMS Grav, my institution's LMS and a small collection of other open source web apps, I’ve been able to reach more of my desired teaching goals (such as providing an anytime, anywhere performance support tool with real-time chat) for my own courses than by using the LMS as the primary online space. In addition, I’ve made the resulting software open source to also help other instructors reach their own goals – more about this project at the end of this article!\n\n## Why open source software?\n\nThe advantages of using open source software in the field of education are well documented elsewhere (see [Open Source Software in Education](http://er.educause.edu/articles/2008/5/open-source-software-in-education)), but from my own viewpoint, the things I value most are: having more control over the software I use, the online communities often found with open software projects, public communication with the team developing the software, and the wide range of ways I can contribute to projects. I’ve also been keenly following several other open source, institutional-level learning ecosystem efforts, such as [ELMSLN](https://www.elmsln.org/) (a platform for building and sustaining innovation in course technologies) and [TSUGI](https://www.tsugi.org/) (a framework for building learning tools).\n\n## Why GitLab?\n\nGitLab meets several key criteria for its use in a learning ecosystem. First, it is open source software itself and secondly, it is possible to install an instance of GitLab on your own server. For universities and colleges this enhances the benefits of being open source in the first place as single sign-on and the storage of sensitive student data remains in the sole control of the institution.\n\nUsing GitLab in combination with the [GitHub Desktop application](https://desktop.github.com/) I can also very quickly update my online course sites from my desktop, while at the same time being able to then edit course site materials with any code editor I like. Most importantly, students feel like active course participants when they see they are welcome to suggest changes to the course site, or even just to make corrections to course materials. Everything is of course version controlled, which means as a repository administrator I can easily see each and every change before approving them. For changes not immediately approved I can then start a discussion via GitLab with the author of the proposed change to work out any needed further changes, etc. GitLab brings an industrial-strength software and document collaboration tool into the reach of my fellow university colleagues and students.\n\n## Why Grav CMS?\n\nWhile looking for an open source platform to support a learning ecosystem I evaluated multiple options, including self-hosting (for full administrative control) WordPress, Concrete5, Moodle and others. I then came across a number of apps under the category of ‘flat-file CMS,’ meaning that content was stored in files instead of a database. I could see that content as files would be a perfect partner for using a web-based Git service (such as GitLab, [GitHub](https://www.github.com/), [GitBook](https://www.gitbook.com/), etc.) to share and collaboratively edit content. With such a partnership, CMS content can be automatically backed up in a straightforward manner, while also tracking all revisions along the way. Digging deeper, I discovered the open source flat-file CMS Grav (by the team behind [RocketTheme](http://www.rockettheme.com/)) used Markdown – the native format for Web-based Git services such as GitLab – for content. Markdown is also an excellent system-independent format to support the ‘5Rs’ of Open Education Resources (Retain, Reuse, Revise, Remix, and Redistribute).\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course2.png\" alt=\"Editing Markdown content in the Grav CMS Admin Panel\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>Editing Markdown content in the Grav CMS Admin Panel\u003C/small>*\n\nGrav uses many existing modern standards and open source components, such as the very user-friendly [Twig language](https://twig.symfony.com/) (courtesy of Symfony) instead of pure PHP for theme templating. Grav also supports modular and custom content types, and was designed from the ground-up to be both fast and extensible. In addition, with the creation of the open source Git Sync plugin (by [Trilby Media](https://trilby.media/)) it is now easier than ever to do two-way syncing of Grav content between a production server, Git repository and an optional local development instance. It is even possible to sync theme files, which determine the actual functionality and presentation of a site, so educators (or perhaps their tech-savvy students) can directly help other educators needing assistance in additional customization of their Grav sites.\n\nIt should be noted that Grav is not a static site generator, but rather a file-based CMS which supports not only dynamic content but also an online Admin Panel.\n\n## CMPT-363 Open Course Hub\n\nFor my SFU course CMPT-363 User Interface Design this Fall, I will not only be using GitLab and Grav (hosted on the educationally focused [Reclaim Hosting](https://reclaimhosting.com/)), but also a number of other web apps (also mostly open source) to provide a learning ecosystem to my students. Since Grav itself is open and extensible, I can easily add in Javascript elements for a Livechat (which my students have told me they love) thanks to [Rocket.Chat](https://rocket.chat/), responsive Markdown-based slide embeds thanks to the commercial [Swipe.to](https://www.swipe.to/home) web app, and links to an anonymous course feedback form thanks to [Sandstorm.IO](https://sandstorm.io/) and [Quick Survey](https://github.com/simonv3/quick-survey). To address both various other teaching goals (the LMS actually does some things quite reasonably) and student data privacy concerns, I still use the institutional LMS [Canvas](https://www.canvaslms.com/) by Instructure to support a wide range of course elements such as quizzes, assignment submissions, discussion forums, and gradebook. You can see this multi-device friendly Course Hub in action at [paulhibbitts.net/cmpt-363-173/](http://paulhibbitts.net/cmpt-363-173/).\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course3.png\" alt=\"CMPT-363 Open Course Hub Learning Ecosystem\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>CMPT-363 Open Course Hub Learning Ecosystem\u003C/small>*\n\n## The Open Course Hub Project\n\nBased on the [very positive student feedback](https://storify.com/paulhibbitts/flipped-lms) and my own experiences with the 2015 CMPT-363 Course Hub, I decided to release an open source version of a pre-packaged Course Hub with Git Sync the following year (called a Skeleton in Grav-speak, which is a ready-to-run package that includes Grav and all needed theme and example content files). While this package can be installed in [less than a minute](https://www.youtube.com/watch?v=8yyE-LaAa8Y) and fully configured in [under five minutes](https://www.youtube.com/watch?v=jnBig4aGfFg) it is intended for fellow tech-savvy educators to use and further customize as they see fit.\n\n\u003Cimg src=\"/images/blogimages/gitlab-grav-open-course4.png\" alt=\"CMPT-363 Open Course Hub Web Page\" style=\"width: 500px;\"/>{: .shadow}\n\n*\u003Csmall>CMPT-363 Open Course Hub Web Page\u003C/small>*\n\nWhat are the exact skills currently expected? In general, you should be comfortable with accessing files on a website server, understand folder hierarchies, be familiar with Markdown (here is a [10-minute Markdown tutorial](https://designedbywaldo.com/en/tools/markdown-tutorial)), and have a working knowledge of using GitLab or GitHub. Being able to use [GitHub Desktop](https://desktop.github.com/) and a desktop code editor like [Atom.io](https://atom.io/) or [Adobe Brackets](http://brackets.io/) will also bring the ability to store a copy of your Grav site content on your local desktop and then selectively edit and push changes back to the Git repository for deployment to your live Grav Course Hub site. Step-by-step install and configuration instructions for the Grav Course Hub are available at [learn.hibbittsdesign.org/coursehub](http://learn.hibbittsdesign.org/coursehub).\n\nThis is also my way to give back to the open source community in general, which has been so helpful in the development of my own original CMPT-363 Course Hub. Using Grav and the Git Sync plugin I’ve released several additional Open Education Resources (OER) projects, including the Open Publishing Space, and all of these are available at [learn.hibbittsdesign.org](http://learn.hibbittsdesign.org/).\n\nQuestions or comments about using GitLab as an open and collaborative backbone to your learning ecosystem? Please feel free to contact me via email ([paul@hibbittsdesign.org](mailto:paul@hibbittsdesign.org)) or Twitter [@hibbittsdesign](https://twitter.com/hibbittsdesign). You can also read more about my learning ecosystem explorations at [hibbittsdesign.org/blog](http://www.hibbittsdesign.org/blog/).\n\n*Special thanks to the folks at GitLab for the kind offer to provide this guest blog post, and everyone from the Grav community and my Twitter network who provided helpful feedback and comments on the draft versions of this post!*\n\n### About the guest author\n\nPaul Hibbitts has been an interaction design practitioner and educator for over 20 years, and has recently ventured into the world of open source software development thanks to the amazing Grav CMS.\n\n\n[Cover image](https://unsplash.com/photos/Y94yKEyNjVw) by [chuttersnap](https://unsplash.com/@chuttersnap) on unsplash\n{: .note}\n",[787,9],{"slug":1432,"featured":6,"template":698},"collaborative-course-environment-gitlab-grav","content:en-us:blog:collaborative-course-environment-gitlab-grav.yml","Collaborative Course Environment Gitlab Grav","en-us/blog/collaborative-course-environment-gitlab-grav.yml","en-us/blog/collaborative-course-environment-gitlab-grav",{"_path":1438,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1439,"content":1445,"config":1451,"_id":1453,"_type":13,"title":1454,"_source":15,"_file":1455,"_stem":1456,"_extension":18},"/en-us/blog/comment-on-commits-feature-tutorial",{"title":1440,"description":1441,"ogTitle":1440,"ogDescription":1441,"noIndex":6,"ogImage":1442,"ogUrl":1443,"ogSiteName":685,"ogType":686,"canonicalUrls":1443,"schema":1444},"Demo: How to use Merge Request Commit Discussions","You can now hold discussions on specific commits within a merge request – check out how it works in this video.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680285/Blog/Hero%20Images/merge-request-commit-discussions.jpg","https://about.gitlab.com/blog/comment-on-commits-feature-tutorial","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Demo: How to use Merge Request Commit Discussions\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n \"datePublished\": \"2018-01-04\",\n }",{"title":1440,"description":1441,"authors":1446,"heroImage":1442,"date":1448,"body":1449,"category":1053,"tags":1450},[1447],"Victor Wu","2018-01-04","\n\nIn [GitLab 10.3](/releases/2017/12/22/gitlab-10-3-released/) we released a new feature: [Merge Request Commit Discussions](/releases/2017/12/22/gitlab-10-3-released/#merge-request-commit-discussions). This is great news for teams who work at the individual commit level, who want to be able to discuss and collaborate on different commits within one merge request. Watch the video below to see this new workflow in action.\n\n\u003C!-- more -->\n\nIn short: this feature (available in both GitLab [Community and Enterprise Editions](/stages-devops-lifecycle/)) allows you to add comments to [commits within a merge request](/solutions/continuous-integration/). Before you could only add comments to a particular version of a merge request. In the video, you'll see how now when you navigate to a specific commit, you're taken to the \"Changes\" tab, but instead of viewing the latest version, you see the diff associated with that commit.\n\nYou can then leave a comment inline as you would usually, the difference being that your comment now starts a conversation relating specifically to that commit.\n\nIf you leave a comment on another commit, that begins a separate discussion as well. All are accessible from the \"Commits\" tab or the Discussions\" tab. You can resolve discussions as usual, with resolved discussions being collapsed by default, similar to before.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/TviJH6oRboo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nWe hope teams who need a more granular approach to approving merge requests will find this useful! As usual, we welcome your feedback – be it on the [release blog post](/releases/2017/12/22/gitlab-10-3-released/) or by opening an issue.\n\n[Cover image](https://unsplash.com/photos/qm3nnbaBl_4) by [Matthew Brodeur](https://unsplash.com/@mrbrodeur) on Unsplash\n{: .note}\n",[829,9],{"slug":1452,"featured":6,"template":698},"comment-on-commits-feature-tutorial","content:en-us:blog:comment-on-commits-feature-tutorial.yml","Comment On Commits Feature Tutorial","en-us/blog/comment-on-commits-feature-tutorial.yml","en-us/blog/comment-on-commits-feature-tutorial",{"_path":1458,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1459,"content":1465,"config":1470,"_id":1472,"_type":13,"title":1473,"_source":15,"_file":1474,"_stem":1475,"_extension":18},"/en-us/blog/community-update-for-2019",{"title":1460,"description":1461,"ogTitle":1460,"ogDescription":1461,"noIndex":6,"ogImage":1462,"ogUrl":1463,"ogSiteName":685,"ogType":686,"canonicalUrls":1463,"schema":1464},"Celebrating wider community contributions in 2019 and returning to FOSDEM","Here's what the wider community accomplished in 2019 and where to find GitLab at FOSDEM'20.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663430/Blog/Hero%20Images/2018-09-13-gitlab-hackathon-cover.jpg","https://about.gitlab.com/blog/community-update-for-2019","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Celebrating wider community contributions in 2019 and returning to FOSDEM\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2020-01-24\",\n }",{"title":1460,"description":1461,"authors":1466,"heroImage":1462,"date":1467,"body":1468,"category":716,"tags":1469},[1281],"2020-01-24","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nFirst of all, I would like to wish everyone in the GitLab Community a Happy New Year! There's been an impressive growth in the wider GitLab community in 2019 and I wanted to share and celebrate what we all accomplished. \n\nThe first chart below shows merged MRs from the wider community beginning with the 11.0 release. We obviously have a nice trendline, but we also had a record number of merged MRs for the 12.6 release (nearly 250!) and this was a great way to close out 2019! \n\n![Wider community contributions per release](https://about.gitlab.com/images/blogimages/Wider_community_contributions_per_release-Dec2019.png){: .medium.center}\n\nI also want to show some numbers on the wider community growth over the past 3 years. As you will see in the chart below, the number of contributors almost doubled between 2018 and 2019 as we had almost 900 contributors with merged MRs last year. In terms of the number of merged MRs, we had 2400+ MRs in 2019 which is more than 30% increase from the previous year. I really need to congratulate and thank everyone in the wider community for your contributions as these numbers clearly show that GitLab is a thriving open source community. Beyond MRs or code, we appreciate your insight and perspective from your contributions. \n\n![Community contributions in 2018 and 2019](https://about.gitlab.com/images/blogimages/2019_Wider_Community_Contributors_and_Merge_Requests.png){: .medium.center}\n\nI also updated the [top contributors page](https://about.gitlab.com/community/top-annual-contributors/) with the final numbers from 2019. The number of regular contributors with 5 or more merged MRs during the year also saw a significant increase from 2018 (35) to 2019 (68). The growth in regular contributors is something we tried to focus on last year, and I'm impressed with the result. Congratulations to everyone who made the list, and your GitLab souvenir will be coming to you soon.\n\n\n### Let's meet at FOSDEM\n\nNow I want to switch gears to what's happening at [FOSDEM](https://fosdem.org/2020/) on February 1st and 2nd. Last year, GitLab had a stand at FOSDEM for the first time and we were overwhelemed with the amount of people who came to talk to us. I'm excited to announce that we will be back with a stand at FOSDEM and look forward to meeting with community members. Our stand will be at Building K/Level 1 and [this page](https://fosdem.org/2020/stands/) will help you find where the GitLab stand is. \n\nWe will also have a meetup session on Sunday as a part of a Birds of a Feather (BOF) track on Sunday (February 2nd) morning between 10:00 - 11:00 in room J.1.106. You can find details on the meetup at [this FOSDEM page](https://fosdem.org/2020/schedule/event/bof_gitlab/). \n\nIn addition, a couple of GitLab team members are giving talks in devrooms. [Alessio Caiazza](https://gitlab.com/nolith) will discuss [building a smart reverse proxy in Go](https://fosdem.org/2020/schedule/event/speedupmonolith/) and I will have the opportunity to discuss [why community matters in corporate open source projects](https://fosdem.org/2020/schedule/event/corpcommunitythrive/). \n\nFinally, we are working on organizing a Happy Hour on Saturday (February 1st) evening, so stay tuned for more news on this! I hope to see many of you at FOSDEM, and I'll try to make frequent announcements/posts on Twitter during the conference.\n",[268,9,787],{"slug":1471,"featured":6,"template":698},"community-update-for-2019","content:en-us:blog:community-update-for-2019.yml","Community Update For 2019","en-us/blog/community-update-for-2019.yml","en-us/blog/community-update-for-2019",{"_path":1477,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1478,"content":1484,"config":1491,"_id":1493,"_type":13,"title":1494,"_source":15,"_file":1495,"_stem":1496,"_extension":18},"/en-us/blog/configure-post",{"title":1479,"description":1480,"ogTitle":1479,"ogDescription":1480,"noIndex":6,"ogImage":1481,"ogUrl":1482,"ogSiteName":685,"ogType":686,"canonicalUrls":1482,"schema":1483},"GitLab restructures to boost cross-functional collaboration","Implementing a new structure sounds like a big change, but our Configure group is here to give you the scoop.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678839/Blog/Hero%20Images/inside-look-at-new-cross-functional-teams-at-gitlab.jpg","https://about.gitlab.com/blog/configure-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"We restructured to allow better cross-functional collaboration — here's how it's going.\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n \"datePublished\": \"2018-12-13\",\n }",{"title":1485,"description":1480,"authors":1486,"heroImage":1481,"date":1488,"body":1489,"category":1053,"tags":1490},"We restructured to allow better cross-functional collaboration — here's how it's going.",[1487],"Emily von Hoffmann","2018-12-13","\nHello world, meet the GitLab Configure group! They’re the folks hard at work improving [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), the [Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/), and all the related applications on GitLab. They, like the rest of the GitLab engineering function, recently changed how they work together when we split up into devops stage groups according to [product area](https://handbook.gitlab.com/handbook/product/categories/). Each group contains a product manager, UX designer, several engineers, and other contributors. They still belong to [teams](/company/team/structure/#team-and-team-members) with others usually in their same role, but they work together as a [group dedicated to a stage](/company/team/structure/#stage-groups) of the product lifecycle.\n\n![meet the configure group](https://about.gitlab.com/images/blogimages/configure-team.jpg){: .shadow.medium.center}\n\nSo far, Configure group members say this has helped them stay focused and connected. Staff UX Designer Taurie Davis explains that while she used to have to switch gears and spend time getting caught up on different product areas, she can now hone in on finding solutions to familiar problems. Having a stable group of collaborators also promotes shared learning, because they’re working together on the same issues at the same time. Product Manager Daniel Gruesso also sees benefits in having a dedicated set of people for each product area; they enjoy more latitude and no longer face as much competition for getting their work prioritized. These are all benefits of [stable counterparts](/handbook/leadership/#stable-counterparts), or people in different functions, departments, or teams who routinely work together, easing communication to avoid conflict and the [downsides of a matrix organization](/handbook/leadership/#no-matrix-organization).\n\nSome of the challenges that drove this change have been echoed in our user research, with cross-group communication a common and recurring roadblock. In our [2018 Global Developer Report](/developer-survey/previous/2018/), a quarter of engineers indicated that they feel siloed, and lack visibility into what their colleagues in operations, product, and security are working on.\n\nThis was reinforced in recent interviews by our UX research team, where many [developers](https://drive.google.com/file/d/1EVrjVcgIBbuNf4Gwenajsiy6Wv9HsTJw/view) we spoke with said that they’re frustrated by changing requirements and scope creep, and pinpointed poor communication with and empathy for other teams as the cause. Their colleagues in [operations roles](https://drive.google.com/file/d/1A5mSNoPJydjcWKE4rdO2287sjnABxGDA/view) face a similar challenge in convincing others to invest cycles in proactive work that can save them time and stress in the future. Although implementing stable groups may seem like a big change, we’ve seen positive results and hope that sharing our experience may help others take the plunge.\n\nI recently caught up with a few members of the Configure group, read on for their perspectives on how it’s been going.\n\n### Can you each introduce yourself and explain your role?\n\n**Dylan:** Hi I'm [Dylan](/company/team/#DylanGriffith). I'm the [Backend Engineering Manager](https://handbook.gitlab.com/job-families/engineering/backend-engineer/#engineering-manager/) for the [Configure](https://handbook.gitlab.com/handbook/product/categories/) group.\n\n**Thong:** I’m new here! I’m [Thong](/company/team/#thongkuah) and I'm a senior [backend engineer](https://handbook.gitlab.com/job-families/engineering/backend-engineer/).\n\n**Mayra:** I'm [Mayra](/company/team/#may_cabrera) and I'm a [backend engineer](https://handbook.gitlab.com/job-families/engineering/backend-engineer/) for the Configure group.\n\n**Taurie:** I'm [Taurie](/company/team/#tauried), the UX designer for the Configure group. I work closely with product and engineering to help shape the overall user experience of our products.\n\n**Daniel:** I'm [Daniel](/company/team/#danielgruesso), the [Product Manager](https://handbook.gitlab.com/job-families/product/product-manager/) for the Configure group. In short I have to make sure that the features we ship are aligned to our vision; this involves interacting with everyone from customers to the CEO. Working together with engineering, UX, and leadership we make our vision a reality.\n\n### In general, how do you think it's going so far?\n\n**Dylan:** So far the stable devops stage group is working well. I believe that backend teams already were well focused on specific product areas, but I think the addition of focused UX and frontend engineers on our product area helps in a few ways. First, we know who to talk to about UX decisions, and the UX designer and frontend engineers have good context across the feature set and often have good insights based on this context. Backend engineers also get to collaborate and form better working relationships with UX and frontend, and as a consequence we communicate more effectively in general.\n\n### What are some of the big differences that arise from working with people in different roles, versus working more with people who share your background?\n\n**Thong:** Key for me is the different strengths and perspectives that we all bring into the group. I'm pleasantly surprised how well our strengths overlap and support the group. Because we come from different perspectives, I feel we can often challenge each other constructively and check that we are heading in the right direction with respect to achieving the best value for the product.\nThe challenges I have seen in the past would be establishing a common understanding of the group's goals, which sometimes might not be exactly aligned with each department's goals.\n\n**Mayra:** Thong’s answer is a really good one. I'm also quite impressed by how our strengths bolster the group productivity.\n\n**Taurie:** We bring different perspectives to the table which can only improve the product in the end. It also greatly improves communication and allows us to work together instead of in progression. I, personally, have also learned a ton by working so closely with both product and engineering on a daily basis.\n\n**Daniel:** I greatly benefit from learning the technical aspects of our work; if I only interacted with other product folks I would surely not learn as much. This is by far the job where I've learned the most in the shortest amount of time. I love that.\n\n### How has the new structure impacted your day to day?\n\n**Mayra:** For me, it has had a positive impact because now I'm focused on developing particular features for certain areas of GitLab, like the Kubernetes integration and Auto DevOps.\n\n**Dylan:** We have deeper conversations with UX designers and frontend engineers as they understand our product set well. Ownership from the UX designer means that as an engineer I feel less stressed about resolving UX decisions or making issues for UX issues, as I can see that Taurie will often take responsibility for seeing this through.\n\n### How have you tried to bond as a new group?\n\n**Dylan:** We are bonding quite well. We started with daily standups and worked our way down to twice weekly. The daily standup really accelerated the bonding between group members and has resulted in fairly healthy collaboration and high levels of trust between group members. We've also done 1 retro as a full group, which I believe was a more comfortable and open environment as a consequence of us bonding for some time before hand.\n\n**Mayra:** At the last GitLab [Summit](/events/gitlab-contribute/), we had our first on site dinner; sadly, Thong was not able to join us, so we'll need to update this picture on the next summit!\n\n![team dinner](https://about.gitlab.com/images/blogimages/configure-team-dinner.png){: .shadow.medium.center}\n\n**Taurie:** We also have [coffee break calls](/culture/all-remote/#coffee-break-calls) regularly with different group members as a way to discuss things outside of work and continue to strengthen the connection between group members. Our monthly group retrospectives are a great way to discuss what is working well within our group, what has been on our minds, and what we can improve for greater collaborations and results.\n\n**Daniel:** I always try to start calls with a personal touch, no matter how small, I've found it sets people at ease. We plan synchronously and clear up any doubts on the work before starting. Once we're aligned we mostly catch up asynchronously.\n\n### Are there any previous problems, delays, or frustrations that have been resolved or prevented in the new structure?\n\n**Dylan:** Difficult to say, but at a high level we had many discussions before forming this group along the lines of engineers waiting for issues to be labeled \"UX Ready\" before starting work on any feature. But now as a group we've come to realize that we're all involved from the beginning to the end, and engineers are responsible for ensuring the UX makes sense and the UX designer is also responsible for ensuring the final product makes sense. We also regularly have UI contributions from Taurie which saves the round trip of commenting on the MR and waiting for the engineer to make the changes.\n\n**Taurie:** Shifting between multiple different product areas made it much more difficult to learn and keep up to date with the more technical areas of our product such as Kubernetes, and Auto DevOps. Being integrated into a group who is constantly working on these features means I have more domain knowledge and can more confidently answer questions related to the user experience of our area.\n\n### What are you most excited to tackle together, and what can we look forward to seeing from the group?\n\n**Dylan:**\nWe're focusing on making Auto DevOps clearer to users; making more decisions based on research rather than relying on industry trends; building a large and engaged user base for Auto DevOps that helps guide us to make better decisions by collaborating on issues; and improving the code architecture so that frontend engineers are more empowered to build better UX without the need to involve backend engineers (eg. more user experience handled in pure frontend Javascript code).\n\n**Taurie:** I am excited to see the group continue to grow and tackle issues that improve the Auto DevOps experience so that it is widely used among GitLab users.\n\n**Daniel:** I am definitely excited to participate in some of our big initiatives like [serverless](/topics/serverless/) and PaaS. In the near future you can look forward to group-level Kubernetes clusters as well as some great Auto DevOps improvements like the ability to initialize and migrate databases.\n\n### Anything else you want to share?\n\n**Daniel:** We're always looking for [engineers](/jobs/). Familiarity with Kubernetes and expertise with ruby will help you land an interview.\n\n**Dylan:** Try out [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) and don't be afraid to create issues for us if you run into trouble. We love hearing from our users!\n\nCover image by [rawpixel](https://unsplash.com/@rawpixel) on [Unsplash](https://unsplash.com/).\n{: .note}\n",[829,9],{"slug":1492,"featured":6,"template":698},"configure-post","content:en-us:blog:configure-post.yml","Configure Post","en-us/blog/configure-post.yml","en-us/blog/configure-post",{"_path":1498,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1499,"content":1505,"config":1512,"_id":1514,"_type":13,"title":1515,"_source":15,"_file":1516,"_stem":1517,"_extension":18},"/en-us/blog/contributing-to-gitlab-with-ease",{"title":1500,"description":1501,"ogTitle":1500,"ogDescription":1501,"noIndex":6,"ogImage":1502,"ogUrl":1503,"ogSiteName":685,"ogType":686,"canonicalUrls":1503,"schema":1504},"Contributing to GitLab with ease","Everyone can contribute to GitLab, so here are a few tips to make your experience easy and pleasant.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678997/Blog/Hero%20Images/mergerequestsgame.jpg","https://about.gitlab.com/blog/contributing-to-gitlab-with-ease","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Contributing to GitLab with ease\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lin Jen-Shin\"}],\n \"datePublished\": \"2018-08-23\",\n }",{"title":1500,"description":1501,"authors":1506,"heroImage":1502,"date":1508,"body":1509,"category":784,"tags":1510},[1507],"Lin Jen-Shin","2018-08-23","\nAs a [Merge Request Coach](https://handbook.gitlab.com/job-families/expert/merge-request-coach/), I am happy to\nhelp community contributors feel comfortable when contributing\nto GitLab. During my time reviewing merge requests, I’ve learned a bit about\nhow it feels contributing to GitLab as a newcomer, and I’d like to share\nmy learnings with you.\n\n## Common issues in an MR (merge request)\n\nIn the past, I think styling might have been one of the most common issues.\nHowever, we’re improving our CI to run more static analysis, so these issues\nare now automatically pointed out. Today, contributors can easily see what\ndidn’t pass CI, and they can fix the issues very quickly, so this is not as\ncommon as it was in the past.\n\nThe biggest issue today might be that many contributors don’t add tests, since\ntests often require much more effort than fixing or adding something. If\nyou’re struggling with adding tests, please don’t worry. Merge request coaches\ncan tell you how to add tests when we see your contribution, and we’ll work\nthrough it together.\n\n## Best practices\n\n1. If you only remember one best practice, I hope it is to keep this\nreference handy when [contributing to GitLab](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/index.md).\nI know it’s super long, but it has all the information you need when it comes\nto making contributions to GitLab.\n\n2. Get [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit) set up\nlocally if you haven’t already. Running tests locally is the best way to\ndevelop and debug, and I highly encourage that you incorporate this into your\nworkflow.\n\n3. Don’t ignore CI. If your pipeline didn’t pass, it’s important to go back and\nidentify the problem. Troubleshooting issues is a great way to practice your\nskills and help you learn from mistakes.\n\n4. Look at the [GitLab team page](/company/team/) and pick a merge request coach to\nping if you need help. Merge request coaches guide contributors and will even\njump in to help finish an MR if a contributor can no longer work on it,\nensuring that the attribution stays with the original contributor. Our goal is\nto help everyone feel comfortable and empowered to contribute even with\nsmallest possible effort. Coaches have other responsibilities and don’t always\nproactively look for contributors who need help, so ping them if you’re stuck\nor ready for a review. If they’re not the right person to ping, they’ll pass\nyou over to the right one. We love helping community contributors, and we look\nforward to guiding and working with you.\n\n## Little-known features\n\nWe [recently welcomed](/blog/introducing-gitlab-s-integrated-development-environment/)\nWeb IDE to quickly edit multiple files on the web directly without cloning\nthe whole repository. Web IDE is useful if you just want to make some small\nchanges online. If you’d like to learn more about Web IDE, please\nhead over to our [documentation](https://docs.gitlab.com/ee/user/project/web_ide/).\n\nSince GitLab's development velocity is pretty high, sometimes conflicts can\nhappen very frequently. Did you know that you can resolve conflicts directly\nfrom the web UI? I really love this feature, because it’s very easy to resolve\nsimple conflicts, and I don’t need to launch my editor or Git to pull, merge,\nand push. With some simple clicks, I can save a lot of time for simple\nconflicts.\n\n## What everyone should know about MRs\n\nTo me, an MR is a tool to interactively develop and explore with other people.\nDon’t worry about being perfect in the first version of your MR. We learn\nthrough our mistakes and get better over time.\n\nIf you’ve made tons of contributions, we invite you to join our\n[core team](/community/core-team/) or apply for a [full-time position](/jobs/) at GitLab.\nThe MR is one of the most important ways we work together, and we’d love to\ncollaborate with you.\n\n## What to do if you’re struggling\n\nIf you’re having some trouble getting the hang of merge requests, I suggest\ntaking a look at how others work on the MRs. Following other people’s example\ncan help you understand what they did and why they did it. Reaching out to a\nmerge request coach, joining discussions, and reviewing others’ code are also\nways to help you get up to speed. I think that interacting with others is a\ngreat way to learn and improve.\n\n## We’d love your contributions!\n\nWe really enjoy collaborating with community contributors, and we look forward\nto working together. If you don't know what you can contribute, please take a\nlook at [`Accepting merge requests`](https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name[]=Accepting+merge+requests).\nWe label some issues to explicitly call out the ones that we won’t schedule\nanytime soon, but we still want it. These issues usually have very clear scopes,\nso they often just require a simple implementation. They’re nice targets if\nyou don’t know what to contribute but want to gain experience.\n\nIf you would like to see how we handle community contributions, please take a\nlook at [`Community contribution`](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?label_name[]=Community%20contribution).\nWe put this label on all community contributions, therefore you can easily\nfind all the past and current community contributions. We look forward to\nyour future contributions as well!\n\n[Cover image](https://unsplash.com/photos/vqDAUejnwKw) by\n[Victor Freitas](https://unsplash.com/@victorfreitas), licensed\nunder [CC X](https://unsplash.com/license).\n{: .note}\n",[268,9,1511,934,787],"demo",{"slug":1513,"featured":6,"template":698},"contributing-to-gitlab-with-ease","content:en-us:blog:contributing-to-gitlab-with-ease.yml","Contributing To Gitlab With Ease","en-us/blog/contributing-to-gitlab-with-ease.yml","en-us/blog/contributing-to-gitlab-with-ease",{"_path":1519,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1520,"content":1525,"config":1530,"_id":1532,"_type":13,"title":1533,"_source":15,"_file":1534,"_stem":1535,"_extension":18},"/en-us/blog/contributor-after-single-code-base",{"title":1521,"description":1522,"ogTitle":1521,"ogDescription":1522,"noIndex":6,"ogImage":1462,"ogUrl":1523,"ogSiteName":685,"ogType":686,"canonicalUrls":1523,"schema":1524},"Contributing to GitLab after move to a single codebase","How contributors can benefit from the move to a single codebase for GitLab Community and Enterprise Editions.","https://about.gitlab.com/blog/contributor-after-single-code-base","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Contributing to GitLab after move to a single codebase\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-10-02\",\n }",{"title":1521,"description":1522,"authors":1526,"heroImage":1462,"date":1527,"body":1528,"category":716,"tags":1529},[1281],"2019-10-02","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nBy now, many readers will already be familair with GitLab's move to a single Rails codebase for GitLab Community(CE) and Enterprise(EE) Editions. The motivation for the change and work involved were well documented in blog posts by [Marin Jankovski](/blog/merging-ce-and-ee-codebases/) and [Yorick Peterse](/blog/a-single-codebase-for-gitlab-community-and-enterprise-edition/). Also, if you had an open merge request (MR) in CE, you probably saw messages from the GitLab bot (`@gitlab-bot`) like the one below. \n\n![GitLab bot message](https://about.gitlab.com/images/blogimages/Bot-closing-GitLab-FOSS-MR.png){: .shadow.medium.center} \n## Only impacts contributions to the new GitLab repository\n\nI want to highlight a couple of things with this move to a single codebase. First, if you are contributing to other GitLab projects such as [Charts](https://gitlab.com/gitlab-org/charts/gitlab), [GitLab Design System](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com), [GitLab UI](https://gitlab.com/gitlab-org/gitlab-ui), [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab), [Runner](https://gitlab.com/gitlab-org/gitlab-runner), etc., this move to a single Rails codebase for CE & EE will not have any impact on your contribution workflow. \n## Licenses remain the same\n\nNext, there is no change to licensing. GitLab CE will remain open source under the MIT license. GitLab EE code will reside in the [`ee` directory](https://gitlab.com/gitlab-org/gitlab/tree/master/ee) in the [new gitlab (formerly gitlab-ee) project](https://gitlab.com/gitlab-org/gitlab) and will remain source available under a proprietary license. \n## Higher efficiency and easier to contribute\n\nWith this move to a single codebase, there will be less duplicate work and manual intervention required from GitLab team members in the future. This gives them more bandwidth for higher value activities, including helping with wider community contributions.\n\nThe single codebase should also simplify things for wider community members, as you can now search [for issues in one place](https://gitlab.com/gitlab-org/gitlab/issues), and there's also [one place for MRs](https://gitlab.com/gitlab-org/gitlab/merge_requests).\n\nAs another example for improvement, in the past, contributors occasionally had to deal with `ee_compat_check` errors when they submitted an MR in CE. This required opening an MR in EE (or asking a GitLab team member to open an EE MR) and then wait for it to be merged before continuing with the CE MR. This was a pain point for many contributors, and I am excited that this will be eliminated with the single codebase. \n## Re-submitting MRs against the new GitLab project\n\nIf you have an MR that was auto-closed by the GitLab bot in CE (now [GitLab FOSS](https://gitlab.com/gitlab-org/gitlab-foss)), you can continue your work by creating a new MR in the [new gitlab project](https://gitlab.com/gitlab-org/gitlab) following the steps outlined in the GitLab bot message above. If you have any questions or encounter issues when you open a new MR, please feel free to [mention](https://docs.gitlab.com/ee/user/group/subgroups/#mentioning-subgroups) the reviewers from your original MR or me and ask for help. \n\nDuring and after the transition, I was happy to see MR's continuing to come in from the wider community so it doesn't look like this was a major disruption. However, if you have any questions or feedback you are welcome to [open an issue in gitlab](https://gitlab.com/gitlab-org/gitlab/issues) or reach out to me at `rpaik@gitlab.com`.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}",[268,9,787],{"slug":1531,"featured":6,"template":698},"contributor-after-single-code-base","content:en-us:blog:contributor-after-single-code-base.yml","Contributor After Single Code Base","en-us/blog/contributor-after-single-code-base.yml","en-us/blog/contributor-after-single-code-base",{"_path":1537,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1538,"content":1543,"config":1548,"_id":1550,"_type":13,"title":1551,"_source":15,"_file":1552,"_stem":1553,"_extension":18},"/en-us/blog/contributor-post-hannes",{"title":1539,"description":1540,"ogTitle":1539,"ogDescription":1540,"noIndex":6,"ogImage":1276,"ogUrl":1541,"ogSiteName":685,"ogType":686,"canonicalUrls":1541,"schema":1542},"GitLab Code Contributor: Hannes Rosenögger","Core team member Hannes Rosenögger shares his experience contributing to GitLab since 2014.","https://about.gitlab.com/blog/contributor-post-hannes","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Hannes Rosenögger\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-11-20\",\n }",{"title":1539,"description":1540,"authors":1544,"heroImage":1276,"date":1545,"body":1546,"category":784,"tags":1547},[1281],"2018-11-20","\nFor this month's blog post, we're featuring another [Core Team](/community/core-team/) member [Hannes Rosenögger](https://gitlab.com/haynes).\n\n### When did you first contribute to GitLab?\n\nMy first [MR to close multiple issues with one commit](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/263) was back in December 2014. So that's almost four years ago!\n\n### Why and how did you decide to contribute to GitLab?\n\n I used the Community Edition privately and noticed that mentioning multiple issues in an MR only closed the first issue. Since GitLab was open source and the fix was easy, I decided to fix it myself. GitLab's open policy about everything within the company was also a huge factor.\n\n### Which area(s) of the GitLab product have you been contributing to?\n\nI guess it's been pretty random for me. Most of my contributions have been on the backend side and documentation fixes, but if I see something that I can easily fix or I need a feature for my work, I try to make a contribution. I also provide support on the #gitlab IRC channel on freenode. My IRC handle is `haynes`.\n\n### Can you tell us what you do professionally?\n\nI am a Java software developer for a public sector organization in Germany.\n\n### What do you like to do when you're not working?\n\nWhen I'm not working, I'm probably doing something for my local scout group. I enjoy working with the kids and teaching. I also like to fix things from coffee machines to cars. Basically anything that I can fix with a bit of work.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-5\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n \u003C!-- Indicators -->\n \u003Col class=\"carousel-indicators\">\n \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"1\">\u003C/li>\n \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"2\">\u003C/li>\n \u003C/ol>\n\n \u003C!-- Wrapper for slides -->\n \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n \u003Cdiv class=\"item active\">\n \u003Cimg src=\"/images/blogimages/Hannes-blogpost/workbench.jpg\" alt=\"Hannes on workbench\">\n \u003C/div>\n \u003Cdiv class=\"item\">\n \u003Cimg src=\"/images/blogimages/Hannes-blogpost/dishwasher.jpg\" alt=\"Hannes working on his dishwasher\">\n \u003C/div>\n \u003Cdiv class=\"item\">\n \u003Cimg src=\"/images/blogimages/Hannes-blogpost/washing_machine.jpg\" alt=\"Washing machine repair\">\n \u003C/div>\n\n \u003C/div>\n\n \u003C!-- Controls -->\n \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"prev\">\n \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n \u003Cspan class=\"sr-only\">Previous\u003C/span>\n \u003C/a>\n \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"next\">\n \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n \u003Cspan class=\"sr-only\">Next\u003C/span>\n \u003C/a>\n\u003C/div>\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nContributing to GitLab is easier than it looks at a first glance and you can contribute to the community in many different ways. For example, if you want to help out translating the GitLab user interface to your native language on [CrowdIn](https://translate.gitlab.com/), this does not require programming skills or any special setup on your laptop. Also when you want to contribute code, reviewers are normally quite fast in getting back to you and are more than happy to help if you have any questions.\n\nIf you are unsure how to get started or you need help, anyone should feel free to ping me on Twitter ([@hrosenoegger](https://twitter.com/hrosenoegger)) or in the #gitlab IRC channel on [freenode](http://freenode.net/).\n\n### Anything else you want to share with the community?\n\nI love the fact that GitLab actually listens to the community. Even after they make a decision to add a new, paid feature, when community members believe it makes more sense to have the feature in [GitLab Core](/pricing/#self-managed) or the free tier of [GitLab.com](/pricing/), they will actually port it back. The [Squash and Merge feature](/releases/2018/06/22/gitlab-11-0-released/#squash-and-merge-in-gitlab-core-and-gitlabcom-free) is a good example of that.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":1549,"featured":6,"template":698},"contributor-post-hannes","content:en-us:blog:contributor-post-hannes.yml","Contributor Post Hannes","en-us/blog/contributor-post-hannes.yml","en-us/blog/contributor-post-hannes",{"_path":1555,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1556,"content":1561,"config":1566,"_id":1568,"_type":13,"title":1569,"_source":15,"_file":1570,"_stem":1571,"_extension":18},"/en-us/blog/contributor-post-jacopo",{"title":1557,"description":1558,"ogTitle":1557,"ogDescription":1558,"noIndex":6,"ogImage":1276,"ogUrl":1559,"ogSiteName":685,"ogType":686,"canonicalUrls":1559,"schema":1560},"GitLab Code Contributor: Jacopo Beschi","Core Team member Jacopo Beschi shares why he loves contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-jacopo","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Jacopo Beschi\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-09-06\",\n }",{"title":1557,"description":1558,"authors":1562,"heroImage":1276,"date":1563,"body":1564,"category":784,"tags":1565},[1281],"2018-09-06","\n\nThis is the second blog post [highlighting GitLab community members](/blog/contributor-post-vitaliy/)\nwho are making code contributions to GitLab. This month, we're featuring Jacopo\nBeschi, who is based in Italy and is also a member of the [Core Team](/community/core-team/).\n\n### How long have you been contributing to GitLab?\n\nI've been contributing since late 2016.\n\n### Why and how did you decide to contribute to GitLab?\n\nI was looking for an interesting open source software application mostly written\nin Ruby to contribute to. After some Googling around, I found GitLab and instantly\nfell in love with the application and this community.\n\n### Which areas of the GitLab product do you contribute to?\n\nI've contributed to multiple areas of GitLab, such as [backend](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18757),\n[frontend](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9890),\n[API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16478),\n[Utility](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11579),\nand [Quality](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15188)\nwhich are written in Rails.\n\nI haven’t had a chance to contribute to the Golang part of GitLab, such as\n[GitLab Runner](https://docs.gitlab.com/runner/), [Gitaly](https://docs.gitlab.com/ee/administration/gitaly/),\nor [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse).\n\n### Can you tell us what you do professionally?\n\nCurrently, I work as technical lead for [Iubenda](http://www.iubenda.com), a SaaS\nprovider focused on privacy and cookie policies.\n\n### What do you like to do when you're not working?\n\nWhen I’m not working, I enjoy training in the gym and spending time with my wife and friends.\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nDon’t be nervous about getting started! This [Contributing to GitLab page](/community/contribute/)\nexplains all the steps you need to take in order to be a successful contributor,\nand I encourage people to start there.\n\nGitLab also has a lot of [online documentation](https://docs.gitlab.com/) that\nyou could search in order to solve most common questions that developers have.\n\n### Do you have anything else you’d like to share?\n\nContributing to GitLab not only enhances your resume but also allows you to get\nin touch with great people who can help you improve your technical knowledge.\nIn addition, your contribution to GitLab will affect the lives of thousands of\ndevelopers around the globe!\n\n## Interested in learning how you can contribute?\n\nAs Jacopo already suggested, a good place to start is the\n[Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":1567,"featured":6,"template":698},"contributor-post-jacopo","content:en-us:blog:contributor-post-jacopo.yml","Contributor Post Jacopo","en-us/blog/contributor-post-jacopo.yml","en-us/blog/contributor-post-jacopo",{"_path":1573,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1574,"content":1579,"config":1584,"_id":1586,"_type":13,"title":1587,"_source":15,"_file":1588,"_stem":1589,"_extension":18},"/en-us/blog/contributor-post-luke",{"title":1575,"description":1576,"ogTitle":1575,"ogDescription":1576,"noIndex":6,"ogImage":1276,"ogUrl":1577,"ogSiteName":685,"ogType":686,"canonicalUrls":1577,"schema":1578},"GitLab Code Contributor: Luke Picciau","New contributor Luke Picciau shares why he started contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-luke","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Luke Picciau\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-10-04\",\n }",{"title":1575,"description":1576,"authors":1580,"heroImage":1276,"date":1581,"body":1582,"category":784,"tags":1583},[1281],"2018-10-04","\nFor this month's blog post, we're featuring a new contributor [Luke Picciau](https://gitlab.com/Qwertie), who started contributing to GitLab a few months ago.\n\n### When did you first contribute to GitLab?\nMy first contribution was in July 2018, with my MR to [add a button for regenerating 2FA codes](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20295).\n\n### Why and how did you decide to contribute to GitLab?\nI have been using GitLab pretty heavily since 2014. I decided to start contributing in order to practice developing features on a large project. Because I am very familiar with features of GitLab from the user perspective, navigating the code was easy and I was able to start adding new features quickly.\n\n### Which area(s) of the GitLab product are you interested in contributing to?\nI’d love to look into the new [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) and see what improvements could be made, as I see this as a useful tool. Personally, I’d like to use it to write posts for my static site and see the compiled result in my browser as well.\n\n### Can you tell us what you do professionally (or academically if you're going to school)?\nI am a full stack web developer. I primarily use Rails and VueJS. Currently I am also studying for a Bachelor of Information Technology at the University of South Australia. I’m also building an open source website for fitness tracking and analytics of GPS recordings. It’s not quite ready to use yet, but I am pushing regular updates to [the repo](https://gitlab.com/pikatrack/pikatrack).\n\n### What do you like to do when you're not working or studying?\nI’ll often be helping open source projects such as mapping the local area on [Open Street Map](https://www.openstreetmap.org). I also love to go down to the mountain bike parks around Adelaide.\n\n### Can you tell us where you live and what you like about your area?\nI live in [Adelaide, South Australia](https://www.google.com/maps/place/Adelaide+SA,+Australia/@-35.0278392,134.1260638,6z/). My favorite thing about the area is living close to so many national parks and amazing mountain bike trails which give endless exploration possibilities.\n\n![Luke on his mountain bike](https://about.gitlab.com/images/blogimages/Luke_Picciau_mountain_biking_new.jpg){: .shadow.small.center}\n\n### What advice do you have for others who may be interested in contributing to GitLab?\nOne of the things I find most useful is using an IDE or text editor with “go to definition” support. This allows you to click on function and class names and be taken to the place where they are defined. This, in my opinion, is an essential feature for working on a codebase as large as GitLab, especially in a language like Ruby, where it can be difficult to work out where things have been imported from. I personally use [RubyMine](https://www.jetbrains.com/ruby/), but I have been told [Vim](https://www.vim.org/) can also be set up with good Ruby support. Another tip I have is if you get part way through making a change and get stuck on something or need advice on what should be done, commit the changes and [create a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#doc-nav) with what you have done and any questions you have. Someone should reply to the merge request to help you get the changes finished and ready for merge.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":1585,"featured":6,"template":698},"contributor-post-luke","content:en-us:blog:contributor-post-luke.yml","Contributor Post Luke","en-us/blog/contributor-post-luke.yml","en-us/blog/contributor-post-luke",{"_path":1591,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1592,"content":1597,"config":1602,"_id":1604,"_type":13,"title":1605,"_source":15,"_file":1606,"_stem":1607,"_extension":18},"/en-us/blog/contributor-post-siemens",{"title":1593,"description":1594,"ogTitle":1593,"ogDescription":1594,"noIndex":6,"ogImage":1276,"ogUrl":1595,"ogSiteName":685,"ogType":686,"canonicalUrls":1595,"schema":1596},"GitLab Code Contributor: Alexis Reigel","Alexis Reigel shares his experience as a GitLab contributor on behalf of Siemens.","https://about.gitlab.com/blog/contributor-post-siemens","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Alexis Reigel\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-12-18\",\n }",{"title":1593,"description":1594,"authors":1598,"heroImage":1276,"date":1599,"body":1600,"category":784,"tags":1601},[1281],"2018-12-18","\nFor this month's blog post, we're featuring [Alexis Reigel](https://gitlab.com/koffeinfrei). Alexis was also an [MVP for GitLab 9.5 and 10.8](/community/mvp/).\n\n![Alexis Reigel](https://about.gitlab.com/images/blogimages/Alexis_Reigel.jpeg){: .shadow.small.center}\n\n### How did you get involved with contributing to GitLab?\n\nMy Siemens colleagues have been using GitLab since 2013 with [GitLab 5.2](/releases/2013/05/22/gitlab-5-dot-2-released/). The *[upstream first](https://www.redhat.com/blog/verticalindustries/why-upstream-contributions-matter-when-developing-open-source-nfv-solutions/)* principle is important at Siemens, as they don't want to maintain local patches/forks of software. I was hired to contribute features to GitLab that are needed at Siemens, and this give-and-take process between contributors and users is what is great about open source software. My first contribution was the ability to add a [custom brand header logo in emails](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9049), which I created on Feb. 7, 2017 and was merged on Feb. 22, 2017.\n\n### What was your experience with the first merged MR?\n\nThere was no controversy with my first MR, and therefore not much debate before it was merged. The review was very quick and the relevant people chimed in right from the start. For some of the later, more complicated merge requests, it was not always this straightforward. Depending on how complicated the MR is and how many people from GitLab participate, the process may take longer and generate a lot of discussions.\n\n### What advice do you have for others who may be interested in contributing to GitLab? In particular, any insights you can share with current GitLab customers who may be thinking about making code contributions?\n\nFirst, I recommend reviewing existing MRs and issues before submitting an MR. In many cases, there are already discussions and potential solutions for a certain feature or bug fix. It's also helpful to find out [who from GitLab](/company/team/) is relevant or responsible for a certain area so you can ping the right person from the start.\n\nThe initial contribution should always be a minimal solution or what GitLab calls a [\"Minimum Viable Change (MVC)\"](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc), because the solution will often change with feedback. The initial contribution should be considered a starting point for collaboration between the contributor and GitLab team-members.\n\nIn some cases, a contributor may need to be patient with their MR, as depending on the topic and complexity it may take some time to move things forward. The people from GitLab are always very kind and friendly so the discussions are respectful.\n\n### Do you have other colleagues at Siemens who also contribute to GitLab? How do you go about planning and working on your contributions?\n\nYes, there are several colleagues who are active within the GitLab community and you will see [Siemens mentioned in MRs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/?scope=all&utf8=%E2%9C%93&state=merged&search=siemens).\n\nMy Siemens colleagues collect issues and feature requests internally and prioritize them based on how important and urgent they are. After discussing feature requests with coworkers to make sure we have a common understanding of the intended functionality, I start to work on the issues according to their priority. I have a lot of freedom and trust from Siemens on what the solution I contribute should look like.\n\n### What do you like to do when you're not working?\n\nI work on several other free and open source projects such as [Metaflop](https://www.metaflop.com/), [Mykonote](https://github.com/panter/mykonote/blob/master/README.md), and others in my spare time. Apart from that, I like spending time with my family and friends. If there's any time left, I make and listen to music or watch a movie or two.\n\n### Anything else you want to share with the community?\n\nGitLab is a great product and is one of the friendliest and healthiest open source communities. Contributing to such a large project may seem daunting at first, but will pay off in the end. Your contribution will be appreciated by GitLab team-members as well as everyone who uses the product.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":1603,"featured":6,"template":698},"contributor-post-siemens","content:en-us:blog:contributor-post-siemens.yml","Contributor Post Siemens","en-us/blog/contributor-post-siemens.yml","en-us/blog/contributor-post-siemens",{"_path":1609,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1610,"content":1615,"config":1620,"_id":1622,"_type":13,"title":1623,"_source":15,"_file":1624,"_stem":1625,"_extension":18},"/en-us/blog/contributor-post-vitaliy",{"title":1611,"description":1612,"ogTitle":1611,"ogDescription":1612,"noIndex":6,"ogImage":1276,"ogUrl":1613,"ogSiteName":685,"ogType":686,"canonicalUrls":1613,"schema":1614},"GitLab Code Contributor: Vitaliy Klachkov","Core Team member Vitaliy Klachkov shares how he started contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-vitaliy","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Vitaliy Klachkov\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-08-08\",\n }",{"title":1611,"description":1612,"authors":1616,"heroImage":1276,"date":1617,"body":1618,"category":784,"tags":1619},[1281],"2018-08-08","\nWelcome to our new blog series featuring code contributors from the GitLab community! This blog will highlight the wonderful contributions made by GitLab community members and will hopefully inspire others to contribute to GitLab. For the first blog post, we are happy to welcome [Vitaliy “blackst0ne” Klachkov](https://gitlab.com/blackst0ne), who has been chosen as a [release MVP](/community/mvp/) three times!\n\n### How long have you been contributing to GitLab?\n\nI've been contributing since August 2016.\n\n### Why and how did you decide to contribute to GitLab?\n\nI read a news article about a new GitLab release and I didn’t even know what GitLab was back then. There was also a discussion on an example of a Rails-based project with a good codebase, and people suggested taking a look at GitLab.\n\nI was intrigued and decided to take a closer look at GitLab. I actually found\nroom for improvement in the codebase so I started pushing a few merge requests (MRs). I received responses within 1-2 days and I was very impressed. With some of the other communities, I’m used to waiting weeks for feedback.\n\nSo, I kept submitting more merge requests and so far, I have 227 merged MRs. I’m proud that I’m one of the top 50 contributors among 2000+ GitLab [code contributors](http://contributors.gitlab.com/) that include GitLab employees.\n\n### Which areas of the GitLab product do you contribute to?\n\nMostly it has been backend changes, but many of my MRs touched the frontend as well. I spent my time bringing popular features (e.g. [squash and merge to CE](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#doc-nav), [mermaid support](https://docs.gitlab.com/ee/user/markdown.html#mermaid), [switch markdown engine to CommonMark](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14835), [customizable branch name from issues](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13884), etc.), fixing technical debts (e.g. [migrate all spinach specs to rspec](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=blackst0ne&label_name%5B%5D=technical%20debt&label_name%5B%5D=Quality&search=Spinach)), upgrading [GitLab to Rails 5.0](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=blackst0ne&label_name%5B%5D=rails5), and many other improvements.\n\n### Can you tell us what you do professionally?\n\nI am a full-stack web developer at [GEOPHYSTECH LLC](https://geophystech.ru/). The company is focused on seismology, earthquakes, and everything related to earthquake hazards.\n\n### What do you like to do when you're not working?\n\nI’m a big fan of sports or anything that keeps my body moving, such as running, swimming, snowboarding, table tennis, volleyball, ice-blading, football, CrossFit workout, etc.\n\nI also enjoy [chess](https://lichess.org/), reading books/articles, and UX-related things. I’ve been collaborating with GitLab’s UX team.\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nContributing to GitLab is easy. If you want the experience of being a part of a popular open source project, you are more than welcome to join the GitLab community! You can also ping me on [Twitter](https://twitter.com/blackst0ne) if you have any questions or need any help as you get started.\n\n### Do you have anything else you’d like to share?\n\nGitLab has some nice [swag](https://shop.gitlab.com/)! I’ve gotten some great ones for my release MVPs.\n\n## Interested in learning how you can contribute?\n\nA good place to start would be the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, and translation.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":1621,"featured":6,"template":698},"contributor-post-vitaliy","content:en-us:blog:contributor-post-vitaliy.yml","Contributor Post Vitaliy","en-us/blog/contributor-post-vitaliy.yml","en-us/blog/contributor-post-vitaliy",{"_path":1627,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1628,"content":1633,"config":1638,"_id":1640,"_type":13,"title":1641,"_source":15,"_file":1642,"_stem":1643,"_extension":18},"/en-us/blog/contributor-program-update",{"title":1629,"description":1630,"ogTitle":1629,"ogDescription":1630,"noIndex":6,"ogImage":1462,"ogUrl":1631,"ogSiteName":685,"ogType":686,"canonicalUrls":1631,"schema":1632},"Updates from the GitLab contributor community","Here's what's happening with the wider contributor community.","https://about.gitlab.com/blog/contributor-program-update","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Updates from the GitLab contributor community\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-04-17\",\n }",{"title":1629,"description":1630,"authors":1634,"heroImage":1462,"date":1635,"body":1636,"category":784,"tags":1637},[1281],"2019-04-17","\n\nI joined GitLab in June 2018, and it's been exciting to work with our wider community of contributors.\nOne of the first things I did when I started was to look into community metrics to get a better\nunderstanding of the community, and here are a couple of numbers I'd like to share:\n\nSince 2016, about 15 percent of merged MR for the [GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-ce)\nwere contributed by community members (see the chart below). In addition, we had over 200\nfirst-time contributors to GitLab between the 11.5 and 11.9 releases, and it's been fun seeing [people\ncelebrate their first merged MRs on Twitter](https://twitter.com/hashtag/myFirstMRmerged?src=hash).\n\n![Community contribution to CE](https://about.gitlab.com/images/blogimages/contributor-pgm-blogpost/CE_Merged_MRs_since_Jan_2016.png){: .medium.center}\n\nIt's definitely fun being part of a growing community, and I wanted to provide a quick update\non a number of items that we have been working on.\n\n## Core Team updates\n\n### Monthly calls\n\nThe [Core Team](/community/core-team/) consists of individuals who have made sustained contributions\nto GitLab and their mission is to represent the wider GitLab community.\nI started scheduling a regular call with Core Team members\nand I've been very impressed with the quality of discussions we have each month.\nCore Team members helped improve responsiveness to community contributions, Hackathons,\nand even revamped the Core Team page itself. Everyone is welcome to join the call, and the\nlogistics, notes, slides, etc. are available on the [Monthly Core Team meeting page](https://gitlab.com/gitlab-core-team/general/wikis/monthly-core-team-meeting).\nIf you want to watch recordings of previous meetings, you can check out the [Core Team meeting playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthZ12EUkq3N9QlThvkf3WGnZ).\n\n![GitLab Core Team](https://about.gitlab.com/images/blogimages/contributor-pgm-blogpost/Core_Team.png){: .shadow.small.center}\n\n### New additions to the team\n\nThere have also been changes to the Core Team composition. To provide additional support,\nthere will be up to two GitLab company team members forming part of the\nCore Team. So, I'm excited to share that [Rémy Coutable](https://gitlab.com/rymai) and\n[Winnie Hellmann](https://gitlab.com/winh) are now members of the Core Team.\nWinnie was actually a Core Team member prior to joining GitLab, and Rémy has been working\nwith Core Team members for the past several years, so they're perfect additions to the team.\n\nIn addition to the two GitLab team-members, [Ben Bodenmiller](https://gitlab.com/bbodenmiller)\nand [George Tsiolis](https://gitlab.com/gtsiolis) joined the Core Team in the past several months.\nAs you will see in the next section, both Ben and George were two of the top code contributors in 2018.\n\n## Recognizing regular contributors\n\nIn addition to the Core Team members, we also have dozens of members of the wider community\nmaking regular contributions to GitLab. In order to recognize their work, I started a\n[top contributors page](/community/top-annual-contributors/index.html) and\nplan to update this each year to highlight regular contributors. Following examples from other\nopen source communities, we now have badging for three different levels of contributions.\nShortly, we will be sending out special GitLab merchandise to these contributors so they can\ncelebrate their accomplishments. My hope is that we will see an increase in the number of regular\ncontributors in the years to come. In addition to the number of contributors, I also want to improve the diversity of regular contributors – whether it's gender, geography, occupation, etc. – and will start a conversation on this topic in various forums, including the Core Team meeting.\n\n![Contributor badges](https://about.gitlab.com/images/blogimages/contributor-pgm-blogpost/contributor_badges.png){: .shadow.small.center}\n\n## \"Contribute for prize\" issues\n\nIf you participated in the [Q1 Hackathon](/blog/q1-hackathon-recap/),\nyou probably remember that we highlighted an issue in each [product stage](https://handbook.gitlab.com/handbook/product/categories/)\nto encourage people to contribute for a special hackathon prize. Following the success of this\nin the Hackathon, we created a new label `Contribute for prize` to encourage community members\nto work on priority issues on an ongoing basis. You can find more information in the [contributor success handbook page](/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows.html#supporting-the-wider-community-contributors)\nand I encourage everyone to [search for issues with the label `Contribute for prize`](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Contribute%20for%20prize) to start working on them.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,9,787],{"slug":1639,"featured":6,"template":698},"contributor-program-update","content:en-us:blog:contributor-program-update.yml","Contributor Program Update","en-us/blog/contributor-program-update.yml","en-us/blog/contributor-program-update",{"_path":1645,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1646,"content":1652,"config":1658,"_id":1660,"_type":13,"title":1661,"_source":15,"_file":1662,"_stem":1663,"_extension":18},"/en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile",{"title":1647,"description":1648,"ogTitle":1647,"ogDescription":1648,"noIndex":6,"ogImage":1649,"ogUrl":1650,"ogSiteName":685,"ogType":686,"canonicalUrls":1650,"schema":1651},"Create a workspace quickly with the GitLab default devfile","The GitLab default devfile makes it easier than ever to try out workspaces for new projects. Learn how to share developer environment configurations effortlessly with this tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097860/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%281%29_2XDPsbkjQ3o6tcdom6IGxI_1750097859914.png","https://about.gitlab.com/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Create a workspace quickly with the GitLab default devfile\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Zhaochen Li\"}],\n \"datePublished\": \"2025-02-27\",\n }",{"title":1647,"description":1648,"authors":1653,"heroImage":1649,"date":1655,"body":1656,"category":1388,"tags":1657},[1654],"Zhaochen Li","2025-02-27","Software development environments can be complex to set up and maintain. Developers often spend a significant amount of time configuring their local environments with the right dependencies, tools, and settings. GitLab aims to solve this by providing a default devfile that enables you to create workspaces and to start developing quickly.\n\n## GitLab Workspaces\n\nGitLab Workspaces provide isolated development environments for making changes to your GitLab projects without the complexity of setting up local dependencies. Workspaces ensure reproducible development setups, allowing developers to share their environment configurations effortlessly.\n\nBy default, GitLab Workspaces are configured to use the GitLab VS Code fork and include the GitLab Workflow extension. To learn more, visit [the GitLab Workspaces documentation](https://docs.gitlab.com/ee/user/workspace/).\n\n## Understand devfiles\n\nA [**devfile**](https://devfile.io/docs/2.2.0/devfile-ecosystem) is a YAML-based declarative configuration file that defines a project's development environment. It specifies the necessary tools, languages, runtimes, and other components required for development.\n\nPreviously, [setting up a workspace](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) required a custom devfile at the root of the repository. For example, a `.devfile.yaml` file. A typical devfile looked like this:\n\n![typical default devfile](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-26_at_8.15.58_AM_aHR0cHM6_1750097868229.png)\n\n## GitLab default devfile\n\nStarting in GitLab 17.9, a GitLab default devfile is available for all projects when creating a workspace. This eliminates the need to manually create a devfile before starting a workspace.\nHere is the content of the default devfile:\n\n![GitLab default devfile content](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-26_at_8.16.20_AM_aHR0cHM6_1750097868230.png)\n\nWhen creating a workspace with the GitLab UI, the option **Use GitLab default devfile** is always available – regardless of whether custom devfiles exist in the repository. Simply select this option to start exploring GitLab Workspaces with one less setup step.\n\n![Use GitLab default devfile screenshot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097868/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097868232.png)\n\n## Create your own custom devfiles\nWhile the GitLab default devfile provides a quick way to start a workspace, you may want to customize your development environment to better fit your project's needs. By creating a custom devfile, you can tailor your development environment with the exact tools, dependencies, and configurations needed for your workflow.\n\nConsider creating a custom devfile if you need to:\n\n- Add project-specific dependencies beyond the base development image.\n- Adjust CPU and memory resource limits.\n- Configure multiple containers for additional services like databases.\n- Define custom, project-specific, environment variables.\n- Set up specific port mappings.\n- Integrate specialized development tools like debuggers or language servers.\n\nFor more details, see the [Workspaces devfile documentation](https://docs.gitlab.com/ee/user/workspace/#devfile).\n\n## Read more\n\n- [Build and run containers in Remote Development workspaces](https://about.gitlab.com/blog/build-and-run-containers-in-remote-development-workspaces/)\n- [Use GitLab AI features out-of-the-box in a GitLab Workspace](https://about.gitlab.com/blog/use-gitlab-ai-features-out-of-the-box-in-a-gitlab-workspace/)\n- [Quickstart guide for GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/)\n- [Enable secure sudo access for GitLab Remote Development workspaces](https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces/)\n",[9,495,829,828,1388],{"slug":1659,"featured":6,"template":698},"create-a-workspace-quickly-with-the-gitlab-default-devfile","content:en-us:blog:create-a-workspace-quickly-with-the-gitlab-default-devfile.yml","Create A Workspace Quickly With The Gitlab Default Devfile","en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile.yml","en-us/blog/create-a-workspace-quickly-with-the-gitlab-default-devfile",{"_path":1665,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1666,"content":1672,"config":1678,"_id":1680,"_type":13,"title":1681,"_source":15,"_file":1682,"_stem":1683,"_extension":18},"/en-us/blog/create-vision",{"title":1667,"description":1668,"ogTitle":1667,"ogDescription":1668,"noIndex":6,"ogImage":1669,"ogUrl":1670,"ogSiteName":685,"ogType":686,"canonicalUrls":1670,"schema":1671},"GitLab's 2019 product vision for DevOps Create","Take an early look at where collaboration, merge requests, and the Web IDE are heading in 2019.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678812/Blog/Hero%20Images/web-ide-cover.jpg","https://about.gitlab.com/blog/create-vision","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab's 2019 product vision for DevOps Create\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"James Ramsay\"}],\n \"datePublished\": \"2018-09-21\",\n }",{"title":1667,"description":1668,"authors":1673,"heroImage":1669,"date":1675,"body":1676,"category":300,"tags":1677},[1674],"James Ramsay","2018-09-21","\nGitLab is a single application, so for convenience we organize by [DevOps stages](https://handbook.gitlab.com/handbook/product/categories/). The Create stage of the DevOps lifecycle is about creating code, and includes Git repositories, merge requests, code review, the Web IDE, wikis, and snippets.\n\nManaging source code is at the heart of GitLab – it's in our name and it powers your applications. This year we've shipped many important improvements to make it easier to go from idea to production. The [Web IDE](/releases/2018/06/22/gitlab-11-0-released/#cicd-pipeline-status-and-job-traces-in-the-web-ide) makes it easy for anyone to contribute, and faster to work with merge requests. [Squash and Merge](/releases/2018/06/22/gitlab-11-0-released/#squash-and-merge-in-gitlab-core-and-gitlabcom-free), and [Rebase and Fast-forward Merge](/releases/2018/01/22/gitlab-10-4-released/#rebase-and-fast-forward-in-ce) are available in GitLab CE. [File locking](/releases/2018/02/22/gitlab-10-5-released/#git-lfs-2-locking-support) is integrated with Git LFS. [Maintainers can push to forks](/releases/2018/03/22/gitlab-10-6-released/#maintainers-can-push-to-mr-from-fork). And there is much more to come this year, like [batch comments](https://gitlab.com/gitlab-org/gitlab-ee/issues/1984) for merge requests, and [suggested approvers](https://gitlab.com/gitlab-org/gitlab-ee/issues/5382) based on code owners.\n\nHere are some of the things we're thinking about for 2019:\n\n- [Collaboration](#collaboration)\n- [Code review and approvals](#code-review-and-approvals)\n- [Web IDE](#web-ide)\n- [Summary](#summing-up)\n\nAs our plans are always in draft, we'd love to hear your thoughts, and any suggestions.\n\n### Collaboration\n\nGit's distributed design made new collaborative workflows possible, and forking has made collaboration even easier. Forking is the workflow of choice for open source, and for the same reasons it is also great for private organizations. We want to remove the barriers to collaboration and [inner sourcing](/topics/version-control/what-is-innersource/), but also make it easier to collaborate with external open source projects too.\n\nThe distributed capabilities of Git aren't limited to a single server. Open source software is used extensively in commercial applications of all kinds, but collaboration between open source projects and commercial is difficult. Features and bug fixes to open source projects can sit in stale forks in private Git repositories for lack of tools and process. [Distributed merge requests](https://gitlab.com/groups/gitlab-org/-/epics/260) will make it easy publish a patch from a private GitLab instance to a public upstream server, be it GitLab, GitHub or Bitbucket. Teams will be able to work on a patch privately following internal processes, but instead of merging the reviewed and tested change privately, it can be published to a new public merge request upstream. Contributing fixes and features upstream isn't only good for the community, but it also makes commercial sense by eliminating the costly task of keeping a stale, private fork up to date. We want to make it easy for everyone to contribute to open source software, as individuals and as companies!\n\n![Mockup of distributed merge request widget](https://about.gitlab.com/images/blogimages/merge-request-distributed.png){: .medium.center.shadow}\n\nWe'll also be improving simpler forking workflows too with important quality-of-life improvements. To make it easy to see how far behind or diverged your fork is, we will make it possible to [compare branches](https://gitlab.com/gitlab-org/gitlab-ce/issues/19788) across forks and [cherry pick](https://gitlab.com/gitlab-org/gitlab-ce/issues/43568) changes directly from the upstream project into your fork. Forks of private projects will also [inherit permissions](https://gitlab.com/gitlab-org/gitlab-ce/issues/8935) from the upstream project, making it possible for upstream maintainers to rebase stale merge requests and help contributors. This will allow teams to adopt forking workflows without needing to make every project public to the world or to the organization.\n\n### Code review and approvals\n\nMerge requests are key to the workflows that allow teams to iterate rapidly and ship amazing products quickly, by bringing together all the important information in a single place. Critical to this workflow is the code review, and we want GitLab to be the best tool for doing code reviews.\n\nAutomatic code quality and linting tools can prevent code reviews becoming simple code style reviews, but without the inline feedback a reviewer can't be sure which problems have been automatically detected. A new [API for line by line code quality feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/50299) will allow output from tools to be rendered natively in GitLab in the merge request diff. Merge request authors will have a single source of truth, and code reviewers can confidently focus on important structural feedback.\n\nCode review feedback cannot truly be resolved and the merge request approved until the reviewer checks the feedback was correctly addressed. This step prevents feedback from being misunderstood or overlooked, but it is currently difficult and time consuming. We are going to streamline this important step by allowing you to [review changes since code review](https://gitlab.com/groups/gitlab-org/-/epics/314) and making [merge request diffs smarter](https://gitlab.com/groups/gitlab-org/-/epics/340). When the change is straightforward, we're going to make it possible to simply [propose a change](https://gitlab.com/gitlab-org/gitlab-ce/issues/18008) as easily as leaving a comment that can be applied with a single click – no more copying and pasting `sed` one liners! And we're going to make it easier to [view and add comments to commits](https://gitlab.com/gitlab-org/gitlab-ee/issues/1769) at any time.\n\nIn the real world, complex features often require large, complex merge requests. We will support these situations better with [commit by commit code review](https://gitlab.com/groups/gitlab-org/-/epics/285), autosquashing [`fixup!`](https://gitlab.com/gitlab-org/gitlab-ee/issues/212) and [`squash!`](https://gitlab.com/gitlab-org/gitlab-ce/issues/50400) commits, and allowing you to [preview](https://gitlab.com/gitlab-org/gitlab-ee/issues/7259) the resultant squashed commits.\n\nComplex real-world changes also need good commit messages, but commit messages are too easily neglected. Without good commit messages, debugging a regression, or modifying an important existing function is painful and error prone. To help teams adopt best practice [commit hygiene](/blog/keeping-git-commit-history-clean/), we will make [commit messages part of code review](https://gitlab.com/groups/gitlab-org/-/epics/286) by allowing comments on commit messages, improving the [visibility of commit messages](https://gitlab.com/gitlab-org/gitlab-ce/issues/49803), and making [squash and merge smarter](https://gitlab.com/gitlab-org/gitlab-ce/issues/47149). GitLab should celebrate great commit messages and amplify their benefits to make it easier for teams to adopt best practices.\n\n### Web IDE\n\nIn 2018 we're building a strong foundation for a cloud development environment with [client side evaluation](https://gitlab.com/gitlab-org/gitlab-ce/issues/47268) and [server side evaluation](https://gitlab.com/gitlab-org/gitlab-ee/issues/4013) powered live previews, and server side evaluation will also enable a [web terminal](https://gitlab.com/gitlab-org/gitlab-ee/issues/5426) to test your changes in real time. IDEs are also very personal and should support customization, to make it easy to move between your local IDE and GitLab IDE. Please share your feedback, and consider contributing – I'd love to see support for [dark syntax themes](https://gitlab.com/gitlab-org/gitlab-ce/issues/46334) and [vim keybindings](https://gitlab.com/gitlab-org/gitlab-ce/issues/47930)!\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/sSWu6TyubTE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThe Web IDE makes it easier than ever to resolve code review feedback, reducing the need to switch context in your local development environment, but we can make it even better. Addressing a comprehensive code review still requires switching backwards and forwards between the merge request and the Web IDE. [Line by line code quality feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/50299) available in the merge request diff will also be available in the Web IDE as will [live linting feedback](https://gitlab.com/groups/gitlab-org/-/epics/70) powered by server side evaluation so to help prevent new code styling problems being created while resolving feedback.\n\nWe are also considering integrating [merge request discussions](https://gitlab.com/groups/gitlab-org/-/epics/72) so that code review comments can be addressed without needing to continually switch between tabs. We don't think the Web IDE should replace the merge request, nor should every feature be duplicated into it, but do think the Web IDE can further simplify the process for resolving code review feedback so teams can iterate faster.\n\n### Summing up\n\nWriting, reviewing, and merging code is where the rubber hits the road when taking your app from idea to production, and in 2019 we want it to be better than ever before!\n\nThe [GitLab product vision](/direction/) is public so you can read up on what we're thinking about at any time, about every part of the product. Please join the conversation and share your feedback on these ideas, and offer ideas of your own! Your contributions – idea or code – are welcomed and appreciated so that we can all work together to make GitLab the best application to build and ship your next great idea.\n",[934,829,9,912,695],{"slug":1679,"featured":6,"template":698},"create-vision","content:en-us:blog:create-vision.yml","Create Vision","en-us/blog/create-vision.yml","en-us/blog/create-vision",{"_path":1685,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1686,"content":1691,"config":1697,"_id":1699,"_type":13,"title":1700,"_source":15,"_file":1701,"_stem":1702,"_extension":18},"/en-us/blog/crucial-conversations",{"title":1687,"description":1688,"ogTitle":1687,"ogDescription":1688,"noIndex":6,"ogImage":1174,"ogUrl":1689,"ogSiteName":685,"ogType":686,"canonicalUrls":1689,"schema":1690},"Having crucial conversations on an all-remote team","Exploring crucial conversations and the way they fit into our values here at GitLab.","https://about.gitlab.com/blog/crucial-conversations","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Having crucial conversations on an all-remote team\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Samantha Lee\"}],\n \"datePublished\": \"2021-02-18\",\n }",{"title":1687,"description":1688,"authors":1692,"heroImage":1174,"date":1694,"body":1695,"category":716,"tags":1696},[1693],"Samantha Lee","2021-02-18","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nLast week, I attended the [Crucial Conversations training](https://www.vitalsmarts.com/crucial-conversations-training/). Since joining the GitLab Learning and Development team back in October of 2020, requests for support in having difficult conversations with team members have been a recurring theme from people leaders. I completed this training as the first step in a two-part training that will enable myself and other members of the Learning and Development team to be certified to train the GitLab team in having crucial conversations.\n\nIn this post, I'll outline a few key takeaways from the course, share how crucial conversations look in an all-remote work environment, and explain how crucial conversations connect to our [CREDIT values](https://handbook.gitlab.com/handbook/values/).\n\n### What are crucial conversations?\n\nWhen a conversation turns crucial, emotions and stressors are running high. Crucial conversations can occur any day, at any time, with any person. They can be planned or they can come out of a casual conversation. \n\nCrucial conversations usually address one of three topics, but it's not abnormal for a crucial conversation to touch multiple topics!\n\n1. **Content**: This could be a crucial conversation about a one-time issue, like a missed deadline, forgotten appointment, or an aggrivating comment. Content conversations address what happened and how to move forward from it.\n\n2. **Pattern**: When topics of content conversations happen time after time, they become a pattern conversation. Crucial conversations to address patterns could be centered around multiple missed responsibilities or repetitive comments that impact a team's ability to work together efficiently. At home, maybe your requests to your partner to take their phone calls in another room to keep a quiet workspace have been repeatedly ignored. Or at work, your direct report has missed the end of month reporting deadline for 3 months in a row. It's important to address pattern conversation early to get to the root cause, which is likely a content issue.\n\n**A quick note about pattern conversations:** At the time of writing this blog post, our world has just hit the one-year mark of life during the Covid-19 pandemic. While addressing patterns is important, it's equally as important to treat each other with kindess and understand that pandemic-induced stress might show itself in problematic patterns. All the more reason to have a conversation about it!\n\n3. **Relationship**: Here's when things get sticky. Content and pattern conversations are about the action happening (or not happening). But relationship conversations are about the _people having the conversation_. These crucial conversations could be about a lack of trust or mutual respect in a relationship, differing communication styles, or lack of agreement on a project or plan of action. It's also important to remember that conversations intended to be content or pattern-focused can turn into relationship conversations quickly, especially when the person feels an emotional tie to the work or action being discussed.\n\nUnderstanding what crucial conversations **are** is as important as understanding what crucial conversations **are not**. Crucial conversations are **not** synonymous with conflict. This was one of the first things we addressed in the training and I think it's one of the most important factors. When we enter crucial conversations prepared for conflict, we're already approaching fight or flight. We're ready to defend ourselves, to act in protection mode. The goal of crucial conversations is not to fight or protect ourselves, but rather to collaborate on desired results.\n\nTake a second to think about the last time you were part of a crucial conversation - a conversation where you perhaps felt stressed, overwhelmed, or nervous about the topic being discussed. How did your body react? Did your heart rate increase? Did you fall silent? Maybe instead your voice was raised. We each respond to crucial conversations in different ways that detract from the main goal of arriving at a solution that works for all parties.\n\nWe've likely all been part of a crucial conversation in the past, whether it be at work or home. Once we know how to identify these conversations, we can move on to strategies for having them effectively. \n\nAt GitLab, this means having effective, results-driven crucial conversations on Zoom with people from all over the world, which brings its own set of unique challenges.\n\n### Having crucial conversations is hard, and an all-remote team brings its own challenges.\n\nIn an office setting, you might pass by a manager or colleague who asks to discuss a challenge or frustration they're having with your work. Or at home, you might spend time after dinner discussing household responsibilities with your children or roommates. During these crucial conversations, we feed off of body language, tone, and energy in the room to recognize if someone feels [psychologically unsafe](/handbook/leadership/emotional-intelligence/psychological-safety/).\n\nBut on Zoom, when your teammate might be in their home office across town or across the globe, we need to use different cues to [build safety and trust](/handbook/leadership/building-trust/).\n\nSome ways we do that at GitLab include:\n\n1. We meet regularly with our people leaders in [1:1 meetings](/handbook/leadership/1-1/). These regular sessions give space for team members to raise crucial conversations often and address challenges and blockers early.\n1. We keep [1:1 agendas](/handbook/leadership/1-1/#the-1-1-agenda) to get a heads up on what will be discussed and to document action items and takeaways from synchronous conversations.\n1. We watch for the [body language cues](/handbook/leadership/crucial-conversations/#having-crucial-conversations-on-an-all-remote-team) that we can see on a video call or in a person's tone of voice. This includes checking if someone turns their camera off mid-call, becomes silent or unresponsive to the conversation, or sounds choked up or angry.\n1. We create intentional [space for pause](/handbook/leadership/crucial-conversations/#having-crucial-conversations-on-an-all-remote-team). There can be a sense of pressure to fill every minute during any conversation. During video or phone conversations, silence might feel more uncomfortable. We ask for and respect requests for a minute to think before responding right away.\n\nThese strategies aren't exclusive to an all-remote team - I'm sure they can have a positive impact on in-person crucial conversations, too! But when working on a remote team, it's important to recognize what's missing from in-person connection and be mindful to make the space as safe as possible.\n\nI've explained what crucial conversations are and how they show up in an all-remote work environment, but most importantly, I need to explain the **why**.\n\n### Why do crucial conversations matter?\n\nCrucial conversations enable our team to live our [CREDIT values](/handbook/leadership/crucial-conversations/#how-crucial-conversations-align-with-gitlab-values). In our [values hierarchy](https://handbook.gitlab.com/handbook/values/#hierarchy), we prioritize results. What I love most about crucial conversations is that they also prioritize results.\n\nHere's an example:\n\nImagine you're an individual contributor at GitLab. You're feeling overwhelmed with the number of projects on your plate this quarter.\n\nIf you wanted, you could commit to each project, knowing the deadlines were probably unrealistic. You could show up to work each day feeling stressed and overwhelmed. You might snap one day, saying something out of frustration to your team, and regret the comment later on.\n\nOr, you could decide to address the issue with your manager in your 1:1. You can:\n1. Collect your facts. In this case, it's your list of projects all due in the quarter.\n1. Share your story. Express how the workload feels unattainable and you know you can't complete your best work in the given time frame)\n1. Come to a conclusion together. Perhaps you decide to prioritize projects, breaking each project down into specific tasks and moving long-term priorities to the next quarter.\n\nThis second scenario is completely based on results. This crucial conversation has enabled you to set yourself up for success in completing every project with your highest quality of work. The company benefits from your high-quality output. Your team benefits from having a team member who isn't totally stressed out. You benefit from feeling safe and confident in the work you're doing. Every outcome from the conversation can be traced back to a key result for yourself, your team, and the company.\n\nWith such a focus on results, our GitLab team should be having crucial conversations every day!\n\nI see crucial conversations map back to the rest of our values as well. You can read more about the [alignment of GitLab values to crucial conversations in our handbook](/handbook/leadership/crucial-conversations/#how-crucial-conversations-align-with-gitlab-values).\n\n### Getting started having crucial conversations\n\nIf you've read through this post and want to give crucial conversations a try, here are a few ways to get started:\n\n1. Read our [Crucial Conversations handbook page](/handbook/leadership/crucial-conversations/).\n1. Read our [Psychological Safety handbook page](/handbook/leadership/emotional-intelligence/psychological-safety/). Creating safe space to have crucial conversations is essential.\n1. Check out the [Crucial Conversations training](https://www.vitalsmarts.com/crucial-conversations-training/) from VitalSmarts. GitLab team members might consider using our [Growth and Development benefit](https://about.gitlab.com/handbook/total-rewards/benefits/general-and-entity-benefits/#growth-and-development-benefit) to take the training themselves.\n1. Try it out! Practicing crucial conversations is the key to getting better at the skills, so give it a try at work, at home, or even with yourself!\n1. GitLab team members - keep an eye out for internal Crucial Conversations training coming in Q2/Q3 of this year as the Learning and Development team gets certified to deliver the training!\n\n### Looking for more Learning and Development material from GitLab?\n\nIf you want to learn more about what the Learning and Development team at GitLab is up to, check out our [handbook page](/handbook/people-group/learning-and-development/) or read our past newsletters. You can also reach us at `learning@gitlab.com`.\n",[1097,9,934],{"slug":1698,"featured":6,"template":698},"crucial-conversations","content:en-us:blog:crucial-conversations.yml","Crucial Conversations","en-us/blog/crucial-conversations.yml","en-us/blog/crucial-conversations",{"_path":1704,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1705,"content":1711,"config":1717,"_id":1719,"_type":13,"title":1720,"_source":15,"_file":1721,"_stem":1722,"_extension":18},"/en-us/blog/day-in-the-life-remote-worker",{"title":1706,"description":1707,"ogTitle":1706,"ogDescription":1707,"noIndex":6,"ogImage":1708,"ogUrl":1709,"ogSiteName":685,"ogType":686,"canonicalUrls":1709,"schema":1710},"A day in the life of the \"average\" remote worker","Go on, you know you're curious! Explore a day in the life of GitLab team members from around the world.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670134/Blog/Hero%20Images/remote-life-cover.png","https://about.gitlab.com/blog/day-in-the-life-remote-worker","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"A day in the life of the \"average\" remote worker\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"},{\"@type\":\"Person\",\"name\":\"Charlie Ablett\"}],\n \"datePublished\": \"2019-06-18\",\n }",{"title":1706,"description":1707,"authors":1712,"heroImage":1708,"date":1714,"body":1715,"category":910,"tags":1716},[1325,1713],"Charlie Ablett","2019-06-18","\nGitLab is an [all-remote company](/company/culture/all-remote/), meaning we are not based in one location or even one time zone. Instead, our team is distributed in home offices and work spaces [across the globe](/company/team/#countries), everywhere from San Francisco to London to Taipei.\n\nBecause GitLab is not limited to one time zone, we work asynchronously. Our asynchronous workflow gives us a [competitive advantage](/blog/remote-enables-innovation/), because we are contributing 24 hours a day, as opposed to the standard 9am-5pm if we had a brick-and-mortar office headquartered in one location. As an organization, the focus is not on when or how a team member works, but rather on our [results](https://handbook.gitlab.com/handbook/values/#results).\n\nBecause of this emphasis on results rather than regimen, there is a lot of variability in how we structure our workdays. At [Contribute 2019](/events/gitlab-contribute/), a group of us came together to discuss how we use the flexibility GitLab affords us to structure our ideal workdays. Our discussion featured team members working in different capacities, as engineers, writers, and managers, from many different locations.\n\n## Morning\n\nThere are a few morning activities that were universal: A warm cup of coffee or tea to kick off the day; and morning cuddles with a cat or dog if you have the good fortune of having a pet.\n\n\"When my alarm goes off, Milly, my dog, who hates getting out of bed, snuggles closer to me. I get up, make coffee, and log on to begin working. Meanwhile, Milly is usually still in bed until 10:30am, sometimes even 11:30am,\" says [Sara Kassabian](/company/team/#sarakassabian), content editor, from Oakland, California.\n\nFor some of us, sunshine (or other humans) function as the morning wake-up call.\n\n\"I stopped setting an alarm because mornings are quiet in my time zone, and (inevitably) I get woken by my upstairs neighbors getting ready for work anyway! I make a big cup of coffee and try to get all my deep focus work done before my coworkers in the US start to wake up,\" says [Rebecca Dodd](/company/team/#rebecca), managing editor, from London.\n\n\"I also do not set an alarm because I often work until late. Usually my kids wake me up at some point, and then I will have a big cup of tea,\" says [Charlie Ablett](/company/team/#cablett), a senior backend engineer, [Plan](/handbook/engineering/development/dev/plan/), from New Zealand.\n\nMornings can be a particularly hectic time for working parents. Oftentimes, parents who don't work remotely will have to juggle getting their children ready for school, getting ready for work, and making school drop-off in time to get to the office between 8am-9am. Parents working at GitLab have the opportunity to be in the home and available to their children because we're [all remote](/blog/building-an-award-winning-culture-at-gitlab/). Flexible scheduling makes it a little bit easier to balance family with work obligations.\n\n## Midday\n\nWe all structure our afternoons differently. Some of us have children to pick up from school, while others are just starting their workday, or taking a break from the computer to run errands or exercise.\n\n\"I usually take a break to go running or to walk my dog. Then I’ll pick up my kids from school. I usually have one or two more screening calls and some team meetings,\" says [Stephanie Garza](/company/team/#stephaniegarza), diversity sourcing specialist, from Michigan.\n\n\"I start my workday in the afternoon by checking Slack and emails. I may go for a walk. I might work out then start focused work at 3pm or so,\" says [Laura Montemayor](/company/team/#lauraMon), frontend engineer, [Monitor](/handbook/engineering/frontend/monitor/), from New York City.\n\nWeather is also a big determinant about whether work or play is on the agenda for the afternoon.\n\n\"It depends on whether or not the weather is nice or if I have plans in the evening. If it’s sunny in New York City, you have to go outside. If it’s nice I want to go enjoy the weather! Or if I’m going out in the evening I’ll get my work done first,\" says Avielle Wolfe, backend engineer, [Secure](/handbook/engineering/development/sec/secure/), from New York City.\n\n\"If it’s sunny in Oakland, I will take Milly for a longer walk, which gives me some Vitamin D and the boost of energy I’ll need to finish up any remaining tasks for the day,\" added [Sara](/company/team/#sarakassabian).\n\nNot every team member lives in a location as urban as Oakland or New York City. Some live in suburban neighborhoods or more rural locations, all of which can have an impact on how we structure our day. For instance, [Charlie](/company/team/#cablett), who lives in a more rural setting, once had to set aside an hour around 4pm each day to milk her cows.\n\n## Evening\n\nFor those of us with children, the evenings are the ideal time to set work aside and focus on family time.\n\n\"My evening typically begins with practice. My daughter does soccer and my son does karate. My husband works a weird schedule so this is my alone time with the kids. I will make dinner and then get some more work done sometime between 8-10pm,\" says [Stephanie](/company/team/#stephaniegarza).\n\nIf our workday started in the afternoon as opposed to the morning, there are often more tasks to be completed throughout the evening.\n\n\"I am still working by evening,\" says [Laura](/company/team/#lauraMon). \"I’ll have a meal around 8pm. If I have plans, I go out, otherwise I play video games. If I get a second wind I’ll work more after 10pm.\"\n\n\"I try to finish my work by 6pm, but if I work overtime then the next day I will have an excuse to relax a little bit! In the evenings, I’ll cook dinner by putting some chicken and veggies into a steamer pot, and then continue working while that cooks, or I will go out for dinner. Sometimes I’ll attend local meetups, or just relax and watch TV. My bedtime is around midnight,\" says [Mark Chao](/company/team/#lulalala_it), backend engineer, [Create](/handbook/engineering/development/dev/create/), from Taipei.\n\n## Focused versus collaborative work\n\nGitLab gives us the flexibility to build a custom schedule, so early birds and night owls can work when they feel they are most effective. When we choose to work in tandem with teammates and when we do our focus work depends primarily upon two factors: When the overlap happens across teams and time zones, and also when we are most focused and/or creative.\n\n\"Europe and the Americas are chatty overnight so I have lots to catch up on in the morning, including the minutes of meetings that happened at 3am (e.g., daily company call),\" says [Charlie](/company/team/#cablett). \"America is still awake so I collaborate with them if I need to, and I do all my deep focus work later on when not many folks are around.\"\n\nThough GitLab has a globally distributed team across 54 countries and regions, the majority of us are based in the United States and Europe.\n\n\"After lunch, I get maybe one more hour of focused work in until 3pm when America wakes up. Then meetings start, Slack gets busy, and then I'm trying to disentangle myself and switch off for the evening,\" says [Rebecca](/company/team/#rebecca). \"If something doesn’t happen before 3pm, it generally doesn’t happen that day.\"\n\n\"In the afternoon for me, people will start to wake up and log on so I will have more interactions and working on issues,\" says [Mark](/company/team/#lulalala_it).\n\nSometimes team members with children will log on to complete a few more hours of work while the children are sleeping, generally between 8pm-10pm, and sometimes after 10pm.\n\n## Family first at GitLab\n\n\"I love working at GitLab for a variety of reasons, but the flexibility in creating work-life harmony in my life tops my list. I work closely with our executive team here, and they have been so supportive and encouraging when family-related conflicts arise. They are constantly reminding me that \"[family first](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second)\" is our mantra, and give me ease of mind to take time away when needed,\" says [Cheri Holmes](/company/team/#cheriholmes), manager, executive assistant, from Dublin, California, in a previous [blog post](/blog/building-an-award-winning-culture-at-gitlab/).\n\nInc. Magazine recently ranked GitLab as one of the [best places to work](/blog/building-an-award-winning-culture-at-gitlab/), due in large part to a company culture that gives team members the agency to balance our personal and professional obligations. While the \"average\" team member may not share a schedule, we do share a commitment to our [values](https://handbook.gitlab.com/handbook/values/#credit): Collaboration, results, efficiency, diversity, iteration, and transparency. In order to work asynchronously effectively, everyone must embrace and embody the values of our organization.\n",[829,1097,9,934],{"slug":1718,"featured":6,"template":698},"day-in-the-life-remote-worker","content:en-us:blog:day-in-the-life-remote-worker.yml","Day In The Life Remote Worker","en-us/blog/day-in-the-life-remote-worker.yml","en-us/blog/day-in-the-life-remote-worker",{"_path":1724,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1725,"content":1731,"config":1737,"_id":1739,"_type":13,"title":1740,"_source":15,"_file":1741,"_stem":1742,"_extension":18},"/en-us/blog/developer-security-divide",{"title":1726,"description":1727,"ogTitle":1726,"ogDescription":1727,"noIndex":6,"ogImage":1728,"ogUrl":1729,"ogSiteName":685,"ogType":686,"canonicalUrls":1729,"schema":1730},"The developer-security divide: frank talk from both sides","Data from our 2020 DevSecOps Survey shows dev and sec remain at odds over test, bug finding, fixes, and more. Can we be friends? Maybe.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681492/Blog/Hero%20Images/puzzle.jpg","https://about.gitlab.com/blog/developer-security-divide","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The developer-security divide: frank talk from both sides\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n \"datePublished\": \"2020-08-13\",\n }",{"title":1726,"description":1727,"authors":1732,"heroImage":1728,"date":1734,"body":1735,"category":693,"tags":1736},[1733],"Brendan O'Leary","2020-08-13","\n\n_We have to start by saying that at GitLab, there really is no developer-security divide. Dev and sec *do* get along – extraordinarily well, as a matter of fact. But there’s no denying that friction between developers and security pros does exist and we wanted to take this opportunity to acknowledge the elephant in the room._\n\n_In our [2020 Global DevSecOps Survey](/developer-survey/previous/2020/), 65% of security pros said their organizations had successfully shifted security left. Thanks to DevOps, developers, security experts, operations professionals, and testers all reported being increasingly part of cross-functional teams dedicated to getting safe code out the door more quickly._\n\n_But look a bit more closely into that rosy picture and the cracks start to appear. Security team members said developers didn’t find enough bugs early in the process and were slow to fix them when they were found. Not enough security testing happens and if the tests are run, they occur too late in the process. Very few devs said they run standard security tests like SAST or DAST. And there is even confusion over exactly who is responsible for security: 32% of sec pros told us they were solely responsible but more than 29% told us *everyone* was responsible._\n\n_To see if we could shed some clarity on these critical-to-get-right DevOps topics [Brendan O’Leary](/company/team/#brendan), senior developer evangelist, and [Ethan Strike](/company/team/#estrike), security manager, [Application Security](/topics/devsecops/), had a virtual sit down to hash out the differences between devs and sec._\n\n![Headshots of Brendan O’Leary and Ethan Strike](https://about.gitlab.com/images/blogimages/brendanethan.png){: .shadow.small.center}\nBrendan O’Leary and Ethan Strike\n{: .note.text-center}\n\n## Who is primarily responsible for security?\n\n*Ethan*: Overall, for secure development to be successful there has to be a culture of security shared between all of the stakeholders, including development, product, and security. That means that both development and security need to feel trusted and supported throughout the organization, not just in their particular vertical. Here at GitLab, our E-group has done an excellent job of building that culture, which has allowed us to tackle problems collaboratively across teams.\n\nSpecific to the question, in order to be successful, I believe the team writing the code is ultimately responsible for security. They are the owners of the code they write, and know it best, so they are in the best position to ensure its security. But that does not mean that the security team is off the hook for product vulnerabilities. They have the important responsibility of ensuring the development team has tools and knowledge available to them to write secure code. They might even contribute to the code base themselves.\n\n> For secure development to be successful there has to be a culture of security shared between all of the stakeholders. – Ethan Strike\n\nThe security team also has the important role of assessing risk and communicating that risk effectively for the development teams to act upon. It is unrealistic for both sides to expect the other to shoulder the entire security work load, and there must be a balance between security requirements and functionality based upon business requirements.\n\n*Brendan*: There are two ways to look at this. If we said who is _directly_ responsible for security, then sure it’s easy to say that the folks with \"security\" in their title are the answer to that.\n\nBut the reality, especially in a modern organization centered around software delivery and excellence, is that everyone has to be responsible for security and have it at the forefront of their minds.\n\nThe thing customers want is better software faster, but one security incident can make that irrelevant. Security thus is a *key* component of quality software, and has to be a team effort. Just as there are different folks on a car assembly line that are _primarily_ responsible for different parts of the car, the only way for a high-quality vehicle to roll off the end of the line is for everyone to work together, back each other up, and help to check each other's specialized work.\n\n## Devs aren’t running enough SAST/DAST/container or compliance scans. Why?\n\n*Brendan*: The bar is far too high to even get started running [SAST](https://www.gartner.com/en/information-technology/glossary/static-application-security-testing-sast) or [DAST](https://www.gartner.com/en/information-technology/glossary/dynamic-application-security-testing-dast) scans. Let’s take a look at them separately as they are worlds apart.\n\n> So running the code in production is hard enough, why would I spend time to try and run it _before_ production? – Brendan O’Leary\n\nFor SAST (or container or compliance) scans: To run that as a developer in a \"traditional\" organization, I would need help from the ops team to have the right tooling installed. To determine what the \"right\" tooling is, I’d probably need a security review of existing tools as they are varied and their efficacy can depend on what languages and frameworks we are specifically using to write our application. And all of that work is before the first SAST check even runs - and after they are running it’s even worse. As a developer, I don’t have a great way to understand at the end of a release cycle what changes caused which security issues, so the \"noise\" of security tests (if we have them) is too loud to find the signal inside. It’s easier to just not deal with that whole cycle.\n\nFor DAST the bar is *much* higher than even SAST. While I have all the same issues that we mentioned about SAST in terms of coronation and signal-to-noise ratios, now add that complexity to the fact that I will need an entire running \"prod-like\" environment to even think about running DAST. That means recreating a proxy for the network and architecture decisions that are made by the ops team about the production environment. And if you get the wrong thing wrong, it makes all of the DAST test invalid. So running the code in production is hard enough, why would I spend time to try and run it _before_ production?\n\n*Ethan*: In my experience this is because out of the box the tools can create a lot of noise. Common causes of noise are false positives, or a high number of low-impact findings. When you’re trying to get a feature out the door, this can understandably be frustrating. A lot of the noise comes from the generic nature of the tools, as they are meant to be applicable to every code base. Each code base is of course different.\n\nHere again though, some cooperation can go a long way. The efficacy of the tools comes with some tuning, and the goal is to get to that happy medium. For example, at GitLab, the results of the SAST tools are presented in an MR and developers are first in line for validating the findings, as they know the code the best. The application security team also looks at the results in the dashboard, and is looking to assess larger trends, identifying areas that are being overlooked/dismissed incorrectly, or simply providing additional context on the findings. That information can then be shared with the development teams. Each side has to trust that the other is working to find the right balance.\n\n## Why aren’t devs finding enough bugs?\n\n*Ethan*: This is difficult to answer, as it is driven by the circumstances. It could be a matter of security education, a feeling of lack of ownership, or just culture overall. I think that most developers, if given ownership of the code they write, would be incentivized to find as many bugs as possible. In the end, that means less time fixing things in the backlog and more time building features. In order to do that though, they need to be given resources in the form of knowledge and time to test effectively, and the security team can help them with that.\n\n*Brendan*: This is a direct result of the above. In fact, given how few developers are running SAST and DAST, it may honestly be generous to say they discover 25% of bugs. Without that infrastructure, there’s no way for me as a developer to find those issues.\n\nAnd worse than that they can all be \"out of sight, out of mind.\" If security has a walled garden around information about what security scans are important to our organization, or how to run those scans, then I’m just as happy as a developer to live in an \"ignorance is bliss\" world. That is of course until there’s a major security breach caused by poor coding practices.\n\n## How can bugs be found earlier in the process?\n\n*Brendan*: Again, the bar is too high to run the security scans. As a developer, I don’t have an easy way to do that or understand security’s requirements for those tests. Without that ability, I’m at a loss to find any bugs.\n\nAnd without any \"security\" in the pipeline, it leaves all detection of security issues to the end of a cycle when we want to actually put the code into production. And by that time, there have been dozens or hundreds of changes, so unwinding what changes caused which issues is next to impossible - much less understanding how to quickly fix them. So it’s back to the drawing board from an engineering perspective to fix issues we should have known about when we started walking down that path... of course this causes delays.\n\n> If security has a walled garden around information about what security scans are important to our organization, or how to run those scans, then I’m just as happy as a developer to live in an \"ignorance is bliss\" world. – Brendan\n\n*Ethan*: That is because testing in general comes late in the development process. I don’t think this is always security specific. This stems historically from the waterfall software development process. With agile, quality testing has become more prominent with unit testing and CI, but security is still working its way into that workflow. For example, at GitLab, we have security focused unit tests and automated SAST and dependency scanners, but we still have manual security testing, and a bug bounty program in operation after major development is complete. I think that all security teams are always looking to find ways to identify a risk when the code is written. This can be in the form of threat modeling, embedded security engineers looking at code, and the development of security-focused libraries.\n\n## Is it true that devs apparently don’t want to fix bugs?\n\n*Ethan*: I do not think that is true. I think that there can be difficulty scheduling fixes in with feature requirements. Also, if I remember correctly, [in the survey](/developer-survey/previous/2020/), some developers said that they do not always know how to fix a bug. I think that the fixing of security bugs needs to be a cultural practice within the company. All teams involved in development, including product, developers and the security team have to be committed to fixing security bugs within established time frames. That also has to be balanced with features and non-security bugs. That is where an agreed upon [SLA](https://www.cio.com/article/2438284/outsourcing-sla-definitions-and-solutions.html) for fixing security vulnerabilities is helpful.\n\n*Brendan*: I love to fix bugs - when they are easy to identify and debug and small enough to make the \"blast radius\" of a fix not too large. The best time to do that is when I’m in \"flow\" - right when I’m writing the code and have a mental model of all of the things and how they are interconnected. So that’s basically the same day or same week as when I wrote it.\n\n> With agile, quality testing has become more prominent with unit testing and CI, but security is still working its way into that workflow. – Ethan\n\nAfter that, if I find out about a bug weeks later or that is only reproducible in production, then it is extremely frustrating if not impossible to fix. Without an environment that looks like prod, or a clear understanding of *why* security sees something as a bug that I see as a nuance, it makes it much harder to fix.\n\nIf I was given the feedback I get at the end of a release cycle on the day I write the code, bugs would get fixed immediately.\n\n## Are security pros seen as too \"top down\" and \"out of touch\" with programming?\n\n*Brendan*: Oftentimes security and developers seem at odds. In many traditional organizations, this is both cultural AND related to misaligned incentives. If we only incentivize developers by the speed at which they are able to release new features while also incentivizing security professionals by number of incidents then the two are constantly at odds.\n\nThis is the same dichotomy of relationship that existed (and still does in some places) between developers and operators. If the only goal is fast feature shipping, you move fast and break things. If the only goal is a stable operating environment, then you’ll make sure no one is able to easily change or add anything.\n\nThat’s why the term \"DevOps\" was invented - to try and align incentives. Many organizations still struggle with that, but the [DORA research](https://www.devops-research.com/research.html) has shown us that the two can actually _complement_ each other if we focus on the metrics that really matter (frequency of deploys, time to fix an incident if one starts, etc.). What are those same metrics that will bring security and development together? They are probably very similar, but until organizations accept that and focus on cultural change to make sure that the teams incentives are truly aligned, it will continue to be a struggle.\n\n*Ethan*: This has not been my experience at GitLab. It really depends on how the security team was built. At GitLab, we like to believe that we’ve built a balanced team that covers the range of security skills, from lots of development experience and deep knowledge of secure coding techniques, to more dynamic security testing-oriented engineers who are working on building up their development skill set. Each of them are important to building a security program that enables and supports developers in building secure products.\n\n## Finally, will dev and sec *ever* get on the same page?\n\n*Ethan*: We need a realignment of expectations and support at all levels for developing a secure product. On the security side, the team has to realize that there will always be vulnerabilities that get to production. There is no way to catch them all. This is not only because of the fast nature of software development, but also because new attack vectors are discovered, and some things, like newly identified vulnerabilities in dependencies, are only identified after deployment. With that in mind, they should work towards providing developers the tools and data needed to identify them as early as possible, especially those vulnerabilities that are seen repeatedly. Also, there should be a well-known policy for handling vulnerabilities that are identified. That way, everyone knows what to do, and expectations are clearly defined.\n\n> If we only incentivize developers by the speed at which they are able to release new features while also incentivizing security professionals by number of incidents then the two are constantly at odds. – Brendan\n\nFrom the engineering side, it’s important to accept security as part of your development flow. It’s not glamorous, but the reason security is important is that it builds trust with customers and other stakeholders in your product. It also protects the company. Help the security team. This can be done by identifying areas of concern, asking questions, and helping security team members understand the code being written. For both teams, it’s important to have constructive communication and collaboration. There should be regular communication about what each team considers important and how that can be attained. Above all, there must be trust that the other team is doing what is best for the product.\n\n*Brendan*: Much like the last 10 years has seen businesses make themselves successful (or fail) based on their ability to deploy changes quickly and create a stable service, the next 10 years will see a similar transformation around security. The import of things like security, privacy, and data protection will require it of businesses, and those who are not able to adapt their culture will fade away. Those who have a radically different view of the world will thrive.\n\nIn the end, this is how dev and sec will \"have\" to get along.\n\n_Our [2022 Global DevSecOps Survey](/developer-survey/) is out now! Learn the latest in DevOps insights from over 5,000 DevOps professionals._\n\n*Read more about development and security*:\n\n- How [secure](/blog/soc2-compliance/) is GitLab?\n\n- How we think about [security and open source software](/blog/open-source-security/)\n\n- GitLab's guide to [safe deployment practices](/blog/safe-deploys/)\n\nCover image by [Marcus Winkler](https://unsplash.com/@markuswinkler) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[850,807,9],{"slug":1738,"featured":6,"template":698},"developer-security-divide","content:en-us:blog:developer-security-divide.yml","Developer Security Divide","en-us/blog/developer-security-divide.yml","en-us/blog/developer-security-divide",{"_path":1744,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1745,"content":1751,"config":1756,"_id":1758,"_type":13,"title":1759,"_source":15,"_file":1760,"_stem":1761,"_extension":18},"/en-us/blog/developing-a-successful-devops-strategy",{"title":1746,"description":1747,"ogTitle":1746,"ogDescription":1747,"noIndex":6,"ogImage":1748,"ogUrl":1749,"ogSiteName":685,"ogType":686,"canonicalUrls":1749,"schema":1750},"Developing a successful DevOps strategy","Here's what it takes to build a DevOps practice that works for everyone on the team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667540/Blog/Hero%20Images/devops-team-structure.jpg","https://about.gitlab.com/blog/developing-a-successful-devops-strategy","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Developing a successful DevOps strategy\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n \"datePublished\": \"2022-03-09\",\n }",{"title":1746,"description":1747,"authors":1752,"heroImage":1748,"date":1753,"body":1754,"category":757,"tags":1755},[690],"2022-03-09","Some 60% of developers are releasing code 2x faster than before, [thanks to DevOps](https://learn.gitlab.com/c/2021-devsecops-report?x=u5RjB), and a majority of respondents to our 2021 Global DevSecOps Survey said their teams develop software using DevOps or DevSecOps.\n\n[DevOps](/topics/devops/) has had a direct impact on many businesses. Here’s what it takes to develop a successful DevOps strategy.\n\n## What is DevOps?\n\nDevOps is a set of practices that combines dev and ops to create safer software faster.\n\nThe main DevOps principles are automation, [continuous integration and delivery](/topics/ci-cd/) and responding quickly to feedback. Others are agile planning, infrastructure as code (IaC), containerization and microservices. Also, building in quality assurance and security with development and operations through the application lifecycle is important. Incorporating security into a DevOps team is referred to as [DevSecOps](https://about.gitlab.com/topics/devsecops/).\n\nEnabling the speed of delivery while maintaining high software quality requires an [organizational culture shift](https://www.ibm.com/cloud/learn/devops-a-complete-guide) that automates and integrates the efforts of the development and ops teams – two groups that traditionally practiced separately from each other, or in silos.\nBut the best DevOps processes and cultures extend beyond development and operations to incorporate input from all application stakeholders – including platform and infrastructure engineering, security, compliance, governance, risk management, line-of-business, end users and customers – into the software development lifecycle. \n\n## What are the benefits of a successful DevOps strategy?\n\nA successful DevOps strategy puts the focus on the customer. It’s not enough to focus on developing good software because this approach justifies prolonged development and release deadlines. It also overlooks the most critical factor: the consumer of the software. Your customer doesn’t care much about the process – they just want a quality product that will address their problem. A successful DevOps strategy puts the team in the consumer’s shoes.\n\nAnother benefit of DevOps is that it allows a variety of teams, such as operations, security or project management, to work in an [Agile](/topics/agile-delivery/) setting. While development teams have become more Agile over the years, this occurred in isolation; operations teams have found it challenging to keep up and cannot release software at the same rate. DevOps brings these teams together and accelerates the delivery of software, while keeping the quality high.\n\nShorter development cycles with DevOps produce more frequent code releases, which in turn, makes it easier to spot code defects.\n\n## What key elements make DevOps successful?\n\nLike in most situations, **communication** is key to making a DevOps strategy successful. No business team can function without it, and that goes for a DevOps team. A good DevOps strategy incorporates feedback from developers, co-workers, and key stakeholders when building new systems.\nIT roles used to be more structured and defined, and as mentioned, professionals became used to working in silos. But DevOps has changed that model and work has become more **collaborative**. Teams now need to clearly communicate expectations, requirements and deadlines.\n\nDevOps is about a willingness to **change**. Teams must let go of some of their traditional practices and be open-minded to shifting their focus away from one deliverable and onto the next as business needs and capabilities evolve and change.\n\nTeams must also **accept failure** but not get discouraged by it. Some failure is to be expected, and the concept of [“fail fast”](https://docs.gitlab.com/ee/ci/testing/fail_fast_testing.html) (so you know there’s a problem soon enough to fix it easily) is at the heart of DevOps. They should embrace the possibilities that come from trying new techniques, and not be afraid to get creative. The top teams are those that work together, exchange ideas and push the boundaries of how they work and write more creative code.\n\n## Tips for creating a DevOps roadmap\n\nHaving a standard roadmap provides a DevOps team with a high-level, strategic blueprint of what the company envisions for the product. It’s a valuable reference point for any stakeholder during the software lifecycle. A roadmap also lets ops know when the development team will have a piece of code ready for testing.\n\nWhen creating a DevOps roadmap, make sure to clearly define the objectives and goals. Ask the team what [the collective purpose is for the roadmap](https://www.productplan.com/learn/create-a-devops-roadmap/). Objectives might include:\n\n- Improving engineering and ops teams coordination\n- Creating a single source of truth\n- Building an archive of development and release practices that people can refer to over time that are based on the most effective processes. This will help improve DevOps efforts going forward.\n\nFocused, short-term goals and plans should be established. Organizations typically plan their product roadmaps between 2 and 6 months out.\n\nA common mistake businesses make when building roadmaps is to use text only. By just using word processing documents or spreadsheets, stakeholders won’t get a clear understanding of what’s a high priority, which initiatives are dependent on others and who’s responsible for what.\n\nVisual roadmaps, complete with color-coding and bars, helps stakeholders more easily understand product plans. Roadmaps should also be kept current to reflect changes within the company’s culture and business model.\n\n## What are some common challenges associated with DevOps?\n\nChange isn’t easy and the merging of development and operations may cause a few clashes, but those involved must keep in mind that building a successful DevOps team requires this integration and collaboration between both sides. \nMake a gradual move into DevOps by starting with a small product or component and build from there.\n\nThere can also be challenges with deciding what tools to use, since there are so many available. This makes selecting a tool hard, especially if there’s a lack of knowledge about the technology behind it. Using a [DevOps platform](/topics/devops-platform/) can streamline all these choices as all of the moving parts of DevOps will be available and integrated in one single offering. \n\n[Momentum for DevOps](/blog/a-snapshot-of-modern-devops-practices-today/) is clearly growing because organizations are eager to take advantage of delivering software in shorter development cycles, while enhancing innovation in more stable operating environments and with performance-driven employee teams.",[695,9,891],{"slug":1757,"featured":6,"template":698},"developing-a-successful-devops-strategy","content:en-us:blog:developing-a-successful-devops-strategy.yml","Developing A Successful Devops Strategy","en-us/blog/developing-a-successful-devops-strategy.yml","en-us/blog/developing-a-successful-devops-strategy",{"_path":1763,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1764,"content":1770,"config":1775,"_id":1777,"_type":13,"title":1778,"_source":15,"_file":1779,"_stem":1780,"_extension":18},"/en-us/blog/devops-stakeholder-buyin",{"title":1765,"description":1766,"ogTitle":1765,"ogDescription":1766,"noIndex":6,"ogImage":1767,"ogUrl":1768,"ogSiteName":685,"ogType":686,"canonicalUrls":1768,"schema":1769},"Need DevOps buy-in? Here's how to convince stakeholders","If you need to make the case for DevOps to a non-technical crowd, it's important to be prepared. Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681597/Blog/Hero%20Images/speedphoto.jpg","https://about.gitlab.com/blog/devops-stakeholder-buyin","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Need DevOps buy-in? Here's how to convince stakeholders\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2020-09-24\",\n }",{"title":1765,"description":1766,"authors":1771,"heroImage":1767,"date":1772,"body":1773,"category":693,"tags":1774},[1325],"2020-09-24","\n\nWe know that DevOps is key to staying nimble in an increasingly competitive marketplace, but chances are your colleagues in finance or marketing aren’t as well-informed about software development.\n\nOne of the major challenges technology teams embedded in non-tech organizations face is convincing key business stakeholders to invest in cutting-edge methodologies such as [DevOps](/topics/devops/). Oftentimes, this challenge comes down to ineffective communication and misaligned incentives.\n\n\"Unfortunately, the divide between these incentives and the misalignment in these incentives is not exclusively held between developers and operators, the similar divide exists between the business and IT, in fact, in the business, they may not even be able to tell the difference between developers and operators, it's all IT to them,\" said [Nathen Harvey](https://twitter.com/nathenharvey), Developer Advocate from Google, at GitLab Virtual Commit. \"Much like from my perspective, it's just the business: finance, marketing, accounting, they all go together and blur in my head.\"\n\nThe best way to get stakeholders to buy-in to DevOps? Align incentives, think big picture, lead with empathy, and come prepared with evidence about the business value of DevOps.\n\n## Align incentives on your technology team\n\nBefore approaching the key decision-makers about investing in DevOps, make sure there is consensus among dev and ops about what direction you’re moving in. The tension between dev and ops teams is well documented: Developers tend to want greater agility, while operators want more stability.\n\n\"We turn to our developers and we say, 'Your job is to build and ship features as fast as possible, your job is agility,'\" said Nathen. \"And then we turn to our operators and we say, 'Your job (is to) make sure that the platform is stable, that nothing ever breaks.'\"\n\nThe good news is, DevOps is a way to have the best of both worlds.\n\nBefore he joined Google, Nathen worked for a retail company where his responsibility was to push the \"deploy\" button to ship new software updates every two weeks. There was a lot of ceremony around deployments, but there was also an office pool about how many of those changes would be rolled back.\n\nResearch by Google Cloud’s DevOps Research and Assessment (DORA) shows that teams that ship smaller features move faster while maintaining a more stable production environment, with numbers to prove it. When comparing the elite performers with the low performers, elite DevOps performers manage to balance speed and stability:\n\n* Deploy code 208 times more frequently\n* 106 times faster from commit to deploy\n* Changes are likely to fail just 1/7 of the time\n* 2604 times faster recovery time from incidents\n\nOnce you have developers and operators clamoring for DevOps, it’s time to move on to the next stakeholder tier.\n\n## Think about the business you work for\n\nGitLab is a software company, so we’re always thinking about new ways to deploy faster and more nimble code. If our developers found a new way to achieve this, we’re all ears. Most of our customers don't work for tech companies, but the most successful ones have found a way to make technology relevant to their business’ mission.\n\nFor example, [Delta Airlines found a way to go cloud native](/blog/delta-cloud-native/) because it fit into their mission of business agility. Whether you’re in transportation or e-commerce, business agility is something we can all agree on. Make a list of the top three priorities for your company and think about what your customers want (e.g., in the pandemic it may be an app with reliable curbside pick-up). Think about your company’s mission and business strategy and sketch out a compelling case for why DevOps will help your business edge out the competition.\n\n## Lead with empathy and think strategically\n\nBefore approaching your collaborators on the business side of things, put yourself in their shoes. Think in-depth about their motivations and goals to find the most compelling way to communicate with them.\n\nFirst, write your problem statement (e.g., \"I want to adopt a more agile DevOps strategy\"). Next, identify three key stakeholders across different teams on the business side of things (e.g., Max in Marketing, Alex in Accounting, and Lee in Legal). After that, conduct an informal thought exercise to enable more empathetic and strategic thinking:\n\n* Look at their job description. What are their core responsibilities?\n* Think about resourcing. What are their resource constraints?\n* What is their level of influence over the decision? Grade their influence on a scale of one to five (one being low influence, five being high influence)\n* How does helping your tech team be more agile impact their team’s performance and goals?\n\nIn the end, communicating with stakeholders about DevOps is all about finding common ground.\n\n## Close with evidence\n\nLet’s face it, the business side of your organization might not know the difference between a developer and an ops pro any more than you understand the intricacies of accounting, and that’s OK. So long as things aren’t broken, the gatekeepers are probably disinclined to fix it. But what if you can demonstrate just how much better things could be with a more [agile software delivery strategy](/solutions/agile-delivery/)?\n\nThe DORA team at Google created a [rigorous State of DevOps research program](https://www.devops-research.com/research.html) that assesses how different industries can improve software delivery. A simple five-question survey on five DevOps capabilities will rank your team into four tiers of performance – between low performer and elite performer.\n\nEvaluating your progress is key. Nathen's deployments at a previous employer had good \"time to restore\" rates but the fail change rate was between 16-30%, a metric that leaves a lot of room for improvement.\n\n\"We felt like we were doing really well, and in fact, we were, we had made a ton of great progress, but there were still lots of opportunities for us to improve,\" said Nathen. \"So using this quick check can help you and your team identify where are some opportunities for you to improve? How do you stand up against the others within your industry?\"\n\nIn the end, Nathen’s team ranked as a medium performer. So how does your team line-up? By coming prepared to the meeting with evidence on concrete ways a DevOps methodology can lead to more business agility, you are more likely to get the endorsement of key stakeholders on your plan.\n\n## Learn more about measuring software delivery\n\nLearn more about measuring DevOps by watching the keynote featuring Nathen and Dina Graves Portman from GitLab Virtual Commit. [Watch the other keynotes](https://www.youtube.com/playlist?list=PLFGfElNsQthYQaTiUPQcu4O0O20WHZksz), including a [presentation](https://youtu.be/xn_WP4K9dl8) by [GitLab CEO Sid Sijbrandij](/company/team/#sytses).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/yUyZExE-5TU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [CHUTTERSNAP](https://unsplash.com/@chuttersnap?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/speed?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[695,1263,9],{"slug":1776,"featured":6,"template":698},"devops-stakeholder-buyin","content:en-us:blog:devops-stakeholder-buyin.yml","Devops Stakeholder Buyin","en-us/blog/devops-stakeholder-buyin.yml","en-us/blog/devops-stakeholder-buyin",{"_path":1782,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1783,"content":1788,"config":1793,"_id":1795,"_type":13,"title":1796,"_source":15,"_file":1797,"_stem":1798,"_extension":18},"/en-us/blog/ease-pressure-on-smb-developers-with-a-devops-platform",{"title":1784,"description":1785,"ogTitle":1784,"ogDescription":1785,"noIndex":6,"ogImage":799,"ogUrl":1786,"ogSiteName":685,"ogType":686,"canonicalUrls":1786,"schema":1787},"Ease pressure on SMB developers with a DevOps platform","Small and medium-sized businesses have to be master multitaskers, but that's not always efficient. Here's how a DevOps platform can help.","https://about.gitlab.com/blog/ease-pressure-on-smb-developers-with-a-devops-platform","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Ease pressure on SMB developers with a DevOps platform\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-09-06\",\n }",{"title":1784,"description":1785,"authors":1789,"heroImage":799,"date":1790,"body":1791,"category":757,"tags":1792},[734],"2022-09-06","\nAdopting a full, end-to-end DevOps platform eases strain on IT, and that is particularly important in small and medium-sized businesses (SMBs). \n\nSince there’s generally only a handful of IT professionals – at most – working in an SMB, they’re often trying to keep their heads above water. They’re constantly in motion, moving between keeping often less than top-of-the-line systems running, acting as the user help desk, and ensuring company data is safe. They’re not only wearing multiple hats, they’re putting out one fire after another.\n\nWorking under that kind of constant pressure leaves little time and focus for developing and deploying new software, which most [every SMB needs](/blog/can-an-smb-or-start-up-be-too-small-for-a-devops-platform/) to entice new customers, build the brand, and bring in revenue. Relieving that stress and enabling these tiny IT teams to succeed in creating great software products is about survival. And IT survival is about [adopting a DevOps platform](https://learn.gitlab.com/smbmigrationguide/migratedevopssmb).\n\nRelying on a full DevOps platform empowers IT professionals and enables them to eliminate wasted time and energy so they can focus on being a business driver. There are many parts of an end-to-end DevOps platform that lead to increased efficiency and decreased pressure on the IT team:\n\n- Automate processes – from testing to performance management and monitoring – to enable IT to be hands off with repetitive and often time-consuming tasks and eliminate the potential for human error that can use up a lot of time and money.\n\n- More quickly and efficiently turn a vision into software.\n\n- [Foster collaboration](/blog/5-ways-collaboration-boosts-productivity-and-your-career/) with people across departments to brainstorm design ideas and more efficiently make iterative deployments.\n\n- [Produce more stable and secure software](/blog/toolchain-security-with-gitlab/) that won’t need last-minute fixes or code re-writes.\n\n- Focus on delivering software instead of [managing toolchains](/blog/battling-toolchain-technical-debt/).\n\n- Stop switching back and forth between multiple tool interfaces, passwords, and ways of working.\n\n- Gain an overarching view of the entire development and deployment lifecycle.\n\n- Keep track of and easily access best practices to use in new projects by taking advantage of [continuous documentation](/blog/16-ways-to-get-the-most-out-of-software-documentation/) in the platform. \n\nLike anyone, IT professionals don’t perform best when they’re in a constant reactive state. Sure, many SMBs have started to use various DevOps tools to relieve the stress on IT, but if they haven’t adopted a single platform, then they’re simply creating more expense and more work for their already overburdened IT staff. That’s because by cobbling together a mishmash of disparate tools, they’re inadvertently creating an unwieldy toolchain that slows down deployment and the business it fuels. \n\nMoving to a full DevOps platform means shedding that costly and complex toolchain, speeding the transition of business vision into working software, and cutting the workload weighing down IT. \n\nAnd relieving that workload also is about keeping employees happy and less stressed. The [greatest resource a company has is its people](/blog/hiring-in-the-deep-end-of-the-talent-pool/). This is even more true for small companies where the pain of employee dissatisfaction and departure is felt even more acutely. Managers also don’t want projects waylaid because the people driving them are leaving. To stop that from happening, it’s critical to help people get their work done efficiently and more easily, which also reduces their stress and makes them happier.\n\nAn end-to-end platform isn’t just another tool. It’s a whole new way of working that can diminish the often chaotic environment that can surround IT. An SMB’s IT people will still wear many different hats but developing and deploying new software and iterations will be easier, more efficient, and less taxing.\n",[695,9,1141],{"slug":1794,"featured":6,"template":698},"ease-pressure-on-smb-developers-with-a-devops-platform","content:en-us:blog:ease-pressure-on-smb-developers-with-a-devops-platform.yml","Ease Pressure On Smb Developers With A Devops Platform","en-us/blog/ease-pressure-on-smb-developers-with-a-devops-platform.yml","en-us/blog/ease-pressure-on-smb-developers-with-a-devops-platform",{"_path":1800,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1801,"content":1807,"config":1812,"_id":1814,"_type":13,"title":1815,"_source":15,"_file":1816,"_stem":1817,"_extension":18},"/en-us/blog/efficient-devsecops-nine-tips-shift-left",{"title":1802,"description":1803,"ogTitle":1802,"ogDescription":1803,"noIndex":6,"ogImage":1804,"ogUrl":1805,"ogSiteName":685,"ogType":686,"canonicalUrls":1805,"schema":1806},"DevSecOps basics: 9 tips for shifting left","Here's how to create an efficient DevSecOps practice and shift your security left.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663602/Blog/Hero%20Images/efficient-devsecops-9-tips.jpg","https://about.gitlab.com/blog/efficient-devsecops-nine-tips-shift-left","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"DevSecOps basics: 9 tips for shifting left\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n \"datePublished\": \"2020-06-23\",\n }",{"title":1802,"description":1803,"authors":1808,"heroImage":1804,"date":1809,"body":1810,"category":693,"tags":1811},[887],"2020-06-23","\n_This is the first in a five-part series on getting started with [DevSecOps](/topics/devsecops/). Part two outlines the steps needed to create [silo-free collaboration](/blog/achieve-devsecops-collaboration/). Part three looks at the importance of [automated security testing](/blog/devsecops-security-automation/). And part four explains how to [build a strong security culture](/blog/security-culture-devsecops/) to support your DevSecOps efforts._\n\nSpeed is required to stay competitive – nearly 83% of our [2020 Global DevSecOps Survey](/developer-survey/) respondents said they’re releasing code faster than ever with DevOps. With the pace of work accelerating, some important details are easily overlooked or underestimated – like security. \n\nThink back to the last several projects your team has launched. Did security testing begin late in your software development lifecycle (SDLC)? Was too much time wasted on friction between siloed development and security? Was the project delayed due to inefficient handoff between teams, lack of visibility across systems, or lack of planning and consideration?\n\nAll of these are symptoms of outdated security practices trying to fit into your DevOps or Agile methodologies. Upgrade your organization to DevSecOps by [shifting left](/topics/ci-cd/shift-left-devops/): Bring security to the front of your development pipeline. \n\n## Security is changing – with a long way to go\n\nSecurity respondents in our 2020 Global DevSecOps Survey report changes in their roles: Being increasingly included as part of a cross-functional team focused on security (27.73%), becoming more involved in the day-to-day/more hands on (26.94%), and focusing more on compliance (22.55%). Only 19.95% report that their role is not changing.\n\nIt’s evident that companies are beginning to shift their security practices, but security testing remains a source of frustration: Over 42% of survey respondents said that testing happens too late in the lifecycle. This may be due to conflicting opinions on who is responsible for security. Nearly 33% of respondents said the security team is responsible, while almost as many people (29%) said that everyone was responsible. \n\nHowever, it’s difficult for everyone to be responsible when developers aren’t provided with the proper tools and resources to assess the security of their code: Surprisingly, static [application security](/topics/devsecops/) testing (SAST) is still not a common developer tool: Less than 19% of companies surveyed in this year’s DevSecOps report put SAST scan results into a pipeline report that developers can access, and over 60% of developers don’t actually run SAST scans. \n\n## The importance of collaboration between security and development teams \n\nSecurity is a top priority in DevOps methodology because security breaches are troublesome and expensive, and the threats are persistent. Historically dev and sec [have not gotten along](/blog/developer-security-divide/), and when communication between groups is poor, it can be easier for security vulnerabilities to take hold. Also, dev and sec [rarely agree on who owns security](/blog/gitlabs-2022-global-devsecops-survey-security-is-the-top-concern-investment/), which is a problem seen time and again in GitLab’s Annual DevSecOps Surveys.\n\nOur survey isn’t the only one finding strife between the teams. The [Ponemon Institute Research report](https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.zeronorth.io%2Fresource%2Fponemon-report-revealing-the-cultural-divide-between-application-security-and-development%2F&data=04%7C01%7CHeather.Rubash%40netspi.com%7C5db8edd20731475c73e908d8868a4116%7C47bfc77a6733477ba2b2ecf6b199e835%7C0%7C0%7C637407275653430081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=l7TP5PRZjCs1PqCV6JBrPVNMFQuLyBt%2BIOot6rUb5gw%3D&reserved=0) indicated that 71 percent of AppSec professionals believe security isn’t taken seriously by devs; specifically, they believe developers aren’t building in security at a sufficiently early stage. \n\nBut, when security and development teams collaborate early and often on security scanning for their code, there are a number of improvements, including:\n\n- Improved code quality \n- Fewer time-consuming and costly fixes\n- Full visibility of security measures for the whole organization\n- Minimized risk of security breaches\n- Top-notch security testing\n\nSecurity tools and automation can only take teams so far. There is no “set it and forget it” option when it comes to security. There needs to still be a human at the wheel. Collaboration between development and security teams needs to be as much of a priority as security itself. DevSecOps needs to be a culture, not just a practice.\n\nTo remove team siloes around security, here are a few considerations:\n\n1. **Understand what is driving each respective team.** The motivations behind the choices significantly affect how DevSecOps efforts turn out. \n2. **Do the big things together.** Auditing existing security tools, processes, and places where automation is or isn’t in place should be a group effort, not an individual team effort.\n3. **Define security objectives and responsibilities at every stage of the SDLC.** Early scanning and testing are vital to security, and everyone can be part of checking that these security checks are happening. \n4. **Plan and execute a comprehensive security training plan.** Have clear guidelines on security goals and steps to follow in case of an active threat. \n5. **Consider creating a [security champions program](/blog/why-security-champions/).**\n\n### Key to efficient security: Clarity\n\nCommunication cannot be understated when it comes to shifting left. Moving security forward in the software lifecycle won’t help anyone if your team doesn’t understand their responsibilities and expectations. Document any and all role changes when shifting your security practices, and then make sure that all parties have the tools necessary to get the job done. \n\n## What is shifting left?\n\nShift left is a DevOps testing concept to speed up development while at the same time improving code quality. Think of the code development process as starting on the “left” with development and ending on the “right” with deployment, so shifting the testing stage left means moving it from the end of the process to close to the beginning. Shifting left is made far easier with test automation.\n\n### 3 Important reasons to shift left\n\n1. **More code gets tested.** By bringing security forward in the SDLC, you provide more opportunities for code to be scanned and vulnerabilities to be remediated. By automating static application security testing (SAST) at every code commit, for example, you can at least ensure that all code has been scanned once.\n1. **Planning becomes more well-rounded.** Shifting left is not just about technology – it’s also about people. Bring a security DRI into your initial planning meeting to make sure you account for security needs in all stages of the SDLC. This will help streamline end-of-cycle security reviews, reduce friction between teams, and increase the likelihood of hitting your deadline with a secure product.\n1. **Better accountability among non-security team members.** Shifting left lets your team know that everyone is now expected to take security seriously and make it a part of their daily work. \n\n## 9 Tips for efficient DevSecOps\n\n1. Measure time lost in dealing with vulnerabilities after code is merged. Next, look for a pattern in the type or source of those security vulnerabilities, and make adjustments for improvement.\n2. Identify pain points and software risks between development and security, create a plan to resolve them, and then execute on that plan. \n3. Make small code changes. Smaller updates are easier to review and secure and can be launched more quickly than monolithic project changes.\n4. Automate and integrate security scans. Make scans ubiquitous so that every secure code change is reviewed and security flaws are found at their source of creation.\n5. Build security scans into the developer's workflow. Integrated security enables developers to find and fix vulnerabilities before the code ever leaves their hands. This also reduces the volume of open-source vulnerabilities sent to the security team, streamlining their review.\n6. Give developers access to SAST and DAST reports. While this is important for remediation, it's also a valuable tool to help developers build secure coding practices.\n7. Reduce or eliminate any waterfall-style security processes within your SDLC. You should always be able to change direction as needs arise: Keep your organization and your security controls nimble.\n8. Give the security team visibility into both resolved and unresolved vulnerabilities in code, where the vulnerabilities reside, who created them, and their status for remediation.\n9. Streamline your toolchain so that employees can focus their attention on a single interface: A single source of truth.\n\n_How efficient are your DevSecOps practices? [Take our DevSecOps Maturity Assessment to find out.](https://about.gitlab.com/resources/devsecops-methodology-assessment/)_\n\n**Learn more about DevSecOps:**\n\n[How to harden your GitLab instance](/blog/gitlab-instance-security-best-practices/)\n\n[Make your toolchain more secure](/blog/toolchain-security-with-gitlab/)\n\n[Our goals with Zero Trust](/blog/zero-trust-at-gitlab-problems-goals-challenges/)\n\nCover image by [Marc Sendra Martorell](https://unsplash.com/@marcsm) on [Unsplash](https://unsplash.com/photos/-Vqn2WrfxTQ)\n{: .note}\n",[891,9,695,807],{"slug":1813,"featured":6,"template":698},"efficient-devsecops-nine-tips-shift-left","content:en-us:blog:efficient-devsecops-nine-tips-shift-left.yml","Efficient Devsecops Nine Tips Shift Left","en-us/blog/efficient-devsecops-nine-tips-shift-left.yml","en-us/blog/efficient-devsecops-nine-tips-shift-left",{"_path":1819,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1820,"content":1826,"config":1831,"_id":1833,"_type":13,"title":1834,"_source":15,"_file":1835,"_stem":1836,"_extension":18},"/en-us/blog/eight-steps-to-prepare-your-team-for-a-devops-platform-migration",{"title":1821,"description":1822,"ogTitle":1821,"ogDescription":1822,"noIndex":6,"ogImage":1823,"ogUrl":1824,"ogSiteName":685,"ogType":686,"canonicalUrls":1824,"schema":1825},"8 Steps to prepare your team for a DevOps platform migration","Getting teams ready enables them to migrate with more confidence and ease. Here's how to get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663786/Blog/Hero%20Images/craftsman-looks-at-continuous-integration.jpg","https://about.gitlab.com/blog/eight-steps-to-prepare-your-team-for-a-devops-platform-migration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"8 Steps to prepare your team for a DevOps platform migration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-08-16\",\n }",{"title":1821,"description":1822,"authors":1827,"heroImage":1823,"date":1828,"body":1829,"category":757,"tags":1830},[734],"2022-08-16","\nWhen organizations are getting ready to [move to a DevOps platform](https://page.gitlab.com/migrate-to-devops-guide.html), taking the time to get IT teams prepped for the migration will mean people can make the transition with more confidence and efficiency.\n\nBy [replacing a complicated mix of DevOps tools](/topics/devops/use-devops-platform-to-avoid-devops-tax/) with a single, end-to-end DevOps platform, you are about to change the way people work in a fundamental way. That will bring many benefits, like cutting tool-management costs, [increasing security](/blog/one-devops-platform-can-help-you-achieve-devsecops/), speeding software creation and deployment, and [replacing silos with a collaborative environment](/blog/5-ways-collaboration-boosts-productivity-and-your-career/). But any kind of change can create anxiety. By reaching out to people as part of your migration prep, managers can calm those stresses, create champions for the adoption, and ease the work that’s to come. \n\nLet’s look at what IT leaders can do to ease this transition for everyone.\n\n## Build buy-in\n\nStarting at the VP and CIO level, create organization-wide buy-in for this migration. This will be a wide-reaching project so everyone from the C-suite on down needs to be on board. Help them understand the importance of making this move. It’s not about adding a new tool – it’s about improving the way software development works overall, so make sure everyone is invested _from the beginning_. “Management and DevOps teams both need to understand that not migrating will ultimately take up more time and energy because they’d be forced to continue time-consuming glue work and duct taping to keep the toolchain stitched together,\" says [Brendan O’Leary](/company/team/#brendan), staff developer evangelist at GitLab. “People will be doing a lot less of that after a migration.”\n\n> Join us at [GitLab Commit 2022](/events/commit/) and connect with the ideas, technologies, and people that are driving DevOps and digital transformation.\n\n## Find champions\n\nEarly in the process, find your innovators and migration champions. Talk with people on every team to figure out who is excited about adopting a DevOps platform. These people will be critical. Empower them to lead the charge by allowing them to be the first to migrate with your full, visible support. Then their migration successes will serve as inspiration for those less excited to make the move.\n\n## Ease tension\n\nRemember that change makes people nervous and be sensitive to that. Get ahead of any anxieties by laying out how continuing on with their existing (and ever-expanding) [toolchains will only suck up more of their time and efforts](/blog/the-journey-to-a-devops-platform/) because they’ll have to remain focused on juggling a tangle of tools, instead of actually turning plans into software. Toolchains are not the fun part of their jobs, and they’ll be letting go of that.\n\n## Set expectations\n\nTalk with workers about what this will mean for them individually. Reassure them that this does not mean their jobs will be eliminated. However, it will change their day-to-day responsibilities since they’ll be doing less feeding and watering of disparate tools. That will give them more time to take on bigger, more valuable and more interesting projects. Developers, in particular, want to [work on projects that matter](/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen/). Decreasing the toolchain red tape will be a huge step towards increased job satisfaction. \n\n## Define roles\n\nNot everyone on every team will work on the migration. Some will need to keep software development and deployment moving along, while others work on the adoption. Make it clear to individual team members what their roles will be. They’ll automatically be more at ease if it’s clear what their migration responsibilities will be.\n\n## Plan for training\n\nAssure everyone there will be training. They won’t just be thrown into the deep end of the pool. Make sure they know you will be setting them up for success.\n\n## Create sample projects\n\n[Fatima Sarah Khalid](/company/team/#sugaroverflow), a developer evangelist at GitLab, says that even before a migration even begins, managers should ensure their team members are ready to use a DevOps platform to do everything from planning to testing, and pushing software iterations through to production. “Managers should think about having a sample project set up with issues and epics. Set up workflows and merge requests. Run it all through,” says Khalid. “Getting hands-on experience before the migration will get rid of anyone’s fear that they’ll break something.”\n\n## Lay out the benefits\n\nMake sure everyone understands the benefits of using a DevOps platform:\n\n- Your business will be able to quickly, securely, and efficiently turn a vision into software.\n\n- Working in isolated silos will be replaced with working in tandem with teammates, [collaborating, and sharing information and responsibilities](/blog/if-its-time-to-learn-devops-heres-where-to-begin/).\n\n- A single application will give an overarching view of projects, enabling teams to check in on, comment on and offer suggestions on projects as they move through the development lifecycle.\n\n- Security and compliance will increase as it will be built into every step of the development and deployment lifecycle.\n\n- [Built-in automation](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/) will reduce repetitive hands-on work with everything from testing to documentation.\n\nBy preparing teams to make the move to a DevOps platform, the entire migration process will be easier and more efficient. For more information on transitioning to an end-to-end platform, [check out this ebook](https://page.gitlab.com/migrate-to-devops-guide.html).\n",[695,108,9],{"slug":1832,"featured":6,"template":698},"eight-steps-to-prepare-your-team-for-a-devops-platform-migration","content:en-us:blog:eight-steps-to-prepare-your-team-for-a-devops-platform-migration.yml","Eight Steps To Prepare Your Team For A Devops Platform Migration","en-us/blog/eight-steps-to-prepare-your-team-for-a-devops-platform-migration.yml","en-us/blog/eight-steps-to-prepare-your-team-for-a-devops-platform-migration",{"_path":1838,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1839,"content":1845,"config":1851,"_id":1853,"_type":13,"title":1854,"_source":15,"_file":1855,"_stem":1856,"_extension":18},"/en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces",{"title":1840,"description":1841,"ogTitle":1840,"ogDescription":1841,"noIndex":6,"ogImage":1842,"ogUrl":1843,"ogSiteName":685,"ogType":686,"canonicalUrls":1843,"schema":1844},"Enable secure sudo access for GitLab Remote Development workspaces","Learn how to allow support for sudo commands using Sysbox, Kata Containers, and user namespaces in this easy-to-follow tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675033/Blog/Hero%20Images/blog-image-template-1800x945.png","https://about.gitlab.com/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Enable secure sudo access for GitLab Remote Development workspaces\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vishal Tak\"}],\n \"datePublished\": \"2024-11-20\",\n }",{"title":1840,"description":1841,"authors":1846,"heroImage":1842,"date":1848,"body":1849,"category":807,"tags":1850},[1847],"Vishal Tak","2024-11-20","A development environment often requires sudo permissions to install, configure, and use dependencies during runtime. GitLab now allows secure sudo access for [GitLab Remote Development workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/). This tutorial shows you how to enable GitLab workspace users to securely use sudo commands to perform common tasks.\n\n## The challenge\n\nFor the sake of this article, say your project is as simple as the below code.\n\n```\npackage main\n\nimport (\n\t\"encoding/json\"\n\t\"log/slog\"\n\t\"net/http\"\n\t\"os\"\n)\n\nfunc main() {\n\t// Set up JSON logger\n\tlogFile, err := os.OpenFile(\"server.log\", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tdefer logFile.Close()\n\n\tjsonHandler := slog.NewJSONHandler(logFile, nil)\n\tlogger := slog.New(jsonHandler)\n\tslog.SetDefault(logger)\n\n\t// Define handlers\n\thttp.HandleFunc(\"/path1\", handleRequest)\n\thttp.HandleFunc(\"/path2\", handleRequest)\n\n\t// Start server\n\tslog.Info(\"Starting server on :3000\")\n\terr = http.ListenAndServe(\":3000\", nil)\n\tif err != nil {\n\t\tslog.Error(\"Server failed to start\", \"error\", err)\n\t}\n}\n\nfunc handleRequest(w http.ResponseWriter, r *http.Request) {\n\tdata := make(map[string]interface{})\n\tfor k, v := range r.Header {\n\t\tdata[k] = v\n\t}\n\n\tdata[\"method\"] = r.Method\n\tdata[\"url\"] = r.URL.String()\n\tdata[\"remote_addr\"] = r.RemoteAddr\n\n\tresponse, err := json.MarshalIndent(data, \"\", \" \")\n\tif err != nil {\n\t\tslog.Error(\"Failed to marshal metadata\", \"error\", err)\n\t\thttp.Error(w, \"Internal Server Error\", http.StatusInternalServerError)\n\t\treturn\n\t}\n\n\t// Log the metadata\n\tslog.Info(\"Request received\",\n\t\t\"path\", r.URL.Path,\n\t\t\"response\", string(response),\n\t)\n\n\t// Write response\n\tw.Header().Set(\"Content-Type\", \"application/json\")\n\tw.Write(response)\n}\n```\n\nThis code starts an HTTP server on port 3000, exposes two paths: `path1` and `path2`. Each HTTP request received is logged to a file `server.log`.\n\nLet's run this code with `go run main.go` and generate some requests.\n\n```\ni=1\nwhile [ \"$i\" -le 100 ]; do\n echo \"Iteration $i\"\n\n if [ $((random_number % 2)) -eq 0 ]; then\n curl \"localhost:3000/path1\"\n else\n curl \"localhost:3000/path2\"\n fi\n\n i=$((i + 1))\ndone\n```\n\nAs you work on this application, you realize the need to analyze the logs to debug an issue. You look at the log file and it is long to parse with a simple glance. You remember there is a handy tool, [jq](https://jqlang.github.io/jq/), which parses JSON data. But your workspace does not have it installed.\n\nYou want to install `jq` through the package manager for this workspace only.\n\n```\nsudo apt update\nsudo apt install jq\n```\n\nThe output is:\n\n```\nsudo: The \"no new privileges\" flag is set, which prevents sudo from running as root.\nsudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.\n```\n\nThis happens because GitLab workspaces explicitly disallows `sudo` access to prevent privilege escalation on the Kubernetes host.\n\nNow, there is a more secure way to run `sudo` commands in a workspace.\n\n## How sudo access works\n\nThat is exactly what we have [unlocked](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace) in the 17.4 release of GitLab.\n\nYou can configure secure sudo access for workspaces using any of the following options:\n\n- Sysbox \n- Kata Containers \n- User namespaces\n\nWe will set up three GitLab agents for workspaces to demonstrate each option.\n\n### Sysbox\n\n[Sysbox](https://github.com/nestybox/sysbox) is a container runtime that improves container isolation and enables containers to run the same workloads as virtual machines.\n\nTo configure sudo access for a workspace with Sysbox:\n\n1. In the Kubernetes cluster, [install Sysbox](https://github.com/nestybox/sysbox#installation).\n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n enabled: true\n dns_zone: \"sysbox-update.me.com\"\n default_runtime_class: \"sysbox-runc\"\n allow_privilege_escalation: true\n annotations:\n \"io.kubernetes.cri-o.userns-mode\": \"auto:size=65536\"\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings. \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information. \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\n### Kata Containers\n\n[Kata Containers](https://github.com/kata-containers/kata-containers) is a standard implementation of lightweight virtual machines that perform like containers but provide the workload isolation and security of virtual machines.\n\nTo configure sudo access for a workspace with Kata Containers:\n\n1. In the Kubernetes cluster, [install Kata Containers](https://github.com/kata-containers/kata-containers/tree/main/docs/install). \n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n enabled: true\n dns_zone: \"kata-update.me.com\"\n default_runtime_class: \"kata-qemu\"\n allow_privilege_escalation: true\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings. \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information. \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\n### User namespaces\n\n[User namespaces](https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/) isolate the user running inside the container from the user on the host.\n\nTo configure sudo access for a workspace with user namespaces:\n\n1. In the Kubernetes cluster, [configure user namespaces](https://kubernetes.io/blog/userns-beta/). \n2. In the GitLab agent for workspaces, set the following config:\n\n```\nremote_development:\n enabled: true\n dns_zone: \"userns-update.me.com\"\n use_kubernetes_user_namespaces: true\n allow_privilege_escalation: true\n```\n\n3. Add other settings in the agent config as per your requirements. [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for more information about individual settings. \n4. Allow the agent to be used for workspaces in a group. See the [documentation](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#allow-a-cluster-agent-for-workspaces-in-a-group) for more information. \n5. Update GitLab Workspaces Proxy to serve traffic for the domain used in the above agent configuration. See [Tutorial: Set up the GitLab workspaces proxy](https://docs.gitlab.com/ee/user/workspace/set_up_workspaces_proxy.html) for more information.\n\nSetting up a Kubernetes cluster with user namespaces configured is challenging since it is behind a beta feature gate in Kubernetes Version 1.31.0. This means it is not yet possible to configure such a cluster on the major cloud providers because they don't provide a mechanism to enable feature gates in their managed Kubernetes offering. Here is an example of [configuring a simple Kuberenetes cluster using `kubeadm`](https://gitlab.com/gitlab-org/gitlab/-/issues/468290#note_1959300036).\n\n### Create a workspace\n\nIf you now create a workspace with these agents and try installing `jq` through a package manager, it should succeed!\n\nYou can analyze the logs using `jq`. Say you wanted to inspect the log entries where the path is `/path1`, you can run:\n\n```\njq 'select(.path == \"/path1\")' server.log\n```\n\nThe output is:\n\n```\n{\n \"time\": \"2024-10-31T12:04:38.474806+05:30\",\n \"level\": \"INFO\",\n \"msg\": \"Request received\",\n \"path\": \"/path1\",\n \"response\": \"{\\n \\\"Accept\\\": [\\n \\\"*/*\\\"\\n ],\\n \\\"User-Agent\\\": [\\n \\\"curl/8.7.1\\\"\\n ],\\n \\\"method\\\": \\\"GET\\\",\\n \\\"remote_addr\\\": \\\"[::1]:61246\\\",\\n \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n{\n \"time\": \"2024-10-31T12:06:22.397453+05:30\",\n \"level\": \"INFO\",\n \"msg\": \"Request received\",\n \"path\": \"/path1\",\n \"response\": \"{\\n \\\"Accept\\\": [\\n \\\"*/*\\\"\\n ],\\n \\\"User-Agent\\\": [\\n \\\"curl/8.7.1\\\"\\n ],\\n \\\"method\\\": \\\"GET\\\",\\n \\\"remote_addr\\\": \\\"[::1]:61311\\\",\\n \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n{\n \"time\": \"2024-10-31T12:19:34.974354+05:30\",\n \"level\": \"INFO\",\n \"msg\": \"Request received\",\n \"path\": \"/path1\",\n \"response\": \"{\\n \\\"Accept\\\": [\\n \\\"*/*\\\"\\n ],\\n \\\"User-Agent\\\": [\\n \\\"curl/8.7.1\\\"\\n ],\\n \\\"method\\\": \\\"GET\\\",\\n \\\"remote_addr\\\": \\\"[::1]:61801\\\",\\n \\\"url\\\": \\\"/path1\\\"\\n}\"\n}\n```\n\n## Get started today\n\nLearn even more with our [Configure sudo access for a workspace documentation](https://docs.gitlab.com/ee/user/workspace/configuration.html#configure-sudo-access-for-a-workspace). See [GitLab agent for workspaces settings](https://docs.gitlab.com/ee/user/workspace/gitlab_agent_configuration.html#workspace-settings) for details on individual settings.\n\n> New to GitLab Remote Development? Here is a [quickstart guide](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) to get you up to speed.",[807,828,1097,495,9],{"slug":1852,"featured":90,"template":698},"enable-secure-sudo-access-for-gitlab-remote-development-workspaces","content:en-us:blog:enable-secure-sudo-access-for-gitlab-remote-development-workspaces.yml","Enable Secure Sudo Access For Gitlab Remote Development Workspaces","en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces.yml","en-us/blog/enable-secure-sudo-access-for-gitlab-remote-development-workspaces",{"_path":1858,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1859,"content":1865,"config":1871,"_id":1873,"_type":13,"title":1874,"_source":15,"_file":1875,"_stem":1876,"_extension":18},"/en-us/blog/enforcing-managing-2fa-support-security",{"title":1860,"description":1861,"ogTitle":1860,"ogDescription":1861,"noIndex":6,"ogImage":1862,"ogUrl":1863,"ogSiteName":685,"ogType":686,"canonicalUrls":1863,"schema":1864},"This is what happens if you lose access to your 2FA GitLab.com account","Support Engineering Manager Lyle Kozloff explains why we no longer accept government ID for two-factor authentication removal.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666816/Blog/Hero%20Images/security-cover.png","https://about.gitlab.com/blog/enforcing-managing-2fa-support-security","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"This is what happens if you lose access to your 2FA GitLab.com account\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lyle Kozloff\"}],\n \"datePublished\": \"2018-10-08\",\n }",{"title":1860,"description":1861,"authors":1866,"heroImage":1862,"date":1868,"body":1869,"category":300,"tags":1870},[1867],"Lyle Kozloff","2018-10-08","\nYou may have read my previous post about [how to keep your GitLab account safe and accessible](/blog/keeping-your-account-safe/). That came about because the Support Team recently changed how we verify your identity when you lose access to your GitLab.com account and request that the [two-factor authentication (2FA)](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) be reset. This was a collaborative effort between our Support and Security teams, and I wanted to share our updated, more secure process.\n\nUp until recently, the procedure for regaining access to your account started with resetting with an [SSH key](https://docs.gitlab.com/ee/user/ssh.html). Many users didn't have one registered, so the standard fallback for proving your identity was to provide your government-issued ID for verification. This is fairly common, but has a couple of drawbacks:\n\n- Many GitLab users don't use their real names on their GitLab accounts, so \"@elitehacker,\" for example, would have a pretty hard time proving their identity that way.\n- Also, GitLab, unlike other companies, doesn't use an independent verification service to assess these IDs. I don't even know what an Illinois driver's license looks like, let alone one issued by a country I've never been to. So there's a risk that our team wouldn't be able to identify fraudulent IDs.\n\n## How we authenticate users without using government ID\n\nWith this in mind, we started discussing ways to authenticate users that didn't rely on government-issued ID. I chatted to [Westley](/company/team/#wvandenberg) on the Security team, and got some insight into different approaches he had seen when he previously worked at Amazon. This is what the process looks like now:\n\n### Step 1: Determine risk factor\n\nThe first step is to classify the data we're potentially granting access to if we reset 2FA. There's a vast difference in risk between effectively granting access to thousands of private repositories which look like they contain secret government data, and granting access to a handful of tutorials on Angular that are public. So we came up with four different classifications based on what a user would get access to if we reset their 2FA – you can check out [the first iteration of these in the discussion in the issue](https://gitlab.com/gitlab-com/security/issues/45). This is a peer-reviewed process, so there will always be another agent confirming that the classification looks appropriate.\n\n### Step 2: Pose authentication challenges\n\nTogether Westley and I came up with a series of challenges the Support Team can pose to users who have lost access, which require knowledge and familiarity with the user's account. These challenges are given scores, and depending on what classification your account is given, there will be a minimum score you need to attain in order for us to reset your 2FA. The set of challenges posed is selected by the agent handling the ticket, and it may differ each time.\n\nThere's no one, single factor that will get you into your account – the spirit is rather that you can build a body of evidence to verify your identity, rather than relying on one thing (which used to be the case with the government ID). If you succeed in the challenges, we will reset your 2FA so you can get back into your account.\n\nThese challenges aren't made public – we're not going to give away exactly what you need to access a 2FA account, obviously 😆 We'll keep [iterating](https://handbook.gitlab.com/handbook/values/#iteration) on them too.\n\nAs mentioned, this new workflow is really a result of collaboration between Support and Security. Having identified that our existing process was less than ideal, we asked for an audit of our proposal from Security, to get their stamp of approval and ensure that we were leveraging our internal resources to keep our users' accounts safe. You can [check out the issue for this consultation with Security here](https://gitlab.com/gitlab-com/security/issues/45) for the full discussion.\n\nTo avoid resetting your 2FA altogether, here's [how to keep your GitLab account safe and accessible](/blog/keeping-your-account-safe/).\n",[9,934,807],{"slug":1872,"featured":6,"template":698},"enforcing-managing-2fa-support-security","content:en-us:blog:enforcing-managing-2fa-support-security.yml","Enforcing Managing 2fa Support Security","en-us/blog/enforcing-managing-2fa-support-security.yml","en-us/blog/enforcing-managing-2fa-support-security",{"_path":1878,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1879,"content":1884,"config":1890,"_id":1892,"_type":13,"title":1893,"_source":15,"_file":1894,"_stem":1895,"_extension":18},"/en-us/blog/engineering-managers-automate-their-jobs",{"title":1880,"description":1881,"ogTitle":1880,"ogDescription":1881,"noIndex":6,"ogImage":1131,"ogUrl":1882,"ogSiteName":685,"ogType":686,"canonicalUrls":1882,"schema":1883},"How GitLab automates engineering management","At GitLab we know automation is engineering's best friend. Here's a deep\ndive into three scripts we use regularly to keep big projects on track.","https://about.gitlab.com/blog/engineering-managers-automate-their-jobs","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab automates engineering management\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Seth Berger\"}],\n \"datePublished\": \"2021-11-16\",\n }",{"title":1880,"description":1881,"authors":1885,"heroImage":1131,"date":1887,"body":1888,"category":300,"tags":1889},[1886],"Seth Berger","2021-11-16","As an engineer, figuring out how to automate your work becomes an important\naspect of your job. From writing powerful dotfiles, to customizing bash\nscripts, to writing robust and rigorous tests, engineers regularly look for\nways to automate their repetitive work. \n\n\nAt GitLab, engineering managers are no different and are constantly looking\nfor ways to automate their work. I asked engineering managers at GitLab to\nshare their automation scripts and their responses were overflowing. \n\n\nFrom automating their [1:1 document\ncreation](https://www.youtube.com/watch?v=gqFbZi8Hyoc), to integrating\n[GitLab with Google Sheets](https://gitlab.com/-/snippets/2200407), to\nwriting utilities to [provide executive\nsummaries](https://gitlab.com/gitlab-org/secure/tools/report-scripts),\nGitLab team members take advantage of the [rich API that\nGitLab](https://docs.gitlab.com/ee/api/) provides to organize the mountains\nof information that they sort through on a regular basis. \n\n\nFor this blog post, I’m sharing a\n[repo](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries) that\ncontains just a few of the many scripts that our team members use. These\nscripts were originally written by engineering manager [Rachel\nNienaber](/company/team/#rnienaber). Rachel’s Infrastructure team is tasked\nwith the exciting work of coordinating large scale infrastructure and code\nimprovements. The work involves coordinating and sequencing lots of issues\nand epics, and ensuring the work gets done at just the right time and in the\nright order. Because of the breadth and scale of the work, she has created a\nhandful of scripts that parse issues and epics in order to gain better\nvisibility into the work that needs to be done. \n\n\nIn the repo, there are three scripts. I’ll provide a quick overview of the\nfirst two, and then dive into the code on the last one. \n\n\n* [Issues not in epics\n](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/master/issues_not_in_epics.rb)\n\n* [Epic\nsummary](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/master/epic_summary.rb)\n\n* [Epic/Issue relationship\n](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/master/epic_issue_relationships.rb)\n\n\n**Issues not in epics**\n\n\nSince the Infrastructure team leans on\n[epics](https://docs.gitlab.com/ee/user/group/epics/) to organize their\nissues, they also want to be able to organize work that may not be part of\nan epic. The\n[`issues_not_in_epics.rb`](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/master/issues_not_in_epics.rb)\nscript iterates through issues not in an epic and updates the description of\na single hard-coded\n[issue](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/538)\nwith a table summarizing those issues. The script is run on a daily basis\nvia a scheduled pipeline. This ensures that issues do not slip through the\ncracks. \n\n\n**Epic summary**\n\n\nThis script,\n[`epic_summary.rb`](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/master/epic_summary.rb),\nwas written to solve the problem of having to look in multiple places to\nunderstand the status of each project. By grouping all status information\ninto one place it’s easy to see what the team is working on, and what\nprojects will be coming up next. \n\n\nAs input it takes a designated epic ID and updates the description of that\nepic by crawling sub-epics and extracting the following data from those\nepics:\n\n\n* The person responsible for delivering a sub-epic (at GitLab we use the\nterm [Directly Responsible Individual or\nDRI](/handbook/people-group/directly-responsible-individuals/))\n\n* The latest status update for the epic as inputted by an engineer in an\nepic description\n\n* The number of sub-epics\n\n* Links to a board showing the issues constituting that epic\n\n\nYou can see an example of the output from the script on this\n[epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/148).\n\n\nPart of what makes this script simple is that the Infrastructure team always\nupdates the bottom of all their epic descriptions with the following\nmarkdown.\n\n\n```markdown\n\n## Status {DATE}\n\n{commentary of the status}\n\n```\n\n\nBy consistently using that very simple markdown, the following snippet of\ncode can reliably extract the status for each epic:\n\n\n```rb\n if description!= nil && description.index(\"## Status\")\n\n end_location = description.length\n\n if description.index(\"mermaid\")\n end_location = description.index(\"mermaid\")-6\n end\n\n status = description[description.index(\"## Status\")+10..end_location]\n end\n```\n\n\nThe code above certainly won’t win any algorithm challenges, but that’s kind\nof the point and what we aim to do with [boring\nsolutions](/blog/boring-solutions-faster-iteration/). \n\n\nYou’ll notice the code above adjusts what is parsed to exclude a mermaid\ndiagram that might appear after the `## Status` markdown. That diagram gets\nmaintained with the\n[epic_issue_relationship.rb](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/master/epic_issue_relationships.rb)\nscript. \n\n\n**Epic issue relationship**\n\n\nThis script updates either a specific epic or all epics, depending on the\ncommand line option, with a [mermaid\ndiagram](https://mermaid-js.github.io/) that shows the relationship between\nissues and the order that those issues need to be completed by examining how\nthey are related to one another. Adding a mermaid diagram to the description\nwas introduced by [Sean McGivern](/company/team/#smcgivern), a staff\nengineer on the Scalability team. It creates brilliant diagrams like this\none from this\n[epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/579).\n\n\n![Mermaid\nDiagram](https://about.gitlab.com/images/blogimages/2021-11-16-engineering-managers/issue_relation.png)\n\n\nLet’s walk through the code.\n\n\nThe script uses the Docopt gem to parse and accept several input\nparameters. \n\n\n```rb\n\noptions = Docopt::docopt(docstring)\n\ntoken = options.fetch('--token')\n\ngroup_id = options.fetch('--groupid')\n\nepic_id = options.fetch('--epicid', nil)\n\ndry_run = options.fetch('--dry-run', false)\n\n```\n\nThen a connection to the GitLab instance is created, taking advantage of the\n[GitLab gem](https://github.com/NARKOZ/gitlab) which is extended in\n[`lib/gitlab_client/epics.rb`](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/main/lib/gitlab_client/epics.rb)\nto include a few extra methods. \n\n\n```rb\n\nGitlab.configure do |config|\n config.endpoint = 'https://gitlab.com/api/v4'\n config.private_token = token\nend\n\n```\n\n\nIf an epic id is passed in, then the `update_mermaid` will run only for a\nspecific epic. Otherwise, the code searches for epics that match the two\nlabels, `workflow-infra::In Progress` and `team::Scalability` and are also\n`opened`. Only when the matching epics do not have child epics, is\n`update_mermaid` run. \n\n\n```rb\n\nif epic_id\n update_mermaid(token: token, group_id: group_id, epic_id: epic_id, dry_run: dry_run)\nelse\n Gitlab.epics(group_id, 'workflow-infra::In Progress,team::Scalability', options: { state: 'opened' }).each do |epic|\n if Gitlab.epic_epics(epic['group_id'], epic['iid']).count == 0\n update_mermaid(token: token, group_id: group_id, epic_id: epic['iid'], dry_run: dry_run)\n end\n end\nend\n\n```\n\nFinally the most exciting part of the script is the method `update_mermaid`\nmethod. \n\n\nBelow the code sets up variables, and looks to see if a mermaid diagram\nexists in the epic description that it should populate. Note, that if a\nmermaid diagram does not exist in the epic already, this script will not\ncreate one. Each epic should already have a mermaid diagram placeholder\ninserted after the status header.\n\n\n```rb\n\ndef update_mermaid(token:, group_id:, epic_id:, dry_run:)\n in_epic = Set.new\n from_relations = Set.new\n relations = Set.new\n mermaid = ['graph TD']\n original_description = Gitlab.epic(group_id, epic_id).description\n\n unless original_description =~ MERMAID_REGEX\n puts \"#{epic_id} does not have a Mermaid diagram\"\n return\n end\n```\n\n\nNext the code iterates through each of the issues in the epic and assigns a\ngraph_id for each issue that will be part of the mermaid diagram. It also\nadds the `key_fields` to the `in_epic` Set. The code assigns `title` along\nwith an emoji so that the mermaid diagram is visually richer. After that the\ngraph nodes are added to the mermaid diagram. \n\n\n```rb\n Gitlab.epic_issues(group_id, epic_id).each do |issue|\n iid = issue['iid']\n graph_id = id(issue)\n\n in_epic \u003C\u003C key_fields(issue)\n\n title = \"##{iid}\"\n title = \"🎯 #{title}\" if issue['labels'].include?('exit criterion')\n if issue['state'] == 'closed'\n title = \"✅ #{title}\"\n elsif issue['assignees'].any?\n title = \"⏳ #{title}\"\n end\n\n mermaid \u003C\u003C \" #{graph_id}[\\\"#{title}\\\"]\"\n mermaid \u003C\u003C \" click #{graph_id} \\\"#{issue['web_url']}\\\" \\\"#{issue['title'].gsub('\"', \"'\")}\\\"\"\n\n```\n\nAfter adding the graph nodes above, the code iterates through the links\nassociated with each issue. The code determines if the issue is blocked by\nor blocks another issue. Knowing the direction of this relationship defines\nwhich direction the arrow in the mermaid diagram should point. \n\n\nThe code also adds both the issue and link to the `from_relations` set,\nwhich will automatically deduplicate entries.\n\n\n```rb\n Gitlab.issue_links(issue['project_id'], issue['iid']).each do |link|\n case link['link_type']\n when 'is_blocked_by'\n source = id(link)\n destination = graph_id\n when 'blocks'\n source = graph_id\n destination = id(link)\n else\n next\n end\n\n from_relations \u003C\u003C key_fields(issue)\n from_relations \u003C\u003C key_fields(link)\n\n unless relations.include?([source, destination])\n mermaid \u003C\u003C \" #{source} --> #{destination}\"\n relations \u003C\u003C [source, destination]\n end\n end\n```\n\n\nFinally, the code looks at the “extra” issues, which are issues that are not\ndirectly part of the epic, but are related to issues in the epic. These are\nthe most important issues to ensure are on the diagram, since they represent\nissue dependencies that are outside the epic and would otherwise not show up\nwhen viewing an epic page in GitLab. \n\n\nThe code then updates the epic description by calling the GitLab API and\nsetting the new description. \n\n\n```rb\n (from_relations - in_epic).each do |extra_issue|\n mermaid \u003C\u003C \" #{id(extra_issue)}[\\\"❌ ##{extra_issue['iid']}\\\"]\"\n mermaid \u003C\u003C \" click #{id(extra_issue)} \\\"#{extra_issue['web_url']}\\\" \\\"#{extra_issue['title'].gsub('\"', \"'\")}\\\"\"\n end\n\n mermaid_string = mermaid.join(\"\\n\")\n new_description = original_description\n .gsub(MERMAID_REGEX,\n \"\\n\\\\1\\n```mermaid\\n#{mermaid_string}\\n```\\n\")\n\n Gitlab.edit_epic(group_id, epic_id, description: new_description)\nend\n\n```\n\n\nThe above scripts help engineering managers efficiently know about all the\nissues their team members are working on, the status of their team’s epics\nand how all the work fits together. \n\n\nThe scripts only rely on team members doing two things manually: \n\n\n* Updating an epic’s status on a periodic basis\n\n* Creating relationships between related issues. \n\n\nThe scripts can be run as part of a regular scheduled\n[pipeline](https://gitlab.com/gitlab-org/secure/tools/epic-issue-summaries/-/blob/main/.gitlab-ci.yml).\nWith the reports generated on a scheduled basis, engineering managers can\nregularly get summarized information that helps make them and their teams\nmore productive.",[912,934,9],{"slug":1891,"featured":6,"template":698},"engineering-managers-automate-their-jobs","content:en-us:blog:engineering-managers-automate-their-jobs.yml","Engineering Managers Automate Their Jobs","en-us/blog/engineering-managers-automate-their-jobs.yml","en-us/blog/engineering-managers-automate-their-jobs",{"_path":1897,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1898,"content":1904,"config":1909,"_id":1911,"_type":13,"title":1912,"_source":15,"_file":1913,"_stem":1914,"_extension":18},"/en-us/blog/engineering-teams-collaborating-remotely",{"title":1899,"description":1900,"ogTitle":1899,"ogDescription":1900,"noIndex":6,"ogImage":1901,"ogUrl":1902,"ogSiteName":685,"ogType":686,"canonicalUrls":1902,"schema":1903},"How to carry out remote work team collaboration","Some tips for successful asynchronous collaboration from all-remote engineering teams.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681893/Blog/Hero%20Images/remoteengineering.jpg","https://about.gitlab.com/blog/engineering-teams-collaborating-remotely","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to carry out remote work team collaboration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2021-02-09\",\n }",{"title":1899,"description":1900,"authors":1905,"heroImage":1901,"date":1906,"body":1907,"category":1053,"tags":1908},[1325],"2021-02-09","\n\n_This post is the third in our ongoing series about remote work and engineering. Check out the previous posts, [Tips for engineering managers learning to lead remotely](/blog/tips-for-managing-engineering-teams-remotely/), and [Tips for remote pair programming](/blog/remote-pair-programming-tips/)._\n\nAlmost a year into the pandemic, it’s still unclear when it will be safe to head back into the office. While many companies have resolved the initial growing pains of transitioning from a colocated to an all-remote workplace, we want to help your teams go from surviving to thriving by sharing some strategies to [improve remote work collaboration](/company/culture/all-remote/collaboration-and-whiteboarding/).\n\n## Remote working and asynchronous communication\n\nTraditional methods of communication and project management might work in a colocated office setting, but don’t necessarily translate to a remote environment. In a video on GitLab Unfiltered (our company YouTube channel where team members share their work with the public), [Austin Regnery](/company/team/#aregnery), product designer on Manage: Compliance at GitLab, and [Nick Post](/company/team/#npost), senior product designer on Manage: Optimize at GitLab, talk about the growing pains of transitioning from working synchronously to asynchronously.\n\n\"Emails and meetings... [it's all] email, email, email, meeting, PowerPoint, that’s the modus operandi for how companies collaborated,\" says Nick. \"And it’s something that companies and teams have really held on to.\"\n\nAsynchronous communication challenges the traditional modes of workplace communication, but at GitLab, we’ve discovered that this more modern method of collaboration is more efficient and effective in delivering business value to our customers and helping our team members achieve a work-life balance.\n\nWatch the video below to learn how these designers work asynchronously.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/stLBy9TWJBw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Remote work collaboration: be sensitive to timezones\n\nWhen your team is working in the same office, the workday begins and ends at roughly the same time for everyone. At GitLab, we work asynchronously and our team is globally distributed, which means work is completed on a 24-hour clock instead of just eight hours. \n\nOne of the biggest challenges with working asynchronously is ensuring that all team members feel a sense of belonging across timezones. \n\n\"Timezones matter,\" says [Nuritzi Sanchez](/company/team/#nuritzi), senior open source program manager at GitLab. \"Make sure you're not leaving out team members in one locale. Have meetings at different times if needed (e.g., once a week in a NORAM-friendly time, next week in APAC-friendly time, etc).\" \n\nMaking the switch from synchronous to asynchronous work isn’t easy but really pays off. Learn more about [how we work asynchronously at GitLab](/company/culture/all-remote/asynchronous/#async-at-gitlab).\n\n### Remote work collaboration: maximize synchronous time \n\nThere are times when synchronous communication is the best option, such as during weekly team meetings and one-on-ones. Nuritzi explains that there are a few teams at GitLab that have adopted a particular structure to make the most out of every team meeting. \n\n* Always have an agenda: Every meeting needs an agenda, usually in Google Docs, that allows team members to add discussion items and notes before and during the meeting. \n* Notes are key: \"In OSS communities, meeting notes or IRC chats are something that are usually posted publicly later so everyone who needs to can catch up,\" says Nuritiz. \n* Start with check-ins: Team members voluntarily share whether they're at a green/yellow/red level in their work life and personal life. Managers are always advised to participate in these check-ins to set a collaborative tone. \n* FYIs: Not everything on the agenda will merit discussion. Add FYIs for items that should be shared with the team but don't require extensive dialogue. \n* Discussion topics: Some agenda items will need to be discussed with the team, add these in the discussion items section of the agenda.\n* Meetings are optional: Not every team member will be able to attend every meeting, and that's OK. Team members that aren't present can still participate by adding discussion items, FYIs, and notes to the agenda that can be shared by their fellow team members. \n* Try to make it fun: We start and end every [Inbound Marketing weekly recap meeting](https://youtube.com/playlist?list=PL05JrBw4t0KppgWkSa3YgDgc_qUTKsBCs) with music to liven up Thursdays for our globally distributed team. \n\n## How to make remote onboarding feel welcoming\n\nOnboarding is just one example of a workplace process that has been impacted by the pandemic. This makes having empathy for the new hire even more important than usual. Empathetic onboarding means framing the process from the perspective of the new hire, says [Alexandra Sunderland](https://ca.linkedin.com/in/alexandrasunderland), engineering manager at Fellow.\n\nAlexandra iterated on her onboarding process over a number of years and has since developed a six-step framework that she presented at our virtual user conference, GitLab Commit, last year. The six steps are: (1) Focus on relationships, (2) write knowledge down, (3) create an FAQ, (4) set goals and milestones, (5) set up their physical space, (6) ask for feedback.\n\nWatch the video below to learn how Fellow onboards engineers remotely. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/tdWxlpN8dUk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nBeyond making sure new team members are set up with a functional workspace, the secret to successful onboarding is assuming that the team member has the skills and knowledge necessary to do their job, but still needs to learn the context in which to do it, according to Alexandra. \n\nGitLab has a [unique onboarding process](/handbook/people-group/general-onboarding/), in that new hires are given a detailed checklist in an issue and are assigned an onboarding buddy. This onboarding process is a crash course in working as a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one) in an asynchronous workplace. \n\n## How to collaborate on releases remotely\n\nMattermost's [Aaron Rothschild](https://www.linkedin.com/in/arothschild), senior product manager, and [Paul Rothrock](https://www.linkedin.com/in/icelander), customer engineer, describe how their dashboard that provides visibility into the DevOps process can be used with tools such as Jira, Jenkins, and GitLab, to release software remotely. Watch the presentation from our user conference to see an example of how the team collaborates to deliver a release.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/QBG0-YaDXu0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## How to stay social when you’re working alone\n\nCommunication technologies, specifically Slack, can help to cultivate a sense of community and belonging within our teams. We publicly recognize team members that contributed to success in a #team-member-updates channel on Slack, where we announce bonuses and promotions for team members across the company. We also show appreciation for our collaborators in the #thanks channel.\n\n### The (virtual) water cooler\n\nThe pandemic has us all practicing social distancing, but at GitLab, we worked hard to try and replicate the social aspect of the office through a [few different informal communication programs](/company/culture/all-remote/informal-communication/), such as our coffee chats, and Slack channels devoted to different extracurriculars (I’m fond of the #dog and #baking channels, personally). The [Donut bot on Slack is a neat social feature](/company/culture/all-remote/informal-communication/#the-donut-bot). The bot will randomly introduce you to a team member that you may not otherwise have collaborated with in your daily work, and invites the two team members to [set up a coffee chat](/company/culture/all-remote/informal-communication/#coffee-chats). \n\n## Up-level your remote work skills\n\n[GitLab launched a free program on Coursera](https://www.coursera.org/learn/remote-team-management) to help managers with the transition of managing a team remotely. The course is free to join and is packed with valuable information to help companies adapt to working remotely.\n\nCover image by [Chris Montgomery](https://unsplash.com/@cwmonty?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/remote-work?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1097,9],{"slug":1910,"featured":6,"template":698},"engineering-teams-collaborating-remotely","content:en-us:blog:engineering-teams-collaborating-remotely.yml","Engineering Teams Collaborating Remotely","en-us/blog/engineering-teams-collaborating-remotely.yml","en-us/blog/engineering-teams-collaborating-remotely",{"_path":1916,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1917,"content":1923,"config":1929,"_id":1931,"_type":13,"title":1932,"_source":15,"_file":1933,"_stem":1934,"_extension":18},"/en-us/blog/enhancing-gitlab-with-improved-data-filtering-and-visualizations",{"title":1918,"description":1919,"ogTitle":1918,"ogDescription":1919,"noIndex":6,"ogImage":1920,"ogUrl":1921,"ogSiteName":685,"ogType":686,"canonicalUrls":1921,"schema":1922},"Enhancing GitLab with improved data filtering and visualizations","Discover how GitLab's new data views will streamline your workflow and power decision-making.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099097/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099097133.png","https://about.gitlab.com/blog/enhancing-gitlab-with-improved-data-filtering-and-visualizations","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Enhancing GitLab with improved data filtering and visualizations\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n \"datePublished\": \"2024-03-05\",\n }",{"title":1918,"description":1919,"authors":1924,"heroImage":1920,"date":1926,"body":1927,"category":1031,"tags":1928},[1925],"Amanda Rueda","2024-03-05","In the hectic world of product management, quick access, refinement, and visualization of data are essential to drive efficiency and productivity forward. Our recent exploration into the needs of product managers uncovered a vital link between their success and their ability to make data-driven decisions. Conversely, the drain on time and development resources emerged as a significant deterrent to high performance.\n\nRecognizing the critical role of data in strategic decision-making and prioritization, we're excited to announce an upcoming initiative, [Improved Data Filtering and Visualization](https://gitlab.com/groups/gitlab-org/-/epics/5516). This initiative focuses on the usability, flexibility, and efficiency of GitLab's planning views, simplifying how users interact with, recall, and share project data.\n\n## Streamlining data interaction and retrieval\n\nWe're focusing on consolidating multiple views into a unified platform, eliminating confusing navigation, and enabling users to create complex queries in a user-friendly manner. This approach not only makes data more accessible but also empowers users to visualize it in formats that best suit their needs. By providing a single hub for data access and presentation, we're making it easier for users to obtain critical information they need to make more informed, data-driven decisions quickly, leading to streamlined workflows and elevated project outcomes.\n\n### The evolution from multiple views to a single, configurable experience\n\nHere is what it looks like when you evolve from multiple views to a single, configurable experience:\n\n![Image of moving from multiple views to a single view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099112/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099112252.png)\n\n## Transforming workflows with real-world applications\n\nImagine a scenario where you must review the progress of multiple interconnected projects. Traditionally, this would involve navigating through various parts of GitLab, each with its own set of filters and views. With our Improved Data Filtering and Visualization initiative, you will now access a consolidated view that allows for creating intuitive queries. This new view can display issues and epics in a nested format, providing the hierarchical context you need to understand your project structure fully. What's more, you will have the ability to easily switch to a roadmap or board view as your use case demands.\n\nAnother example involves a development team planning their upcoming sprint. Instead of juggling between different pages for issues, epics, and boards, the team can utilize a single, customized view that allows them to view the context of related work items, update the status of work without opening multiple tabs, and understand work item dependencies. This saves precious synchronous time for the team and creates an efficient workflow by bringing visibility teams need to the forefront.\n\n## Engage with us!\n\nAs we venture into this transformative initiative, your insights and feedback will become the backbone of our progress. We're not merely enhancing features; we're on a mission to revolutionize how product planning can be successful within GitLab. Your insights will help turn this ambitious vision into reality.\n\nDelve into our proposed feature iterations [detailed within our initiative](https://gitlab.com/groups/gitlab-org/-/epics/5516#feature-iterations) and leave your comments on the epic. Your perspective on these enhancements is invaluable, helping us refine our approach and ensure it aligns with your needs and expectations.\n\nThis is more than a call to action — it's an invitation to shape the future of GitLab together. Share your feedback, suggestions, and visions with us!\n\n## Leverage Agile planning with GitLab\n\nBuilding on our commitment to streamlining workflows with the Improved Data Filtering and Visualization initiative, it's worth highlighting that GitLab also deeply integrates Agile delivery principles to enhance software development lifecycles. Discover how GitLab bridges strategy with execution, enabling teams to adopt Agile methodologies like Scrum and Kanban, and scale with frameworks such as [SAFe](https://scaledagileframework.com/) and [LeSS](https://less.works/less/framework).\n\n> Explore more about [enhancing Agile Delivery with GitLab](https://about.gitlab.com/solutions/agile-delivery/) and drive faster value creation.\n",[891,495,9,1388],{"slug":1930,"featured":6,"template":698},"enhancing-gitlab-with-improved-data-filtering-and-visualizations","content:en-us:blog:enhancing-gitlab-with-improved-data-filtering-and-visualizations.yml","Enhancing Gitlab With Improved Data Filtering And Visualizations","en-us/blog/enhancing-gitlab-with-improved-data-filtering-and-visualizations.yml","en-us/blog/enhancing-gitlab-with-improved-data-filtering-and-visualizations",{"_path":1936,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1937,"content":1943,"config":1948,"_id":1950,"_type":13,"title":1951,"_source":15,"_file":1952,"_stem":1953,"_extension":18},"/en-us/blog/epics-three-features-accelerate-your-workflow",{"title":1938,"description":1939,"ogTitle":1938,"ogDescription":1939,"noIndex":6,"ogImage":1940,"ogUrl":1941,"ogSiteName":685,"ogType":686,"canonicalUrls":1941,"schema":1942},"3 Major improvements coming to GitLab Epics","Explore three new features of GitLab Epics to enhance your workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671891/Blog/Hero%20Images/epicsimprovements.jpg","https://about.gitlab.com/blog/epics-three-features-accelerate-your-workflow","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"3 Major improvements coming to GitLab Epics\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2020-01-21\",\n }",{"title":1938,"description":1939,"authors":1944,"heroImage":1940,"date":1945,"body":1946,"category":1203,"tags":1947},[951],"2020-01-21","\n[Epics](https://docs.gitlab.com/ee/user/group/epics) allow teams to organize work into a useful collection of [issues](https://docs.gitlab.com/ee/user/project/issues), enabling proper planning to hit larger targets or function features. The [Plan:Portfolio Management team](https://handbook.gitlab.com/handbook/engineering/development/dev/plan/product-planning/) has been tinkering away to improve GitLab Epics. \n\n## How planning with epics provides insight \n\nEpics group themed items to work at different levels, depending on the individual working on the project. Product managers, engineers, and leadership all require different information from projects, and epics enable teams to stay connected without getting lost in a sea of issues.\n\n> “Epics are collections of work that move teams towards a goal and can be business or engineer focused. Operations teams might need to take a closer look at meeting customer needs, solving a problem, or rolling out a feature. An engineer might care about the very specific pieces of work they need to do to accomplish something, to release the next segment, or to put up the next MVC. Epics allow you to organize work, providing visibility at the right level. Different teams are all connected and related with each other, so we're able to stay lockstep in our proper zones.” – [Keanon O'Keefe](/company/team/#kokeefe), Senior Product Manager\n\nEpics break down information silos, since team members can quickly access information across a project. Without epics, teams may have to trudge through thousands of issues to identify relevant data. Cleanly sorting issues into epics results in an increase in visibility and a reduction in cycle time.\n\n## Three improvements \n\nWhen we [released GitLab Epics in 11.3](/blog/epics-roadmap/), our [MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) offered simple functionality and a roadmap. In recent months, we’ve started to iterate on those original MVCs to provide real value versus function. We're working on three significant iterations on epics to help teams enhance their workflow.\n\n### 1. Create issues from epics\n\nUsers can now create issues directly from epics, removing the step of navigating to a new tab before switching back to relate the issue to the epic. \n\n![A screenshot of a webpage that shows a button called create new issue](https://about.gitlab.com/images/blogimages/createanissuefromepic.png){: .shadow.medium.center}\n\nThis improvement allows users to create a new issue directly from an epic.\n{: .note.text-center}\n\nWith this improvement, users can create issues that correspond to a given epic, enabling them to break down a project into more digestible vertical feature slices.\n\n#### A quality of life improvement \n\nThe Plan:Portfolio team received user feedback that it was frustrating to manually create and relate issues in separate tabs. These additional steps disrupted workflow and didn’t meet expectations on how to efficiently iterate on a roadmap. With this quality of life improvement, users can now quickly iterate on the issues that comprise the larger epic.\n\nBy automatically relating issues to epics, users will no longer “lose” issues if they forget to manually relate them. This feature saves teams time and simplifies organization and planning.\n\n_Follow our progress by visiting [the issue](https://gitlab.com/gitlab-org/gitlab/issues/5419)_\n\n### 2. Weight and progress on roadmaps\n\nWhen viewing a roadmap, users can quickly understand the completion progress of each item. This information helps teams determine whether an epic is on track to be completed by the assigned end date.\n\nIf issues aren't groomed regularly, especially when it comes to issue weights, it can be difficult to trust any progress completion data on a roadmap, because it may not consider the historical velocity of the team implementing it. With this improvement, teams can quickly retrieve accurate, reliable data.\n\n#### An increase in visibility\n\nThis feature gives teams the ability to look at the roadmap and immediately recognize whether a project is behind or ahead of schedule. Previously, users had to manually calculate progress and estimate whether goals were attainable. This new view helps teams report progress outwards, allocate additional support to lagging items, and gain better visibility into the progression towards goals.\n\n![A screenshot of a webpage that shows projects and the corresponding progress and due date](https://about.gitlab.com/images/blogimages/weightandprogressepics.png){: .shadow.medium.center}\n\nThe new view will allow users to see quickly whether a project is on track.\n{: .note.text-center}\n\n> “Team members can self-serve information. And from a product manager’s perspective, especially when you look at a company like ours in which we’re all remote, if I need an update that’s not documented in an issue, I might have to wait until one of my engineers in APAC comes online to answer the question. If everything is demonstrated on a roadmap from a progress complete perspective, that can help me answer questions to customers or upper management on where things are at, without having to wait for a response from somebody else.” – Keanon O'Keefe\n\nThe idea is that it saves time, because a manager, director, or executive who looks at this roadmap has instant insight into progress. They don't have to ping the engineering manager who may then need to ping the developers. We’ve reduced the necessary steps in communicating progress and the ability to share information.\n\n**Tip**: This feature depends on leveraging [the weight option](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html). Keanon recommends weighting every issue assigned to an epic to provide the most accurate representation of the amount of work associated and your progress.\n\n_Follow our progress by visiting [the issue](https://gitlab.com/gitlab-org/gitlab/issues/5164)_\n\n### 3. Expand epics on roadmaps to view hierarchy\n\nChild epics are now displayed under their parent epics on the roadmap, enabling users to view the hierarchy of work. With this feature, users can get a detailed view of the work involved over a timeline. Because users can view hierarchy, they’re able to quickly see related work to track progress and determine whether an overall project will meet a goal. \n\n![A screenshot of a webpage that shows a parent epic and the child epics, with corresponding progress and due dates](https://about.gitlab.com/images/blogimages/expandepicsinroadmap.png){: .shadow.medium.center}\n\nThis feature gives users a detailed view of work involved over the project timeline.\n{: .note.text-center}\n\n> “What this change will do is allow you to look at a parent epic and actually click on it so that it expands kind of like a drawer. It will show the parent epic, which might be something that someone at an executive or director level cares about, while individual teams or engineering managers can view more granular details with child epics.” – Keanon O'Keefe\n\nThis improvement complements weights and progress on roadmaps, since it provides even more ways to view data and details. \n\n#### An ordered approach\n\nFrom an organizational standpoint, this iteration enables teams to properly sequence their plans. For example, teams that need to build a section of the backend before starting work on the frontend can quickly determine whether they’re on track to meet timelines or how much more work needs to be completed before another team can begin their work. This is our first step in empowering teams to sequence their work, and it’s an opportunity to allow teams to tailor the view of the roadmap to the audience.\n\n“We have a great set of designers, engineering managers, developers, and product people in Plan. I'm very impressed at how quickly everybody rallied together to move things forward. Many of these iterations are difficult from a design perspective, and I’m impressed with how the team approaches challenges and determines how to get the right data and visual at the right level, while allowing teams to drill down or drill up easily.” – Keanon O'Keefe\n\n**Tip**: It’s important to assign start and due dates to epics, whether you leverage the dates that are inherited or ones you set manually, so that child epics are properly displayed on the roadmap in relation to their parent.\n\n_Follow our progress by visiting [the issue](https://gitlab.com/gitlab-org/gitlab/issues/7077)_\n\n### What’s next for GitLab Epics?\n\nThe team is just getting started with its improvements to GitLab Epics. This is an area that we’re committed to accelerating, and we want to offer the most effective tools for product and portfolio management. “We’ve built out a strong team, and we’re hitting our stride and reaching our potential for releasing functionality,” says Keanon. \n\nOne of the next opportunities the Plan:Portfolio Management team will undertake is collaborating with Plan:Certify on [dependency mapping](https://gitlab.com/gitlab-org/gitlab/issues/2035), which will enable teams to surface dependencies on the roadmap. With dependency mapping, development and operations teams can view a sequence of work, identify blockers, and understand whether they’ll meet target deadlines. This feature will help larger organizations plan multiple projects simultaneously, see dependencies, and identify a critical path of work. \n\n> “We are just getting started with delivering tools that offer functionality between different groups. We have some exciting features coming soon.” – Keanon O'Keefe\n\nIf you’re interested in learning more about the team’s direction, please read more about the vision for Epics.\n\n_Thank you to [Keanon O'Keefe](/company/team/#kokeefe), Senior Product Manager, Plan:Portfolio Management, for contributing to this post._\n\nCover image by [Maarten van den Heuvel ](https://unsplash.com/@mvdheuvel?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/8EzNkvLQosk)\n{: .note}\n",[891,9,912],{"slug":1949,"featured":6,"template":698},"epics-three-features-accelerate-your-workflow","content:en-us:blog:epics-three-features-accelerate-your-workflow.yml","Epics Three Features Accelerate Your Workflow","en-us/blog/epics-three-features-accelerate-your-workflow.yml","en-us/blog/epics-three-features-accelerate-your-workflow",{"_path":1955,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1956,"content":1962,"config":1968,"_id":1970,"_type":13,"title":1971,"_source":15,"_file":1972,"_stem":1973,"_extension":18},"/en-us/blog/expanding-guest-capabilities-in-gitlab-ultimate",{"title":1957,"description":1958,"ogTitle":1957,"ogDescription":1958,"noIndex":6,"ogImage":1959,"ogUrl":1960,"ogSiteName":685,"ogType":686,"canonicalUrls":1960,"schema":1961},"The feature you wanted - Expanded Guest capabilities in GitLab Ultimate","GitLab Ultimate customers can now provide Guests the ability to view code. Learn how to access this new capability.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682652/Blog/Hero%20Images/iterating-cover.jpg","https://about.gitlab.com/blog/expanding-guest-capabilities-in-gitlab-ultimate","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The feature you wanted - Expanded Guest capabilities in GitLab Ultimate\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Hannah Sutor\"}],\n \"datePublished\": \"2023-03-08\",\n }",{"title":1957,"description":1958,"authors":1963,"heroImage":1959,"date":1965,"body":1966,"category":1053,"tags":1967},[1964],"Hannah Sutor","2023-03-08","\n\n[Customizable roles](https://docs.gitlab.com/ee/user/permissions.html) have been on GitLab's roadmap for the past two years. When we began working on them a year ago, our team struggled to find the [minimal viable change](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) (MVC) that would benefit customers. At the same time, through different feedback channels, customers were telling us they wanted more from their Ultimate tier Guest user roles. There it was: our MVC!\n\nHere is what happened next.\n\n## Our MVC journey\n\nWhen we began working on customizable roles, we knew that the six static, out-of-the-box roles that come with GitLab were not flexible enough to cover the use cases of our customers. Some roles were too permissive, while others didn’t grant the permissions necessary to accomplish a task. At a time when security and abiding by [the principle of least privilege](https://www.techtarget.com/searchsecurity/definition/principle-of-least-privilege-POLP) is more top of mind than ever, we needed to give our customers a way to define their own roles.\n\nThe customer ask was clear, but the implementation path was not. Performance considerations were top of mind. Permission policies are evaluated when any user action is performed, and we need a secure but scalable way for thousands of users, who may have hundreds of custom roles created, to do their work in GitLab. The team did a lot of technical discovery and performance testing in order to ensure the chosen technical implementation was scalable.\n\nWe decided to start with a very small implementation of custom roles - something that would be meaningful to customers, while also allowing our team to test the new backend implementation that will support custom role creation and usage.\n\n## How custom roles work\n\nFor our MVC, we decided that GitLab.com customers with an Ultimate license should be able to create a custom role that is based on the current “Guest” role. They will be able to add one additional permission to the “Guest” role - the ability to view code. This effectively creates a “Guest+1” role. They can then assign this custom role to any existing user.\n\nPreviously, Guests were able to view code on Self-Managed GitLab, and only on internal or public projects. Now, this functionality is available to Guests across the board - in GitLab.com and Self-Managed GitLab, and regardless of project visibility setting. You just need to create and apply the custom Guest role to any user who wishes to view code.\n\nYou can read more about how to [implement this yourself](https://docs.gitlab.com/ee/user/permissions.html#custom-roles) and watch a demo [here](https://about.gitlab.com/releases/2023/02/22/gitlab-15-9-released/#users-with-the-guest-role-can-view-private-repositories).\n\n## Create a custom role\n\nUse the API to create the “Guest+1” custom role. This role will show up as \"Guest - custom\" in the UI, so that it's easy to see which users have this version of the \"Guest\" role assigned.\n\nOnce the custom role is created, you can [use the API](https://docs.gitlab.com/ee/user/permissions.html#custom-roles) to associate it to a list of users. Voila! Now, your users have a custom role that allows them to view code as a Guest.\n\n![customizable guest role](https://about.gitlab.com/images/blogimages/iterating-towards-customizable-roles/guest-custom-role.png){: .shadow}\n\n## Why this MVC?\n\nSometimes, something is so loud that you’re forced to listen to it. That’s undoubtedly how I felt when I heard the dissatisfaction of our Ultimate customers around Guest users in private projects.\n\nAn unlimited number of Guest users are free with a GitLab Ultimate subscription. However, if the Guest user doesn’t have enough access to really do much within the product, is it really of any value at all? Customers left us a lot of feedback that the low level of privilege the Guest users have for private projects was detrimental to their users' workflows - making those “free” users not actually useful at all. We knew it was time to deliver more value.\n\n## What’s next\n\nOur final vision for customizable roles in GitLab is for our users to be able to take what exists today in our [permissions table](https://docs.gitlab.com/ee/user/permissions.html) and toggle each permission off/on as they please to define a custom role.\n\nWe plan to start on this by [consolidating](https://gitlab.com/groups/gitlab-org/-/epics/8914) some of these permissions - both for practical and performance reasons. As you can imagine, some permissions don’t make sense to be toggled “on” if a different feature is “off.\" We will be removing the need for complex logic by consolidating permissions into larger sets that make sense to be enabled/disabled at the same time. This should also translate nicely on the usability side - permutations of 100+ individual permissions would be unwieldy to manage, as a systems administrator, and difficult to understand your role definition, as an end user.\n\nThis update to custom roles is a great example of our iteration value here at GitLab, and I’m most excited about the fact that it’s solving an acute pain point for our Ultimate customers. They deserve to get a lot of value out of their Ultimate subscription, and I am hopeful that an additional permission for Guest users is one way we can increase their value. It’s also a great first step towards our grand customizable roles vision. I hope you’ll give it a try!\n\n**Check out this demo that shows the customizable guest role in action:**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/46cp_-Rtxps\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[829,9,495],{"slug":1969,"featured":6,"template":698},"expanding-guest-capabilities-in-gitlab-ultimate","content:en-us:blog:expanding-guest-capabilities-in-gitlab-ultimate.yml","Expanding Guest Capabilities In Gitlab Ultimate","en-us/blog/expanding-guest-capabilities-in-gitlab-ultimate.yml","en-us/blog/expanding-guest-capabilities-in-gitlab-ultimate",{"_path":1975,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1976,"content":1982,"config":1989,"_id":1991,"_type":13,"title":1992,"_source":15,"_file":1993,"_stem":1994,"_extension":18},"/en-us/blog/exporting-vulnerability-reports-to-html-pdf-jira",{"title":1977,"description":1978,"ogTitle":1977,"ogDescription":1978,"noIndex":6,"ogImage":1979,"ogUrl":1980,"ogSiteName":685,"ogType":686,"canonicalUrls":1980,"schema":1981},"How to export vulnerability reports to HTML/PDF and Jira","With GitLab's API, it's easy to query vulnerability info and send the report details elsewhere, such as a PDF file or a Jira project.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","https://about.gitlab.com/blog/exporting-vulnerability-reports-to-html-pdf-jira","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to export vulnerability reports to HTML/PDF and Jira\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Siddharth Mathur\"}],\n \"datePublished\": \"2023-09-14\",\n }",{"title":1977,"description":1978,"authors":1983,"heroImage":1979,"date":1985,"body":1986,"category":1053,"tags":1987},[1984],"Siddharth Mathur","2023-09-14","\nGitLab's [Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) makes it easy to triage security scan results without ever having to leave the platform. You can manage your code, run security scans against it, and fix vulnerabilities all in one place. That being said, some teams prefer to manage their vulnerabilities in a separate tool like Jira. They may also need to present the vulnerability report to leadership in a digestible format.\n\nOut of the box, GitLab's Vulnerability Report can be [exported to CSV](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#export-vulnerability-details) with a single click, for easy analysis in other tools. In some cases though, a simple PDF of the report is all that's needed. \n\nWith [GitLab's API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#queryvulnerabilities), it's easy to query vulnerability info and send the report details elsewhere, such as a PDF file or a Jira project. In this blog, we'll show you how to export to HTML/PDF and Jira. **Note that the scripts used in this tutorial are provided for educational purposes and they are not supported by GitLab.**\n\n## Exporting to HTML/PDF\nTo export your vulnerability reports to HTML or PDF, head to the [Custom Vulnerability Reporting](https://gitlab.com/jwagner-demo/vandelay-industries/engineering/custom-vulnerability-reporting) project. \n\n![Project overview](https://about.gitlab.com/images/blogimages/2023-07-27-exporting-vulnerability-reports-to-html-pdf-and-jira/project_overview.png)\n\n\nThis project contains a script that queries a project's vulnerability report, and then generates an HTML file from that data. The pipeline configured in the project runs this script and converts the HTML file to PDF as well.\n\nTo use the exporter, first [fork the project](https://gitlab.com/jwagner-demo/vandelay-industries/engineering/custom-vulnerability-reporting/-/forks/new) or [import it into a new project](https://gitlab.com/projects/new#import_project) (select “Repository by URL” and paste the git URL of the original project).\n\n![Project import](https://about.gitlab.com/images/blogimages/2023-07-27-exporting-vulnerability-reports-to-html-pdf-and-jira/project_import.png)\n\n\nSet the CI/CD variables as described in the readme. You'll need the following from GitLab:\n- GitLab project/personal access token with permissions to access vulnerability info (read_api scope)\n- GitLab GraphQL API URL (for SaaS this is https://gitlab.com/api/graphql)\n- GitLab project path (e.g. smathur/custom-vulnerability-reporting)\n\nAfter you've set the required CI/CD variables, manually run a pipeline from your project's Pipelines page. Once the pipeline is complete, you'll see your file export by going to the “build_report” (for HTML) or “pdf_conversion” job and selecting “Download” or “Browse” on the sidebar under \"Job artifacts.\" And there you have it! A shareable, easy-to-read export of your project's vulnerabilities.\n\n![PDF export](https://about.gitlab.com/images/blogimages/2023-07-27-exporting-vulnerability-reports-to-html-pdf-and-jira/pdf_export.png)\n\n\n## Exporting vulnerability info to Jira\nGitLab lets you create Jira tickets from vulnerabilities through the UI using our [Jira integration](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-jira-issue-for-a-vulnerability). While you can do this individually for vulnerabilities that need actioning, sometimes teams need to bulk-create Jira tickets for all their vulnerabilities. We can leverage GitLab and Jira's APIs to achieve this.\n\nTo get started, head to the [External Vulnerability Tracking](https://gitlab.com/smathur/external-vulnerability-tracking) project. This script fetches vulnerabilities in the same way as the script above, but it uses the Jira API to create a ticket for each vulnerability. Each ticket's description is also populated with details from GitLab's vulnerability report.\n\nTo use the exporter, simply [fork the project](https://gitlab.com/smathur/external-vulnerability-tracking/-/forks/new) or [import it into a new project](https://gitlab.com/projects/new#import_project) (select “Repository by URL” and paste the git URL of the original project), and set the CI/CD variables as described in the readme. You'll need the following from GitLab:\n- GitLab project/personal access token with permissions to access vulnerability info (read_api scope)\n- GitLab GraphQL API URL (for SaaS this is https://gitlab.com/api/graphql)\n- GitLab project path (e.g. smathur/external-vulnerability-tracking)\n\nYou will also need the following from Jira:\n- Jira [personal access token](https://id.atlassian.com/manage-profile/security/api-tokens)\n- Jira API issue endpoint URL (for SaaS this is https://ORG_NAME.atlassian.net/rest/api/latest/issue/)\n- Jira user email ID\n- Jira project key where you want to create vulnerability tickets (e.g. ABC)\n\nOnce you have set your CI/CD variables as described in the project readme, simply run a pipeline from your project's Pipelines page, and watch as your tickets get created in Jira!\n\nIf you run the pipeline again in the future, the script will run a search query against your Jira project to prevent duplicate tickets from being created. It will create tickets for new vulnerabilities that aren't already in Jira.\n\n![Jira export](https://about.gitlab.com/images/blogimages/2023-07-27-exporting-vulnerability-reports-to-html-pdf-and-jira/jira_export.png)\n\n\n## References\n- [GitLab Vulnerability API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#queryvulnerabilities)\n- [Custom Vulnerability Reporting project](https://gitlab.com/jwagner-demo/vandelay-industries/engineering/custom-vulnerability-reporting)\n- [External Vulnerability Tracking project](https://gitlab.com/smathur/external-vulnerability-tracking)\n- [Jira REST API examples](https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/)\n\n",[828,9,807,1988],"AWS",{"slug":1990,"featured":6,"template":698},"exporting-vulnerability-reports-to-html-pdf-jira","content:en-us:blog:exporting-vulnerability-reports-to-html-pdf-jira.yml","Exporting Vulnerability Reports To Html Pdf Jira","en-us/blog/exporting-vulnerability-reports-to-html-pdf-jira.yml","en-us/blog/exporting-vulnerability-reports-to-html-pdf-jira",{"_path":1996,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":1997,"content":2003,"config":2009,"_id":2011,"_type":13,"title":2012,"_source":15,"_file":2013,"_stem":2014,"_extension":18},"/en-us/blog/five-great-phabricator-features-inspired-gitlab",{"title":1998,"description":1999,"ogTitle":1998,"ogDescription":1999,"noIndex":6,"ogImage":2000,"ogUrl":2001,"ogSiteName":685,"ogType":686,"canonicalUrls":2001,"schema":2002},"5 Great Phabricator features that inspired GitLab","Take a deep dive into the Phabricator features that prompted GitLab to build new tooling around automation, integrated CI, and better code reviews.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667482/Blog/Hero%20Images/cover-image-unsplash.jpg","https://about.gitlab.com/blog/five-great-phabricator-features-inspired-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 Great Phabricator features that inspired GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n \"datePublished\": \"2021-08-13\",\n }",{"title":1998,"description":1999,"authors":2004,"heroImage":2000,"date":2006,"body":2007,"category":300,"tags":2008},[2005],"Michael Friedrich","2021-08-13","Innovation often happens because competition sparks new ideas. We unpack how\nPhabricator inspired GitLab to add new features.\n\n\n## Phabricator explained\n\n\nTurning back time a bit, what exactly is Phabricator? Built on the concept\nof web-based applications, Phabricator enables developers to collaborate\nwith code reviews, repository browser, change monitoring, bug tracking and\nwiki. On May 29, 2021, Phacility, the maintainer and sponsor of Phabricator\n[announced\nend-of-life](https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/)\nand stopped maintaining Phabricator.\n\n\n[GitLab co-founder and CEO, Sid Sijbrandij](/company/team/#sytses) gives\ncredit to Phabricator on\n[HackerNews](https://news.ycombinator.com/item?id=27334636):\n\n\n> Phabricator was an inspiration to me when starting GitLab. It is shutting\ndown now. [Many of its features were years ahead of its\ntime](https://news.ycombinator.com/item?id=27334511) and there was a lot of\nhumor in the product. As a tribute to it shall we add Clowcoptarize as a way\nto merge? This would be an [opt in option introduced in GitLab\n14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/332215).\n\n\nIt got me curious: What are these inspirations Sid is referring to? Let's\ndive into GitLab's history together and see what we can learn.\n\n\n_Tip: Features in the [GitLab documentation](https://docs.gitlab.com/) often\nhave a `Version History` box. You can use the issue URLs to dive deeper into\nfeature proposals, discussions, etc._\n\n\n### Review workflows\n\n\nA typical engineering workflow is as follows: The engineering manager\nassigns a new issue as a task to a developer. The developer works in their\npreferred IDE – local in VS Code or in the\n[Gitpod](/blog/teams-gitpod-integration-gitlab-speed-up-development/)\ncloud environment. Changes happen in a new feature branch in Git, which gets\npushed to the remote Git server for collaboration.\n\n\nThe Git branch is not ready yet and stays hidden in a potentially long list\nof branches. To keep better track of their feature branches, developers\ncould copy-paste the branch name or URL into the related issue - which I did\n10 years ago. The concept of a \"diff linked to a task for review\" in\nPhabricator, likewise a \"Git branch with commits linked to Merge Requests\"\nin GitLab was not invented yet. \n\n\nPhabricator inspired GitLab to create a [default\nworkflow](https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/)\nfor reviews. The Phabricator workflow makes the review more dominant and\nsquashes all changes into a single commit after the review is approved.\nThere are upsides and downsides to automatically squashing commits.\nSquashing the commits could mean losing information from review history and\ncreate more discussion. Depending on the application architecture, the\nfrequency of changes, and debugging requirements, this can be a good thing\nor a bad thing. GitLab allows you to choose to [squash\ncommits](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html)\nbefore merging a MR and/or specifying the default project settings around\nsquashing commits.\n\n\nPhabricator treated a MR (or what they call \"diff tasks\") as the single\nsource of truth for tracking changes and the review history. We felt this\nwas a great idea, and replicated the process of a \"diff task\" in Phabricator\nin GitLab MRs. One of the major upsides to GitLab's version is that\ncollaboration and discussion that happened in issues and epics is still\navailable even after the change is merged.\n\n\n#### Draft MR (or \"diff tasks\")\n\n\nMany times when a MR is created in GitLab, the branch requires additional\nwork before it is ready to be merged. Phabricator introduced a [formal\n\"Draft\" / \"Not Yet Ready for Review\"\nstate](https://secure.phabricator.com/T2543) in 2013 for \"diff tasks\", which\nhelped keep track of work in this state. GitLab added [WIP MRs in\n2016](/blog/feature-highlight-wip/), which we then renamed to draft merge\nrequests in 2020. While `WIP` may make sense to some people, acronyms can\nexclude newcomers. We found `Draft` is more recognizable. To avoid\nconfusion, GitLab [deprecated WIP and moved forward with draft merge\nrequests](https://gitlab.com/gitlab-org/gitlab/-/issues/32692).\n\n\n#### Keep history in MRs for future debugging\n\n\nThe commit history in GitLab is enriched with links to the MR and the\ncorresponding Git review history. In case of a production emergency, having\neverything documented allows for faster research and debugging.\n\n\nGitLab stores the MR short URL with `\u003Cnamespace>/\u003Cproject>!1234` in the\nmerge commit message. Check the history of a [demo project for the\nKubernetes\nagent](https://gitlab.com/everyonecancontribute/kubernetes/k8s-agent/-/commits/main/)\nto see how the merge commit is rendered.\n\n\n![GitLab history with MR commit\nlinks](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/gitlab_history_mr_metadata_link.png)\n\nGitLab commit history includes link to the MR.\n\n{: .note.text-center}\n\n\nThis raw information is stored in the Git repository, whereas the MR itself\nstays in GitLab's database backend. You can verify this by cloning a\nrepository and inspecting the history with this command:\n\n\n```sh\n\n$ git log\n\n```\n\n\n![git log MR\nmetadata](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/git_log_mr_merge_commit_metadata_link.png)\n\nMR metadata included in output from `git log` command.\n\n{: .note.text-center}\n\n\n### Code coverage in MRs\n\n\nCode coverage reports provide insight into how many lines of the source code\nare covered with unit tests. Reaching 100% test coverage is a developer myth\n- visualizing a decrease or increase can help monitor a trend in code\nquality. Phabricator implemented support for various languages with unit\ntest engines and parsing the output, for example in\n[Golang](https://secure.phabricator.com/D12621).\n\n\nWith many different languages and report output formats, integrating code\ncoverage reports into GitLab MRs was challenging. [GitLab launched the first\niteration of code coverage reports in\n2016](/blog/publish-code-coverage-report-with-gitlab-pages/), which\ngenerated the reports with CI/CD jobs and used GitLab pages to publish the\nHTML reports.\n\n\nIn this first iteration, the test coverage is parsed with a regular\nexpression from the CI/CD job output, specified in the project settings or\nwith the [coverage](https://docs.gitlab.com/ee/ci/yaml/#coverage) keyword\ninside the CI/CD job configuration. We can see this in the job view inside\nthe [MR\nwidget](https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-to-a-merge-request)\nand as a coverage badge for the project. See the test coverage history by\nnavigating into `Analytics > Repository`.\n\n\n![Test coverage as project badge in\nGitLab](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/gitlab_project_badge_test_coverage.png)\n\nThe test coverage badge in a GitLab project.\n\n{: .note.text-center}\n\n\nJUnit XML test reports were introduced as common format specification and\nadded as an [MR widget in\n2018](https://docs.gitlab.com/ee/ci/unit_test_reports.html). The test\nreports runs in the background, using CI/CD artifacts to upload the XML\nreports from the runner to the server, where the MR/pipeline view visualizes\nthe coverage reports in a tab.\n\n\nThe generic JUnit integration also helped with customization requests to\nunit tests, updated CLI commands, or changed coverage report outputs to\nparse. GitLab provides [CI/CD template\nexamples](https://docs.gitlab.com/ee/ci/examples/)\n\n\nThe missing piece for GitLab was having inline code coverage remarks inside\nMR diffs. It took about five years for [Sid's initial proposal for inline\ncode coverage remarks](https://gitlab.com/gitlab-org/gitlab/-/issues/3708)\nto be implemented. In 2020, inline code coverage remarks were released in\n[GitLab\n13.5](https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html).\n\n\n![Test Coverage with Rust in\nGitLab](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/gitlab_mr_diff_inline_test_coverage.png)\n\nHow inline code coverage works in GitLab.\n\n{: .note.text-center}\n\n\nCheck out [this MR to practice verifying the test\ncoverage](https://gitlab.com/everyonecancontribute/dev/rust-code-coverage-llvm/-/merge_requests/1/diffs?view=inline\nvalidating some Rust code). Make sure to select the inline diff view.\n\n\n### Automated workflows and integrated CI\n\n\nPhabricator provides\n[Herald](https://secure.phabricator.com/book/phabricator/article/herald/) as\nan automated task runner and rule engine to listen for changes. Herald can\nalso be used to ensure [protected\nbranches](https://docs.gitlab.com/ee/user/project/protected_branches.html)\nand [approval\nrules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#add-multiple-approval-rules)\nto enforce a strong permission model in development workflows. There are\nmore examples in this [HackerNews post from\n2016](https://news.ycombinator.com/item?id=12501025) and somehow, I feel\nlike an explorer seeing many great GitLab features in similar ways. 🦊\n\n\n[GitLab CI/CD pipeline\nschedules](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) remind me\nof the task runner, similarly to\n[webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html)\nand the [REST API](https://docs.gitlab.com/ee/api/) being instrumented from\nCI/CD jobs. The pipeline schedules are also a great way to periodically\nregenerate caches and rebuild container images for cloud native deployments.\n\n\n[Harbormaster](https://secure.phabricator.com/book/phabricator/article/harbormaster/)\nis Phabricator's integration for CI. It's not built from multiple tools in\nthe [DevOps](/topics/devops/) stack, but is instead fully integrated in the\nproduct.\n\n\nThe first version of GitLab CI was created in [November\n2012](/company/history/). In 2015, a GitLab team member came up with the\nidea of combining SCM with CI and [the all-in-one DevOps platform was\nborn](/blog/gitlab-hero-devops-platform/). Built-in CI/CD\ninspired for more features and fostered a better way to innovate together.\nThe [new pipeline editor](/blog/pipeline-editor-overview/) is\njust one example of a streamlined way to configure CI/CD pipelines in\nGitLab.\n\n\nLet's throwback to 2017 and watch as we demonstrate how to take an idea to\nproduction in GitLab, using GKE:\n\n\n\u003Ciframe width=\"560\" height=\"315\"\nsrc=\"https://www.youtube.com/embed/39chczWRKws\" title=\"YouTube video player\"\nframeborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write;\nencrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\n\u003Cbr>\n\n\n### Work boards for issue management\n\n\nWork needs to be organized. Phabricator led the way with a board which\nallowed users to filter tasks and provide a more detailed view into planning\nand project management.\n\n\n![Phabricator work\nboards](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/phabricator_work_boards.png)\n\nInside Phabricator work boards.\n\n{: .note.text-center}\n\n\nGitLab users will recognize the similar look between Phabricator's work\nboards and GitLab [issue\nboards](https://docs.gitlab.com/ee/user/project/issue_board.html). In GitLab\n14.1, we built on existing epic tracking and labeling to create [Epic\nboards](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html) to\nkeep teams organized and measure progress.\n\n\nIn Phabricator, users can drag and drop between columns, which automatically\nchanges the work status for a particular task. This feature inspired the\nboards in GitLab to automatically change the labels in a [defined\nworkflow](/blog/4-ways-to-use-gitlab-issue-boards/) by dragging and dropping\nbetween columns. Users can go a level deeper with scoped labels to switch\nbetween workflow states:\n\n\n* `workflow::design`\n\n* `workflow::planning breakdown`\n\n* `workflow::ready for development`\n\n* `workflow::in dev`\n\n* `workflow::verification`\n\n\nThe [GitLab engineering handbook](/handbook/engineering/workflow/#basics)\ndocuments the different workflows.\n\n\n![Epic boards in\nGitLab](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/gitlab_epic_boards.png)\n\nTake a look at the Epic boards in GitLab.\n\n{: .note.text-center}\n\n\n### Put it all together\n\n\nIn Phabricator, a diff task (in GitLab they're MRs) in the \"review\" state is\nlinked to another task specifying the requirements. The UX needs to be clear\nso the relationship between the diffs can be accessed and understood. Unless\nnecessary, the user shouldn't have to navigate manually. The context of the\nchange review defines possible links to labels, states, dependent issues,\ndiff tasks (MRs), and more.\n\n\nGitLab links [related\nissues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html).\nIf an issue is mentioned in a MR, or vice versa, [GitLab automatically links\nthem](https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html#from-merge-requests).\nThe user also has the option to have the issue close automatically once a\nchange is merged. Read a blog post from 2016 to learn more about [how issues\nand MRs can relate to each other in\nGitLab](/blog/gitlab-tutorial-its-all-connected/).\n\n\n![Linked issues and MRs in\nGitLab](https://about.gitlab.com/images/blogimages/phabricator-features-inspired-gitlab/gitlab_linked_issues_mrs.png)\n\nLinked issues and related MRs in GitLab.\n\n{: .note.text-center}\n\n\nUX work is challenging, and we continue to iterate to improve workflows in\nGitLab. For example, in GitLab 13.8, we reduced the number of clicks it\ntakes to [download a CI/CD job artifact from the\nMR](https://gitlab.com/gitlab-org/gitlab/-/issues/37346).\n\n\n\n### Did we miss a feature Phabricator inspired?\n\n\nWhile writing this blog post, my research revealed more gems. For example, I\nfound a proposal to add [visual graphs for issue\ndependencies](https://gitlab.com/gitlab-org/gitlab/-/issues/273597) in the\n[HN thread](https://news.ycombinator.com/item?id=27336818).\n\n\nWhich features from Phabricator are missing in GitLab? Let us know in the\ncomments, create a new [feature\nproposal](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Proposal%20-%20lean)\nor start your [contribution journey](/community/contribute/) in a new MR\nright away! \n\n\nCover image by [Johannes Plenio](https://unsplash.com/photos/DKix6Un55mw) on\n[Unsplash](https://unsplash.com)\n\n{: .note}\n",[1306,1264,9],{"slug":2010,"featured":6,"template":698},"five-great-phabricator-features-inspired-gitlab","content:en-us:blog:five-great-phabricator-features-inspired-gitlab.yml","Five Great Phabricator Features Inspired Gitlab","en-us/blog/five-great-phabricator-features-inspired-gitlab.yml","en-us/blog/five-great-phabricator-features-inspired-gitlab",{"_path":2016,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2017,"content":2023,"config":2029,"_id":2031,"_type":13,"title":2032,"_source":15,"_file":2033,"_stem":2034,"_extension":18},"/en-us/blog/five-signs-you-should-think-bigger",{"title":2018,"description":2019,"ogTitle":2018,"ogDescription":2019,"noIndex":6,"ogImage":2020,"ogUrl":2021,"ogSiteName":685,"ogType":686,"canonicalUrls":2021,"schema":2022},"Five signs you should think BIGGER!","Are you a designer who is frustrated with only focusing on the next milestone? Do you feel like you have to answer too many questions in every Issue? Do you feel like your product is not making any progress? **Time to Think Bigger!**","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099620/Blog/Hero%20Images/Blog/Hero%20Images/insights_insights.png_1750099620265.png","https://about.gitlab.com/blog/five-signs-you-should-think-bigger","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Five signs you should think BIGGER!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Iain Camacho\"}],\n \"datePublished\": \"2021-03-30\",\n }",{"title":2018,"description":2019,"authors":2024,"heroImage":2020,"date":2026,"body":2027,"category":1053,"tags":2028},[2025],"Iain Camacho","2021-03-30","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAs a designer, it’s difficult to balance the scale of initiatives: Design too small, and nobody is excited or can understand the direction things are going. Start too big and everyone on the team may be too intimidated to start. ThinkBIG is a way of utilizing designers’ natural skillset to balance the iterative nature of engineering with the visionary nature of design.\n\nHere are 5 signals that you should switch up your style and Think Bigger:\n\n### 1) Every milestone is spent only prepping the next\n\n#### Signal\n\nWe’ve all been there. The next milestone planning issue is starting to get filled out and you, the designer, are realizing how many issues need design in order to be ready. As the priorities shift, you know the last two weeks of this milestone will be spent desperately trying to design mockups for engineers to start working on days later. I like to call this “Feeding the sharks”. It describes a certain level of panic some designers feel every milestone: If I don’t deliver enough, I might get chomped!\n\n#### Solution\n\nThinkBIG focuses on creating a larger-scale vision that can be iterated on as we go. This means that each design you put together leads to many independent issues engineers can work on. For a designer, this increases [results](https://handbook.gitlab.com/handbook/values/#results) by delivering one design worth many issues.\n\n### 2) Engineers are asking _a lot_ of questions\n\n#### Signal\n\nHave you ever started a new milestone and as engineers get started, they have a million questions detailing every possible state, permutation, and example that they should account for? This line of questioning means you, the designer, now need to make a myriad of new designs with only minute changes between them. This is not an [efficient](https://handbook.gitlab.com/handbook/values/#efficiency) use of the designer’s time.\n\n#### Solution\n\nFirst off, all these questions are valid and decisions that need to be made. By Thinking Bigger, engineers are better prepared to handle all the edge cases independently because they walk into their work with a fuller context of the impact on users. This enables empathy-driven engineering, allowing engineers to lead the conversation around edge-cases with solutions in mind, instead of needing it to be defined ahead of time. By pushing the edge cases further down the product development lifecycle, there is also a unique opportunity for product, design, and engineering to [collaborate](https://handbook.gitlab.com/handbook/values/#collaboration) on delivering value to customers while still working iteratively.\n\n### 3) Nobody agrees on what the “MVC” actually is\n\n#### Signal\n\nPicture it: You’ve worked hard for weeks refining and distilling a big feature ask into a nicely designed MVC. It’s small, delivers value, and is beautiful to boot! You’ve convinced your PM to prioritize this beautiful little gem and it’s going onto the planning board. Everything feels amazing until… devastation!\n\nAfter engineering looked at it, they came back and said it was too large and would need to be broken down further. Now you’re at the end of your milestone and you’re swiftly picking away at your beautiful design into a shallow imitation of its former glory.\n\n#### Solution\n\nHowever, there is a simple way to keep this from happening: “[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is a team sport”. The designer shouldn’t be the only person on the team compromising for the sake of MVC. With ThinkBIG, you have multiple chances to bring engineering into the fold early and with the full vision in mind. This means devs are part of the conversation from the start, able to craft a valuable iteration and your designs become the conversation piece of deciding “What can we do next to deliver an amazing experience to our customers?”\n\n### 4) We’re working so hard but not getting anywhere\n\n#### Signal\n\nWorking iteratively is incredibly powerful and at GitLab, we can see the value of an iterative approach. We’re able to change our priorities at a moment’s notice and the work we actually have to deliver is reasonable and manageable while continuously delivering new value to customers. There is, however, a small drawback: When you’re only focusing on the step immediately in front of you, it’s easy to get lost along the way.\n\n#### Solution\nAs a designer, we have a unique opportunity to be the navigator for our teams. Using the ThinkBIG model, designers are empowered to hold responsibility for the Vision. From here, the Product Manager/Product Designer relationship becomes a balance between the vision and the strategy. Designs based on the large vision are used to keep the team on track for hitting the targets that bring value to customers while allowing for collaboration with the rest of the team on what tiny steps we take to get there.\n\n### 5) Engineers are reworking a lot\n\n#### Signal\n\nMy engineer and I are excited to work on a new effort. I’ve designed the first iteration and successfully passed it to them. While they’re building, I’m working on the design for the next iteration. A few weeks later the new changes are merged, the next iteration designs are ready, and customers are already seeing value. Your engineer looks at the next iteration and painfully mutters “Well, I’ll have to rewrite what I wrote the last milestone to account for this.”\n\n#### Solution\n\nIn a highly iterative development lifecycle, it’s not uncommon to have to rework things as the product evolves. However, it shouldn’t be happening every time. With ThinkBIG, engineers are informed of the long-term goal as well as the short-term MVC iteration. This extra context allows them to deliver the iteration while architecting their code in an informed way of where it will go.\n\n### Start Thinking BIGGER!\n\nAre some of these signals sounding familiar? Then switching your design style to ThinkBIG may be for you! The simplest way to make this change is to move iteration breakdown to **after** the design phase. It immediately shows engineers where we want to go as a product or feature, opens the implementation breakdown (MVC) conversation to the whole team, and provides incredibly valuable insight to everyone on the team. This model of working helps designers be more efficient, deliver results, and foster a tight collaboration with the broader team. To see this process in action, check out a [Package ThinkBIG around the dependency proxy design and research](https://www.youtube.com/watch?v=LXFu6oDxhsw). For more information, check out the GitLab Handbook on [ThinkBIG](https://about.gitlab.com/handbook/product/ux/thinkbig/) to learn more.\n",[9,1096,934,1097,1988],{"slug":2030,"featured":6,"template":698},"five-signs-you-should-think-bigger","content:en-us:blog:five-signs-you-should-think-bigger.yml","Five Signs You Should Think Bigger","en-us/blog/five-signs-you-should-think-bigger.yml","en-us/blog/five-signs-you-should-think-bigger",{"_path":2036,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2037,"content":2043,"config":2049,"_id":2051,"_type":13,"title":2052,"_source":15,"_file":2053,"_stem":2054,"_extension":18},"/en-us/blog/five-things-you-hear-from-gitlab-ceo",{"title":2038,"description":2039,"ogTitle":2038,"ogDescription":2039,"noIndex":6,"ogImage":2040,"ogUrl":2041,"ogSiteName":685,"ogType":686,"canonicalUrls":2041,"schema":2042},"5 Things you might hear when meeting with GitLab's CEO","After two weeks shadowing our CEO, I can share the hottest topics on his mind right now.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670738/Blog/Hero%20Images/coghlanshadow.jpg","https://about.gitlab.com/blog/five-things-you-hear-from-gitlab-ceo","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 Things you might hear when meeting with GitLab's CEO\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"John Coghlan\"}],\n \"datePublished\": \"2019-06-28\",\n }",{"title":2038,"description":2039,"authors":2044,"heroImage":2040,"date":2046,"body":2047,"category":910,"tags":2048},[2045],"John Coghlan","2019-06-28","\n\nDuring my two-week rotation in GitLab’s [CEO shadow program](https://handbook.gitlab.com/handbook/ceo/shadow/) I noticed something: Being a CEO involves a lot of repetition. Whether meeting with his executive team, board members, public or private market investors, candidates for [open roles](/jobs/), or journalists, our CEO [Sid Sijbrandij](/company/team/#sytses) had to repeat himself – a lot.\n\nThis shouldn’t be a surprise. I’ve read [articles](https://www.mckinsey.com/business-functions/organization/our-insights/the-ceos-role-in-leading-transformation) about the [importance of repetition](https://getlighthouse.com/blog/power-of-repetition-successful-leaders/) for leaders. My job can be pretty repetitive, too. I'm constantly planning meetups and explaining my role and the programs I manage to people throughout the wider GitLab community. And yet, given Sid’s position in GitLab and his desire to pursue “interestingness” (a Sid-ism I heard often), I was still surprised the 10th time I heard him tell the story of [how GitLab was founded](https://www.youtube.com/watch?v=CZ07wk3t31g&feature=youtu.be&t=135).\n\nI want to highlight a few of the other common themes, topics, and questions that came up repeatedly throughout my time in the CEO shadow program – to both share some insight with our community and inform folks who will be meeting with Sid about what to expect.\n\n## 1. \"We don't have any offices\"\n\nGitLab’s all-remote culture is a popular topic right now. It came up frequently in conversations with potential investors, candidates for executive positions, and journalists. People were curious to learn how we make it work at our scale and how we replicate the serendipitous moments that occur among co-located teams. Sid typically relies on explanations of our [handbook](https://handbook.gitlab.com/handbook/), [breakout calls](https://handbook.gitlab.com/handbook/communication/#breakout-call), [coffee chats](/company/culture/all-remote/tips/#coffee-chats), and [Contribute](https://www.youtube.com/watch?v=xdtPNXtkBhE) to help folks better understand how we are able to be successful as an all-remote company.\n\nIt's exciting to hear the conversation on all-remote work evolve as people learn more about it. One of the main reasons I joined GitLab was the ability to be part of an [all-remote](/company/culture/all-remote/) company. I believe we can change how the world views all-remote teams as we continue to be successful. With more than 2,000 [contributors](/community/contribute/), more than 600 people on our [team](/company/team/), and many more wanting to join, we are off to a good start.\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\" data-cards=\"hidden\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Over the last 3 months we had over 20,000 applications for the vacancies at \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> \u003Ca href=\"https://t.co/JbmWvk3uDB\">https://t.co/JbmWvk3uDB\u003C/a> It encourages us to push for even more transparency \u003Ca href=\"https://t.co/WQcUPXzcWj\">https://t.co/WQcUPXzcWj\u003C/a> since many people cite that as a reason to apply.\u003C/p>— Sid Sijbrandij (@sytses) \u003Ca href=\"https://twitter.com/sytses/status/1134122539670691841?ref_src=twsrc%5Etfw\">May 30, 2019\u003C/a>\u003C/blockquote>\n\u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nOur success has [already inspired other companies to follow the all-remote blueprint](/handbook/inspired-by-gitlab/). The movement towards all-remote organizations will continue as we grow, generating more awareness and opening up opportunities that were never previously available to people around the world.\n\nHere's a recording of a meeting I attended between our CEO Sid and GitLab board member Sue Bostrom that touched on our all-remote story:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/ePZpfeTG63M\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## 2. \"One of our values is...\"\n\nIn nearly every meeting I attended over the two-week rotation, [GitLab’s values](https://handbook.gitlab.com/handbook/values/) were mentioned. Transparency is the most common value highlighted when our CEO meets with members of the wider GitLab community (see above tweet), many of whom are surprised to see Sid using Google to search for our handbook, roadmap, or OKRs – which is possible because they’re published publicly on our website. With his executive team and other leaders in the company, Sid is frequently focused on [results](https://handbook.gitlab.com/handbook/values/#results) – from structuring his meetings with a bias to action (more on this later) to pushing for GitLab to always be more data-driven and analytical in how we execute on everything from [our releases to our vision](/handbook/product/product-processes/#planning-horizons). When something is moving slower than expected, Sid will encourage people to break down the work and make small changes that are easier to ship in alignment with our [iteration value](https://handbook.gitlab.com/handbook/values/#iteration).\n\nOur other values came up in conversations about how we recruit for our fast-growing team and the recruitment of a new chief people officer ([diversity](https://handbook.gitlab.com/handbook/values/#diversity-inclusion)), how well our people are performing as managers of one ([efficiency](https://handbook.gitlab.com/handbook/values/#efficiency)), and the importance of dogfooding our own product ([collaboration](https://handbook.gitlab.com/handbook/values/#collaboration)).\n\n## 3. \"Is this already in the handbook?\"\n\nAs I alluded to earlier, at GitLab we value results and that starts with the CEO. Internal meetings with Sid require an agenda. Those agendas typically follow a [specific format](/handbook/leadership/1-1/suggested-agenda-format/), and they are usually filled with merge requests and other actionable items. Meetings with our CEO are not for status updates. They tend towards discussions that lead to action or for taking action (such as reviewing and merging an MR that is linked to in a meeting agenda). When a discussion takes place without a related MR link in the agenda, Sid inevitably asks, \"Is this already in the handbook?\" or something to that effect. This ensures any follow-up actions are assigned to someone so that actionable, visible changes are not delayed.\n\nEven participation in the shadow program is viewed through the lens of results. As a shadow, one of the [tasks](https://handbook.gitlab.com/handbook/ceo/shadow/#tasks) you’re expected to complete is updating GitLab’s handbook, particularly the shadow page. During my rotation, Sid commented multiple times on the number of MRs that I created to update our handbook. Results have the CEO’s attention.\n\n## 4. \"Google Docs are the new whiteboard\"\n\nGoogle Docs are the default tool for GitLab agendas and meeting notes. While they are a necessity in the remote work environment, once you begin using them, you quickly notice the efficiency they bring to meetings. The delight that Sid draws from the efficiency of using Google Docs for notes is clear whenever he happily explains how they are superior to whiteboards, which happens frequently in meetings with people new to GitLab's way of working.\n\nAt GitLab, we find Google Docs to be so efficient and helpful, that we’ve even included [why to use them in our handbook](/company/culture/all-remote/tips/index.html#docs-beat-whiteboards). This handbook addition was contributed by my fellow CEO shadow, [Cindy Blake](/company/team/#cblake2000). In her words:\n\n> \"Often we are asked, 'But how do you whiteboard without everyone physically together?' We use Google Docs for collaboration. Every meeting has a Google Doc for the agenda and for documenting discussion, decisions, and actions. Everyone in the meeting adds notes at the same time. We literally even finish one another's sentences sometimes. By brainstorming in text, instead of drawings, we are forced to clearly articulate proposals, designs, or ideas, with less variance in interpretations. A picture may be worth a thousand words, but it is open to as many interpretations are there are people viewing it. In Google Docs, we use indentations to drill deeper into a given topic. This method retains context for comments, discussions, and ideas.\"\n\n## 5. \"Can you put your headphones on?\"\n\nThe emphasis on clear communication is a priority for Sid and leaks into many of his conversations. This ranges from his awareness and respect when communicating with folks for whom English is not their first language to how we name and structure the parts of our organization and to whether or not a meeting attendee is using headphones on a Zoom chat (note: you should). All of this – even the preference for headphones – makes sense.\n\nAt a macro level, as an all-remote, open core company with a global community and [team members in 54 countries](/company/team/), GitLab’s community consists of people with varying levels of English fluency. In order to promote a diverse and inclusive culture, it’s important to choose clear language when writing and speaking – from how we name teams and features to the idioms and slang we choose not to use. At a micro level, if you’re meeting with someone who has a poor video or audio connection the issue must be resolved so that everyone can understand each other and get through the agenda.\n\n## Takeaways\n\nWhether you're reading this because you have a meeting with Sid, you're joining the CEO shadow program, or you simply want to add some best practices from a CEO to incorporate in your routine, there are a few key takeaways to distill from these common topics and questions.\n\n* All-remote is gaining momentum\n* Values matter\n* Have a bias towards action\n* Find tools that work for you\n* Clear communication is key\n\nOne other thing you'll hear often when you're with Sid is \"Thank you.\" Despite being a CEO, Sid is generous with his time and praise and never fails to say thank you to folks he spends time with. As a parent of two young children myself, I think that might be the most important takeaway of all.\n",[1097,9,934],{"slug":2050,"featured":6,"template":698},"five-things-you-hear-from-gitlab-ceo","content:en-us:blog:five-things-you-hear-from-gitlab-ceo.yml","Five Things You Hear From Gitlab Ceo","en-us/blog/five-things-you-hear-from-gitlab-ceo.yml","en-us/blog/five-things-you-hear-from-gitlab-ceo",{"_path":2056,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2057,"content":2062,"config":2070,"_id":2072,"_type":13,"title":2073,"_source":15,"_file":2074,"_stem":2075,"_extension":18},"/en-us/blog/forrester-tei",{"title":2058,"description":2059,"ogTitle":2058,"ogDescription":2059,"noIndex":6,"ogImage":708,"ogUrl":2060,"ogSiteName":685,"ogType":686,"canonicalUrls":2060,"schema":2061},"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://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":2063,"description":2059,"authors":2064,"heroImage":708,"date":2066,"body":2067,"category":1203,"tags":2068},"Discover your GitLab return on investment with the Forrester Total Economic Impact™ Study and Estimator",[2065],"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",[108,9,695,1203,2069,1263],"research",{"slug":2071,"featured":6,"template":698},"forrester-tei","content:en-us:blog:forrester-tei.yml","Forrester Tei","en-us/blog/forrester-tei.yml","en-us/blog/forrester-tei",{"_path":2077,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2078,"content":2084,"config":2090,"_id":2092,"_type":13,"title":2093,"_source":15,"_file":2094,"_stem":2095,"_extension":18},"/en-us/blog/future-merge-requests-realtime-collab",{"title":2079,"description":2080,"ogTitle":2079,"ogDescription":2080,"noIndex":6,"ogImage":2081,"ogUrl":2082,"ogSiteName":685,"ogType":686,"canonicalUrls":2082,"schema":2083},"The future of merge requests: Real-time collaboration","We want to hear your thoughts on the future of merge requests and code review.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666775/Blog/Hero%20Images/cover.jpg","https://about.gitlab.com/blog/future-merge-requests-realtime-collab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The future of merge requests: Real-time collaboration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Moreira da Silva\"}],\n \"datePublished\": \"2019-12-19\",\n }",{"title":2079,"description":2080,"authors":2085,"heroImage":2081,"date":2087,"body":2088,"category":1053,"tags":2089},[2086],"Pedro Moreira da Silva","2019-12-19","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2019-12-20.\n{: .alert .alert-info .note}\n\nWe want to share some of the work we’ve been doing in the [Source Code](https://handbook.gitlab.com/handbook/product/categories/#source-code-group) part of the product and get feedback on what could be the future of [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) and [code review](/direction/create/code_review/).\n\n**Perhaps the best way is to walk you through a short visual story. You can** [**watch the recording (28 min)**](https://www.youtube.com/watch?v=KpdvIU6hv94) **or** [**jump to its text version**](#context) **below. In the end, if you’d like to share your thoughts, you can do so on the** [**feedback issue**][feedback-issue].\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/KpdvIU6hv94\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Context\n\nIf you haven’t been following along our work on merge requests, let’s set the scene:\n1. In the next releases of GitLab, we’re shipping [**performance**](https://gitlab.com/groups/gitlab-org/-/epics/1417) **and** [**navigation**](https://gitlab.com/gitlab-org/gitlab/issues/33813) **improvements**, based on the user experience research we’ve been doing.\n1. We have also an exciting [**new Sourcegraph integration**](/blog/sourcegraph-code-intelligence-integration-for-gitlab/) which levels up the merge request interface allowing you to navigate code, jumping to definitions or finding references.\n1. **Other improvements** we’ve shipped over the past year include [multiple assignees](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#multiple-assignees), [multiple approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#multiple-approval-rules), [code owners](https://docs.gitlab.com/ee/user/project/codeowners/), and [suggest changes][suggest-changes] – all of these were based on research and user feedback (your feedback).\n\nThese are nice improvements but they are iterating on what we already have and are not substantially changing the code review workflow. Today’s merge request experience is pretty similar to what it was five years ago – we’ve improved it a lot but its fundamental structure is the same.\n\nWe’ve been hearing feedback from users and customers about how we might improve merge requests to solve harder problems and that may require rethinking what we’ve come to accept as the default. **The merge request is a significant place, where people collaborate, where knowledge is shared, where people grow in their skills, where code quality is ensured and improved.** As a result, significant time is spent in the merge request interface. So, we’ve been asking ourselves:\n\n> _How can we significantly decrease the cycle time, increase the efficiency of code review, and create better ways of collaborating?_\n\nTo simplify our approach, we have defined **three key questions** that have also surfaced through research and our own usage:\n1. **Catch up**: Understanding where the merge request is since I last looked at it, what needs my attention, what’s changed, and helping me review that difference more efficiently after first reviewing it.\n1. **Real time collaboration**: Many teams are in the same location or same time zone and have significant overlap. Even here at GitLab, an [all-remote company](/company/culture/all-remote/), most people who work together share a few of hours of overlap and are sometimes looking at the same things. So if people are coming to the same merge request, and working on it at the same time, how can we make that more efficient?\n1. **External discussions**: Working remotely, through [asynchronous communication](https://handbook.gitlab.com/handbook/communication/#introduction), is how we mainly communicate at GitLab. It’s something that we do quite well, but sometimes it’s better to work synchronously by just getting on a call and solve confusions, communicate, sketch things out, and then document those decisions. But unfortunately, the merge request doesn’t provide a natural way to do that. We use Zoom, we use Google Docs, and then we try to summarize in merge requests or issues. What if we could integrate all of that into the merge request?\n\nTo explain what we’ve been thinking about and how we could answer these questions, here is a **short visual story**. The following images are very low-fidelity mockups so that we can focus on ideas rather than dwelling on the details.\n\n## 1. Catch up\n\n> The story starts with me, as a reviewer, coming into a merge request and looking at my personal area at the top right corner.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step1.png){: .shadow.medium.center}\n\n> I can immediately see what has happened since I last reviewed the merge request: Two files with new changes to review and one comment that needs my attention. This comment may be someone that mentioned me, someone that replied to one of my comments, or maybe someone that resolved a thread I’m participating in.\n\n## 2. Smarter suggestions\n\n> I click the speech bubble icon to jump to that comment, where Katherine, the merge request author, and James, another reviewer, are participating. Hmm, this discussion is getting a bit convoluted... but since they are in other timezones, I’ll reply with my thoughts so they can read them in their own time. It also looks like we need specific expertise here. When I start @-mentioning, I see that André was the person who last changed this line of code (and he’s also a code owner of this file). He might have an idea why this was changed, so I’ll mention him in my comment.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step2.png){: .shadow.medium.center}\n\nToday in GitLab we already suggest people who are involved in the merge request or conversation, but this idea brings in new data and more clearly highlights why people are relevant.\n\n## 3. Real time collaboration\n\n> Meanwhile, I notice that Katherine and James are **looking at this merge request right now**, by seeing their avatars popping up at the top of the merge request – _very similar to how you would see someone in Google Docs looking at the same document that you are_. I also get a notification saying that Katherine mentioned me in a comment and that James is now replying to one of my comments.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step3.png){: .shadow.medium.center}\n\nI can see people interacting with the merge request in real time, I can notice their presence, but I’m not seeing what they’re typing or collaborating directly with them – we’re just going about doing our tasks separately. **The way we work may change if we expect an immediate response.** For example, if you notice someone is online, you might ask more open-ended questions because you know that the other person can respond more quickly versus writing a longer response that seeks to conclude the discussion faster. And this is helpful not only for people that work distributed and asynchronously but also for people that work in the same time zone, in the same location, in the same office, or even in the same room.\n\n**These presence indicators create certain expectations and give a sense of progress to the merge requests as well.** When you’re waiting on a code review, you don’t know if someone has looked at it or if the reviewers are close to finishing the review. This can save people from interrupting one another. This provides a sense of progress without needing someone to take an active measure to find out if progress is being made. This is important because progress is one of those things that we all want to feel when we’re waiting on someone or something else.\n\n> Back to the story... This is great timing! Since we’re all online maybe it’s time we jump on a call to clear up the discussions together and get back on track.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step4.png){: .shadow.medium.center}\n\n> By using this dropdown button next to the avatars, I can immediately start a shared session or invite the other participants to a video call, using Zoom (one of our favorite tools here at GitLab). Starting a Zoom meeting also starts a collaborative shared session in the merge request. **In the shared session we can follow each other and write comments together in real time.** I can now follow James and Katherine and see which files they are looking at, in which lines they’re commenting, and also what they’re writing, in real time. I can also ask to be followed if I want to focus all of the participants’ attention to a specific comment or file. I can even copy a link to this shared session and share it via our chat tool or email so that others can join without having to find the merge request.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step5.png){: .shadow.medium.center}\n\nBut the most important thing is the ability to **co-author and collaborate in real time on comments in the merge request**. Not only commenting on the changes but also in the merge request overview (comments that are not attached to specific lines). You can collaborate while you’re in a video call, on the phone, or just in the office next to each other.\n\n## 4. External discussions\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step6.png){: .shadow.medium.center}\n\n> Collaborating in real time on the merge request allowed us to quickly reach a consensus. **And we could easily record everything we discussed in GitLab, instead of using separate tools.** Before ending the shared session, we add a joint comment with a summary and next steps.\n\nWe know that some teams do code reviews in meeting rooms, projecting the changes and all reviewing it together. Everyone’s got their laptops but they’re sort of looking at the same thing, but not quite. These abilities would allow everyone to take notes collaboratively, creating an interesting way of documenting. This is just one use case, there are likely many more use cases that we can solve here.\n\nYou'll notice that it looks a lot like a Google Doc, but on a merge request in GitLab. From a user experience standpoint, we must try to use metaphors and patterns that people have seen and used in other common tools. **Looking and behaving like Google Docs is a good thing because people can immediately relate and understand what these cursors and avatars mean.** But it’s about understanding these paradigms, not accepting them blindly. We strive to study and see if they fit into the situation at hand and if the users recall using this metaphor for this purpose. Using [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions) is part of our values at GitLab.\n\nToday we use Google Docs to take notes during our meetings but maybe this can replace the need to have all of these different tools open simultaneously while we’re on a video call. You can use your preferred tools, like a projector, to collaborate better depending on your work setting and what works best for you and your team, but in the end **everything is recorded in the same tool, in the same integrated environment that is GitLab.** There is no data duplication and it stops teams from using tools like Google Docs to record information that then gets replicated in merge requests and issues, instead the information can go directly into the single source of truth where the decision and discussion are relevant. If we can work out how to do this properly on merge requests we can perhaps apply it to issues and epics as well.\n\n## 5. Record decisions\n\n> Finally, in the shared session we realized that one of the changes must be documented for posterity so that we can prevent mistakes and clarify our decision. So I come back to the comment to commit it to the code base. **This adds the comment directly to the source file as a code comment.**\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step7.png){: .shadow.medium.center}\n\nOne thing that we see happening a lot at GitLab and in other companies is people explaining a decision or why we shouldn’t touch this specific part of the code, in writing. This valuable content is usually left in comments, emails, or chat messages, when it should be a _code comment_. **Code comments allow explanations, decisions, and rationale to be left for posterity so that future authors can be aware of them.**\n\nOur [suggest changes feature][suggest-changes] in merge requests allows you to include suggestions as part of your line comments. These suggestions can then be applied directly to the file where the comment was made, replacing its contents with the suggestion. With the idea of \"Commit as file comment,\" this is slightly different, as you’d be applying the comment to the file itself, as a code comment.\n\nMoving the explanation into the actual file rather than leaving it as a comment in the merge request **makes it accessible wherever the code goes**. It’s in the Git repository, it has a timestamp, it’s part of the repository history, and it’s even in your desktop IDE. It means that if you refactor your repository, split this module out into another repository, the comment follows that line of code.\n\n## Conclusion\n\n**We’re not entirely sure how these ideas will be executed, if all of them are viable, or if they’re even good ideas.** That is why we’d love to hear your thoughts on the [**feedback issue**][feedback-issue]. Share with us what you like, what you don’t like, and what other ideas you have for code review. This short story doesn’t mean that we’re going through with these ideas but that we think they are possible directions to solve those big problems that we’ve been seeing with code review at GitLab.\n\nIf you visualize the communication tools as a spectrum, right now GitLab’s merge requests are similar to email: you’re sending \"emails\" you’re receiving \"emails\" and it’s not a real time discussion, you’re not seeing what other people are typing, you don’t know when you’re going to get a response. On the other end of the spectrum is Google Docs: You see exactly what people are typing in real time, and expectations are more clear. Somewhere closer to Google Docs, you have Slack, which as a chat tool is very much focused on synchronous communication (although it can also be used for asynchronous communication). **We want to be in the middle of this communication tools spectrum, not like a Google Doc, always on, always real time, but we also don’t want to stay as an \"email client for collaborating on code.\"** We want to be smarter than that, enabling collaboration at the right moments.\n\nOne question that has been raised is **privacy**: People feel concerned about revealing when they’re looking at a merge request. Privacy is also a big concern in the sense of \"peer pressure,\" people changing their behaviors because they know they can be observed by others. We have to find some middle ground between people that opt to be more private and quietly observe things, versus people that opt for maximum efficiency and prefer collaborating in real time when everyone is in the merge request. Another concern is how to **avoid interrupting** people's flow. We anticipate that these are some of the interesting challenges we will have to wrestle with and balance against helping teams work most efficiently.\n\nThese concerns are one of the main reasons why we are sharing our ideas. We realized that these are some of our blind spots and that there could be others, so **we need** [**your feedback**][feedback-issue]. There also might be other, even more amazing, crazy ideas that we haven’t thought of yet which would take merge requests to an exciting new place. **So don’t limit your feedback to the ideas that we’ve come up with, feel free instead to share ideas that you think would make the merge request an even better place to work and get your job done.**\n\nIf you’re interested in our macro strategy and plans of how we’re going to help you better manage, plan, and create in GitLab, take a look at our [Dev strategy](/blog/dev-strategy-review/).\n\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nHelp shape the future of code review - [Share your feedback][feedback-issue]\n  \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\nCover image by [Mitchell Luo](https://unsplash.com/@mitchel3uo) on [Unsplash](https://unsplash.com/photos/H3htK85wwnU)\n{: .note}\n\n[feedback-issue]: https://gitlab.com/gitlab-org/gitlab/issues/36119\n[suggest-changes]: https://docs.gitlab.com/ee/user/discussions/#suggest-changes\n",[1264,9,1099],{"slug":2091,"featured":6,"template":698},"future-merge-requests-realtime-collab","content:en-us:blog:future-merge-requests-realtime-collab.yml","Future Merge Requests Realtime Collab","en-us/blog/future-merge-requests-realtime-collab.yml","en-us/blog/future-merge-requests-realtime-collab",{"_path":2097,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2098,"content":2104,"config":2109,"_id":2111,"_type":13,"title":2112,"_source":15,"_file":2113,"_stem":2114,"_extension":18},"/en-us/blog/get-started-compliance-as-code",{"title":2099,"description":2100,"ogTitle":2099,"ogDescription":2100,"noIndex":6,"ogImage":2101,"ogUrl":2102,"ogSiteName":685,"ogType":686,"canonicalUrls":2102,"schema":2103},"Why building compliance as code in DevOps will benefit your entire company","Read here on how to integrate compliance as code into your DevOps cycle and why it's important to have in your business","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680734/Blog/Hero%20Images/compliance-as-code-header.jpg","https://about.gitlab.com/blog/get-started-compliance-as-code","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why building compliance as code in DevOps will benefit your entire company\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n \"datePublished\": \"2019-08-19\",\n }",{"title":2099,"description":2100,"authors":2105,"heroImage":2101,"date":2106,"body":2107,"category":693,"tags":2108},[887],"2019-08-19","\n\nCompliance, both regulatory and self-imposed, is another area where the shift-left\nmovement has taken hold. By building compliance into your workflow with compliance as code methods, your\nteam can save time while producing secure, low-risk code.\n\n## What is compliance as code?\n\nCompliance as code methods ensure that the correct regulatory or company\ncompliance requirements are fulfilled with zero-touch on the path to production.\nIt builds compliance into development and operations.\n\nThe utilization of compliance as code tools enable stakeholders to ensure that production procesesses are compliant by means of defining how resources must be configured. Such a structure often allows these tools to automatically adjust resources into a compliant state in order to meet these pre-defined compliance requirements.\n\nThis type of minimal-friction compliance is a crucial solution for large\nenterprises – especially those subject to complex regulation (such as enterprises\noperating in healthcare or financial services). By building compliance into the\n[DevOps lifecycle](/topics/devops/), you will streamline the workflow and save developers valuable\ntime during review and testing.\n\n## Benefits of compliance as code\n\nAdopting compliance as code brings a number of advantages and new operational capabilities. \n\n- **It’s easier to stay compliant during compliance rule change periods.** When a change happens in regulatory compliance frameworks, awareness and remediation of any issues happen more quickly because teams don’t have to manually overhaul processes or re-train.\n- **More natural alignment between developers and risk assessment teams.** There is more unity between teams when the compliance controls are already defined as code. It’s then possible to embed compliance rules into delivery processes and enable compliant delivery by default. \n- ** A lot of time and money saved.** Automation cuts out costly and time-consuming manual work. When automated compliance as code is in place, there’s a reduced risk of costly fines and data breaches. \n- **It’s all scalable.** Adopting compliance as code means adopting consistency across teams and an organization, regardless of size. This consistency prevents ambiguity and bottlenecks in maintaining compliance. \n\n## Challenges of compliance as code\n\nDevOps means experiencing changes often and quickly, and despite the benefits that automated compliance as code brings, it can also be a challenge. It can sometimes be difficult for security to keep up with the speed of change.\n\nAnd sometimes, even automated compliance as code isn’t perfect. It’s important to remember that there’s no cap on how careful you should be when it comes to DevOps compliance. Despite having automation in place, a pair or two of human eyes open to keep watch is still useful – even if it means a possible increase in human error. \n\n## How to impliment compliance as code\n\nAs [Jim Bird wrote for O’Reilly](https://www.oreilly.com/learning/compliance-as-code),\ncompliance as code policies must be defined up front, and will bring together\nmanagement, compliance, internal audit, PMO, and infosec leaders. This group\nwill work together to define rules and control workflows. Management also needs\nto understand how operational and other risks will be handled throughout the\npipeline.\n\nHow your company does establish compliance as code policies [will depend on how your team is structured](/topics/devops/build-a-devops-team/)\nbut regardless of how your teams interact, transparency is required. To ensure\nthat information is shared and decisions are made collaboratively, consider\nestablishing the following guidelines:\n\n- **Peer reviews**: The first review cycle for larger changes should be manual, to\nensure no changes are made without at least one other person verifying the\nchange. Reviewers can be assigned randomly to ensure the quality of review.\n- **Static application security testing**: [Static\n(or white box) testing](/blog/developer-intro-sast-dast/) should be done for every code change, in addition to\nmanual reviews.\n- **Subject matter expert reviews for high-risk code**: For code that the management team defines as\nhigh-risk (such as security code), changes should be reviewed by a subject matter\nexpert.\n- **Regulated access controls**: Management should keep access in check, both so that\nchanges aren’t made by a single engineer, and so that every change flows through\nthe workflow and can be reviewed by anyone with access to the dashboard.\n\n### Enhance technology with culture\n\nTechnology and processes will only work if your team cultures are aligned with your goal – and culture starts\nat the top. Team leaders should promote and exemplify a security-first\nmentality and openness to collaborative change. This will be a new way of\nthinking for some, but it will help teams adopt the shift-left trend, ultimately\nsaving everyone time and reducing business risk.\n\n### Compliance and open source\n\nIn 2015, [The Linux Foundation found that more than 60% of companies build products with open source software](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/), but more\nthan half of those companies don’t have formal procedures in place to ensure their\nsoftware complies with open source licenses and regulations. Companies should\ncreate a free and open source software (FOSS) compliance program not only to\nabide by copyright notices and license obligations, but also to protect company\nIP and third-party source code from disclosure.\n\n## How we do compliance at GitLab\n\nWe [began our formalized compliance program](/blog/choosing-a-compliance-framework/)\ntowards the end of our Series C funding round, which was fairly early compared\nto other businesses of our size. The benefit of starting early was that we were\nable to implement security controls while we were still developing and evolving\nour operating processes, instead of retrofitting security to the business. The\nkey decision in our approach was choosing between independent or aggregate\nsecurity controls: We chose the aggregate route, leveraging [Adobe’s CCF](https://blogs.adobe.com/security/2017/05/open-source-ccf.html),\nrather than implementing industry frameworks individually. This allowed us to\nmitigate overlapping asks to GitLab teams, which enabled an agile and efficient\nprogram standup, and gave the compliance group internal credibility.\n\n## Compliance as code provides benefits across your ecosystem\n\nThere are benefits to everyone from the developer to the third-party auditor when compliance is baked into code from the beginning. These benefits include:\n- **Time saved**: Your\nteams will spend less time passing code fixes back and forth.\n- **Compliance transparency**: Management will\nunderstand where and how your software abides by compliance requirements.\n- **Routine reporting streamlines auditing**: Reports throughout the DevOps lifecycle provide documentation and proofs of\nrecord that will help management track and streamline any regulatory audit\nprocedures.\n\n## Common compliance as code tools\n\nGoogle Cloud Platform, Amazon Web Services, and Azure are all cloud services that can be used in compliance as code. And oftentimes, these tools are even more effective when paired with native tools. \n\nThrough proper tool adoption, the three core actions of a compliance strategy can be automated: prevention, detection, and remediation.\n\nCover image by [Hack Capital](https://unsplash.com/@hackcapital?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/code?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,1264,695,807,1055,912],{"slug":2110,"featured":6,"template":698},"get-started-compliance-as-code","content:en-us:blog:get-started-compliance-as-code.yml","Get Started Compliance As Code","en-us/blog/get-started-compliance-as-code.yml","en-us/blog/get-started-compliance-as-code",{"_path":2116,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2117,"content":2123,"config":2129,"_id":2131,"_type":13,"title":2132,"_source":15,"_file":2133,"_stem":2134,"_extension":18},"/en-us/blog/git-for-business-processes",{"title":2118,"description":2119,"ogTitle":2118,"ogDescription":2119,"noIndex":6,"ogImage":2120,"ogUrl":2121,"ogSiteName":685,"ogType":686,"canonicalUrls":2121,"schema":2122},"How we use Git as the blockchain for process changes","Git can be useful for more than just coding and operations. It can help you run your entire business – here's how we do it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679971/Blog/Hero%20Images/git-blockchain.jpg","https://about.gitlab.com/blog/git-for-business-processes","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we use Git as the blockchain for process changes\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n \"datePublished\": \"2019-01-15\",\n }",{"title":2118,"description":2119,"authors":2124,"heroImage":2120,"date":2126,"body":2127,"category":910,"tags":2128},[2125],"Aricka Flowers","2019-01-15","\n\nGit may have started out as a way to collaborate on code, but there’s no denying that it has crept into the operations side of things. But does it stop there? We don’t think so.\n\nJust like [blockchain technology](https://blockgeeks.com/guides/what-is-blockchain-technology/) was originally created for cryptocurrency, but is now seen as a revolutionary way to share, store and update [all kinds of data](https://www.fool.com/investing/2018/04/11/20-real-world-uses-for-blockchain-technology.aspx), we see – and use – Git in much the same way.\n\nIn addition to version controlling code and the environment in which it lives, Git can also be used at a high level to facilitate the way a company actually functions, according to our CEO [Sid Sijbrandij](/company/team/#sytses).\n\nHe says GitLab is a prime example of how it can be done.\n\n## How we use Git to run GitLab, the company\n\n\"We’re not just trying to version our code and operations, we're also trying to version all the processes we have at the company, and we do that for a whole slew of reasons,\" says Sid. \"If you write your processes down, it's easier to change and for someone to propose a change. If it's all stored in people's heads, how are you going to change it? You'll have to create a presentation and make sure everyone reads it. But if it’s written down, it's faster to make a change and you're better able to communicate the context for it.\"\n\n### How Git has helped us to scale\n\nUsing Git to implement procedural changes within the company has helped GitLab shoulder growing pains, thanks to our [handbook](https://handbook.gitlab.com/handbook/).\n\n\"Although we're not a perfect company by any means, we've been able to scale really rapidly, onboard people and get them started with the work they have to do,\" Sid says. \"And I think our handbook and how we describe things is an important part of that. It's exciting to see it grow. The handbook is now over 2,000 pages, so people can't read everything anymore, but they can read the parts that are relevant to them, and it's really helping with organizational changes that are happening between different departments.\"\n\nSid admits running a business with Git collaboration can seem like a daunting task, especially for companies that did not start out functioning that way. But he urges business leaders to give the process a chance, pointing to a number of companies that are adopting Git as a way to make procedural changes, including O’Reilly Media and several law firms.\n\n## Two tips for adopting Git to run your business\n\n### 1. Evangelize from the top down\n\n\"First of all, this is super hard. It's unnatural and it requires constant campaigning from the top of the company,\" Sid said. \"The natural state is for all the documentation to get out of date, and for people to send each other emails and PowerPoints about the change they want to make without looking at the rest of the changes.\"\n\n### 2. Make processes easier to change\n\n\"What you frequently find in companies is that there's the official process, and then the process that people really use. You can prevent that by making processes easier to change. The reality is people are changing processes in a company every single day, and they have to make those changes quickly. So the harder you make it, the more diversions there will be between reality and what's in the handbook. Instead, empower everyone in the organization to make those changes and do so quickly. That is one of the most important things you can do.\"\n\n\"Our handbook is [Creative Commons](https://creativecommons.org/licenses/by-sa/4.0/), so feel free to use that as a starting point for anything that you do.\" [Tweet us](http://twitter.com/gitlab) if you do borrow from or adapt our handbook – we'd love to hear about it.\n\n[Cover image](https://unsplash.com/photos/mf-o1E7omzk) by [chuttersnap](https://unsplash.com/@chuttersnap) on Unsplash\n{: .note}\n",[9,1242,934,787,912],{"slug":2130,"featured":6,"template":698},"git-for-business-processes","content:en-us:blog:git-for-business-processes.yml","Git For Business Processes","en-us/blog/git-for-business-processes.yml","en-us/blog/git-for-business-processes",{"_path":2136,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2137,"content":2143,"config":2150,"_id":2152,"_type":13,"title":2153,"_source":15,"_file":2154,"_stem":2155,"_extension":18},"/en-us/blog/git-not-just-for-developers",{"title":2138,"description":2139,"ogTitle":2138,"ogDescription":2139,"noIndex":6,"ogImage":2140,"ogUrl":2141,"ogSiteName":685,"ogType":686,"canonicalUrls":2141,"schema":2142},"Git: Not just for developers","How one company helps video editors, developers, and project managers to collaborate on interactive video, by leveraging the power of open source.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670464/Blog/Hero%20Images/gitlab-loves-open-source.jpg","https://about.gitlab.com/blog/git-not-just-for-developers","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Git: Not just for developers\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Opher Vishnia\"},{\"@type\":\"Person\",\"name\":\"Roy Taragan\"}],\n \"datePublished\": \"2018-05-24\",\n }",{"title":2138,"description":2139,"authors":2144,"heroImage":2140,"date":2147,"body":2148,"category":784,"tags":2149},[2145,2146],"Opher Vishnia","Roy Taragan","2018-05-24","\nIn this post I’d like to tell you about how, at [Eko](https://helloeko.com/), we’re using GitLab CE to allow professionals from different disciplines, such as video editors, designers, and software engineers, to collaborate on creating and publishing Interactive Video projects using the Eko platform.\n\nEko is a unique company. I know practically every company says that about itself, but for us that’s doubly true in that both our platform as well as our users, and our users of users, take part and actively contribute to creative, experimental ideas and technology. At the core of what we do is an exciting new medium called Interactive Video, which enhances storytelling by bridging the gap between the creator and the viewer. The projects themselves are somewhere between a TV show and a video game. These embody a range of creativity - from the [official music video for Bob Dylan’s “Like a Rolling Stone,”](https://helloeko.com/mindblown/beats-and-rhymes?publisherID=gitlab) through choose-your-own-adventure style comedies and high-caliber movie studio productions like #WarGames.\n\n[![Bob Dylan's Like a Rolling Stone video](https://about.gitlab.com/images/blogimages/eko_mind_blown.png)](https://helloeko.com/mindblown/beats-and-rhymes?publisherID=gitlab)\n\nOur development body creates all the technology for both viewing and authoring these experiences, which are created by small indies as well as big studios and production houses. At the end of the day though, all of these projects, regardless of whether they’re playing on desktop, mobile, or the Xbox, are built with web technologies and run in a browser. Each project is served as a web app, consisting of HTML, JavaScript and CSS files, as well as its video, audio and image assets.\n\nTo create these projects, Eko offers a web-based, drag-and-drop interface called Eko Studio. This software provides project creators with an easy interface for uploading and assembling video, connecting the different videos to each other, creating GUI to define the underlying creativity and finally publishing the finished product.\n\n![Eko Studio](https://about.gitlab.com/images/blogimages/eko-guest-post/eko-studio.png)\n\nIn cases where extra logic and functionality is required, such that isn’t yet covered by the set of features in Eko Studio, we offer the Eko SDK, which enables developers to extend the Studio’s functionality by writing their own custom JS and CSS code.\n\nThe interesting thing about the creation process of our Interactive Video projects is because of their scope and multi-disciplinary nature, different people with different roles all work on the same project at the same time. For example, a video editor might upload a new scene, a project manager would change the SEO copy and a developer might implement new GUI or functionality. One of the challenges we faced at Eko is that all of this needs to be synchronised and shared by all. The experience needs to be fluid and cohesive for all types of users, regardless of their role.\n\n![Eko Studio commits](https://about.gitlab.com/images/blogimages/eko-guest-post/eko-studio-commits.png)\n\n## Using open source to enable collaboration\n\nSo what type of software allows for multiple people to work on the same project without stepping on each other’s toes? Git, of course! With that in mind we set out to find how can we use Git as a backend that could serve our creators, developers and non-developers alike.\n\nIn Eko Studio, users can activate the feature that allows extending a project with code. Behind the scenes, the studio then employs GitLab’s API to create a new repository, generates all the code reflecting the current state of the project, and pushes it as the *initial commit*. From this point forward, each time a preview or published version of the project is generated, the process will begin by first pulling the latest version of the code from the repo. Using GitLab’s webhook for push events combined with Firebase, any time a commit is pushed to the repository, the user in Eko Studio is notified and the UI is updated accordingly. The user in Eko Studio can see all the commits (also fetched using the GitLab API) listed as versions, and can revert to an earlier version.\n\n>The less tech-savvy users aren’t even fully aware that by editing the project or adding content they are in fact publishing commits in the project repo\n\nThe cool thing here though, is that the Eko Studio itself acts as a Git client behind the scenes. The less tech-savvy users aren’t even fully aware that by editing the project or adding content they are in fact publishing commits in the project repo. The studio interface makes this completely transparent for them. Changes to the project made in Eko Studio are translated into Git commits in the project repo. Over on the dev side though, the software engineers use the Git interface itself using their favorite code editor and Git client.\n\n![Eko Studio code panel](https://about.gitlab.com/images/blogimages/eko-guest-post/eko-studio-code-panel.png)\n\nThe fact that GitLab is open source enabled us to custom tailor a solution for our users with minimal changes, leveraging APIs and webhooks to connect our own infrastructure. The readily available AMI meant that we can easily spool up our own GitLab CE instances without a complicated setup process. While our use case is very specific, the fact we’ve been able to use GitLab CE with minimal effort to implement our platform and tools for creating Interactive Video definitely highlights the flexibility and capabilities of GitLab!\n",[1242,9,787],{"slug":2151,"featured":6,"template":698},"git-not-just-for-developers","content:en-us:blog:git-not-just-for-developers.yml","Git Not Just For Developers","en-us/blog/git-not-just-for-developers.yml","en-us/blog/git-not-just-for-developers",{"_path":2157,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2158,"content":2164,"config":2170,"_id":2172,"_type":13,"title":2173,"_source":15,"_file":2174,"_stem":2175,"_extension":18},"/en-us/blog/gitlab-and-jira-integration-the-final-steps",{"title":2159,"description":2160,"ogTitle":2159,"ogDescription":2160,"noIndex":6,"ogImage":2161,"ogUrl":2162,"ogSiteName":685,"ogType":686,"canonicalUrls":2162,"schema":2163},"GitLab and Jira integration: the final steps","The last of our three-part series on GitLab and Jira integrations offers a step-by-step look at how the tools work together.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679490/Blog/Hero%20Images/jira-importer-blog-post.png","https://about.gitlab.com/blog/gitlab-and-jira-integration-the-final-steps","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab and Jira integration: the final steps\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Tye Davis\"}],\n \"datePublished\": \"2021-05-24\",\n }",{"title":2159,"description":2160,"authors":2165,"heroImage":2161,"date":2167,"body":2168,"category":1053,"tags":2169},[2166],"Tye Davis","2021-05-24","\n_This is the third in our three-part series on GitLab and Jira integrations. [Part one](/blog/integrating-gitlab-com-with-atlassian-jira-cloud/) explained how to integrate GitLab.com with Jira Cloud. [Part two](/blog/gitlab-jira-integration-selfmanaged/) walked through a detailed explanation of integrating GitLab self-managed with Jira._\n\nAfter the integration is set up on GitLab and Jira, you can:\n\n* Refer to any Jira issue by its ID in GitLab branch names, commit messages, and merge request titles.\n\n* Using commit messages in GitLab, you have the ability to move Jira issues along that Jira projects defined transitions. Here you can see that this Jira issue has Backlog, Selected for Development, In Progress and Done. \n\n![Issue View in Jira](https://about.gitlab.com/images/blogimages/atlassianjira/issueview.png){: .shadow.medium.center}\nIssue View in Jira\n{: .note.text-center}\n\n* As referenced in the Base GitLab-Jira integration, when you comment in a merge request and commit referencing an issue, e.g., PROJECT-7, will add a comment in Jira issue in the format. In addition, by commenting in a jira transition (putting a “#” first), this will initiate the movement of a Jira Issue to the desired transition. Below is using the built-in GitLab Web IDE (this can be done in your Web IDE of choice as well).\n\n![Comment in a Commit/MR](https://about.gitlab.com/images/blogimages/atlassianjira/commitcomment.png){: .shadow.medium.center}\nComment in a Commit/MR\n{: .note.text-center}\n\n* Currently, the Jira-GitLab Dev Panel integration via DVCS refreshes on a 60-min schedule. To expedite, you’ll need to manually refresh the specific project with your most recent changes.\n\n![Dev Panel refreshes every 60 minutes](https://about.gitlab.com/images/blogimages/atlassianjira/devpanelrefresh.png){: .shadow.medium.center}\nDev Panel refreshes every 60 minutes\n{: .note.text-center}\n\n* See the linked branches, commits, and merge requests in Jira issues (merge requests are called “pull requests” in Jira issues).\nJira issue IDs must be formatted in uppercase for the integration to work.\n\n![See GitLab linked in the Dev Panel](https://about.gitlab.com/images/blogimages/atlassianjira/gitlabdevpanel.png){: .shadow.medium.center}\nSee GitLab linked in the Dev Panel\n{: .note.text-center}\n\n* Click the links to see your GitLab repository data.\n\n![Click into the commits](https://about.gitlab.com/images/blogimages/atlassianjira/clickintocommit.png){: .shadow.medium.center}\nClick into the commits\n{: .note.text-center}\n\n![See GitLab linked in the Dev Panel](https://about.gitlab.com/images/blogimages/atlassianjira/clickintopr.png){: .shadow.medium.center}\nClick into the merge (pull) requests\n{: .note.text-center}\n\nFor more information on using Jira Smart Commits to track time against an issue, specify an issue transition, or add a custom comment, see the Atlassian page Using [Smart Commits](https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html)\n\n## View Jira Issues within GitLab\n\nYou can browse and search issues from a selected Jira project directly in GitLab. This requires configuration in GitLab by an administrator.\n\n* In the GitLab integration setup for Jira, click \"enable Jira issues.\"\n\n![Enable Jira issues in GitLab](https://about.gitlab.com/images/blogimages/atlassianjira/enablejiraissues.png){: .shadow.medium.center}\nEnable Jira issues in GitLab\n{: .note.text-center}\n\n* Locate your project key in Jira.\n\n![Locate your project key in Jira](https://about.gitlab.com/images/blogimages/atlassianjira/locateprojectkey.png){: .shadow.medium.center}\nLocate your project key in Jira\n{: .note.text-center}\n\n* Add your proejct key into the GitLab integration setup for Jira.\n\n![Add your proejct key to GitLab](https://about.gitlab.com/images/blogimages/atlassianjira/addprojectkey.png){: .shadow.medium.center}\nAdd your proejct key to GitLab\n{: .note.text-center}\n\n* Select \"Jira Issues\", then \"Issue List\" from the left panel in GitLab\n\n![Select Jira Issues on left panel](https://about.gitlab.com/images/blogimages/atlassianjira/selectjiraissues.png){: .shadow.medium.center}\nSelect Jira Issues\n{: .note.text-center}\n\nFrom the Jira Issues menu, click Issues List. The issue list defaults to sort by Created date, with the newest issues listed at the top. You can change this to Last updated.\nIssues are grouped into tabs based on their [Jira status](https://confluence.atlassian.com/adminjiraserver070/defining-status-field-values-749382903.html).\n\n* The Open tab displays all issues with a Jira status in any category other than Done.\n* The Closed tab displays all issues with a Jira status categorized as Done.\n* The All tab displays all issues of any status.\n\nClick an issue title to open its original Jira issue page for full details.\n\n![View Jira issues in GitLab](https://about.gitlab.com/images/blogimages/atlassianjira/viewjiraissues.png){: .shadow.medium.center}\nView Jira issues in GitLab\n{: .note.text-center}\n\n### Search and filter the issues list\n\nTo refine the list of issues, use the search bar to search for any text contained in an issue summary (title) or description.\nYou can also filter by labels, status, reporter, and assignee using URL parameters. Enhancements to be able to use these through the user interface are [planned](https://gitlab.com/groups/gitlab-org/-/epics/3622).\n\n* To filter issues by labels, specify one or more labels as part of the labels[] parameter in the URL. When using multiple labels, only issues that contain all specified labels are listed. /-/integrations/jira/issues?labels[]=backend&labels[]=feature&labels[]=QA\n* To filter issues by status, specify the status parameter in the URL. /-/integrations/jira/issues?status=In Progress\n* To filter issues by reporter, specify a reporter’s Jira display name for the author_username parameter in the URL. /-/integrations/jira/issues?author_username=John Smith\n* To filter issues by assignee, specify their Jira display name for the assignee_username parameter in the URL. /-/integrations/jira/issues?assignee_username=John Smith\n\n## Troubleshooting\nIf these features do not work as expected, it is likely due to a problem with the way the integration settings were configured.\n\n### GitLab is unable to comment on a Jira issue\n\nMake sure that the Jira user you set up for the integration has the correct access permission to post comments on a Jira issue and also to transition the issue, if you’d like GitLab to also be able to do so. Jira issue references and update comments will not work if the GitLab issue tracker is disabled.\n\n### GitLab is unable to close a Jira issue\n\nMake sure the Transition ID you set within the Jira settings matches the one your project needs to close an issue.\nMake sure that the Jira issue is not already marked as resolved; that is, the Jira issue resolution field is not set. (It should not be struck through in Jira lists.)\n\n## Conclusion\n \nGitLab helps teams ship software faster with technology integration options, such as the integration with Jira, that automate tasks, provide visibility into development progress and the greater end-to-end software lifecycle. We recognize that many companies use Jira for Agile project management and our seamless integration brings Jira together with GitLab. \n\n## Watch and learn\n\nMore of a video person? For a walkthrough of the integration with GitLab for Jira, watch and learn how to configure GitLab Jira Integration using Marketplace App.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/fWvwkx5_00E\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n",[9,232,695],{"slug":2171,"featured":6,"template":698},"gitlab-and-jira-integration-the-final-steps","content:en-us:blog:gitlab-and-jira-integration-the-final-steps.yml","Gitlab And Jira Integration The Final Steps","en-us/blog/gitlab-and-jira-integration-the-final-steps.yml","en-us/blog/gitlab-and-jira-integration-the-final-steps",{"_path":2177,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2178,"content":2184,"config":2190,"_id":2192,"_type":13,"title":2193,"_source":15,"_file":2194,"_stem":2195,"_extension":18},"/en-us/blog/gitlab-and-reproducibility",{"title":2179,"description":2180,"ogTitle":2179,"ogDescription":2180,"noIndex":6,"ogImage":2181,"ogUrl":2182,"ogSiteName":685,"ogType":686,"canonicalUrls":2182,"schema":2183},"How GitLab can help in research reproducibility","NYU reproducibility librarian Vicky Steeves shares why GitLab is her choice for ongoing collaborative research, and how it can help overcome challenges with sharing code in academia.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672928/Blog/Hero%20Images/gitlab-and-reproducibility.jpg","https://about.gitlab.com/blog/gitlab-and-reproducibility","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab can help in research reproducibility\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vicky Steeves\"}],\n \"datePublished\": \"2017-08-25\",\n }",{"title":2179,"description":2180,"authors":2185,"heroImage":2181,"date":2187,"body":2188,"category":784,"tags":2189},[2186],"Vicky Steeves","2017-08-25","GitLab is a great platform for active, ongoing, collaborative research. It\nenables folks to work together easily and share that work in the open. This\nis especially poignant given the problems in sharing code in academia,\nacross time and people.\n\n\n\u003C!-- more -->\n\n\n![phd-code-comic](https://phdcomics.com/comics/archive/phd031214s.gif)\n\n\nIt's no surprise that GitLab, a platform for collaborative coding and Git\nrepository hosting, has features for reproducibility that researchers can\nleverage for their own and their communities’ benefit.\n\n\n### What exactly is reproducibility?\n\n\nReproducibility is a core component in a variety of work, from software\nengineering to research. For software engineers, the ability to reproduce\nerrors or functionality is key to development. For researchers,\nreproducibility is about independent verification of results/methods, to\nbuild on top of previous work, and to increase the impact, visibility, and\nquality of research. Y’know. That Sir Isaac Newton quote in every\nreproducibility presentation ever: \"If I have seen further, it is by\nstanding on the shoulders of giants.\"\n\n\nLike all things, reproducibility exists on a spectrum. I like Stodden et\nal’s definitions from the [2013 ICERM\nreport](http://stodden.net/icerm_report.pdf), so I’ll use those:\n\n\n| ICERM Report\nDefinitions\n| Potential Real-World\nExamples\n|\n\n|:-----------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------|\n\n| Reviewable Research: Sufficient detail for peer review and\nassessment | The code and data are openly\navailable\n|\n\n| Replicable Research: Tools are available to duplicate the author’s results\nusing their data | The tools (software) used in the analysis are freely\navailable for others to confirm results |\n\n| Confirmable Research: Main conclusions can be attained independently\nwithout author’s software | Others can reach the conclusion using similar\ntools, not necessarily the same as the author, or on a different operating\nsystem |\n\n| Auditable Research: Process and tools archived such that it can be\ndefended later if necessary | The tools, environment, data, and code are\nput into a preservation-ready\nformat |\n\n| Open/Reproducible Research: Auditable research made openly\navailable | Everything above is made available in\na repository for others to examine and\nuse |\n\n\nThe last bullet there is the goal – open and reproducible research.\nReleasing code and data are key to open research, but not necessarily enough\nfor reproducibility. This is where the concept of computational\nreproducibility becomes important, where whole environments are captured.\nYou could also look at it this way:\n\n\n![reproducibility-pyramid](https://osf.io/8rx9y/download)\n\n\n### How can GitLab help?\n\n\nThere are a few solutions out there, including containers (such as Docker or\nSingularity) for active research, and [o2r](http://o2r.info/) and\n[ReproZip](https://reprozip.org) for capturing and reproducing completed\nresearch. For this post, I’m going to focus on active research and\ncontainers.\n\n\nI like GitLab for research reproducibility because it makes working together\nsimple, and seamless. There’s no hacking together 100 different third-party\nservices. GitLab has hosting, LFS, and integrated Continuous Integration for\nfree, for both public and private repositories! Everything is integrated in\na single GitLab repository which, if made publicly available, can enable\nsecondary users to reproduce results in a more streamlined fashion. You can\nalso keep these private to a group – you control the visibility of\neverything in one repository in one place, as opposed to updating\npermissions across multiple services.\n\n\nThere are a few key features that set GitLab apart when it comes to\ncontainers and reproducibility. The first is that GitLab doesn’t use a\nthird-party service for continuous integration. It’s shipped with CI runners\nwhich can use Docker images from GitLab’s registry. Basically, you can use\nthe Docker Container Registry, a secure, private Docker registry, to choose\na container that GitLab CI uses to run each job in a separate and isolated\ncontainer.\n\n\n![gitlab-ci-repro](https://about.gitlab.com/images/ci/arch-1.jpg)\n\n\nIf you don’t feel like using the GitLab registry, you can also use images\nfrom DockerHub or a custom Docker container you’re already using locally.\nThese can be integrated with GitLab CI, and if made public, any secondary\nusers can use it as well!\n\n\n### Let's look at an example\n\n\nThis process is set up in a single file, a `.gitlab-ci.yml`. Another feature\nthat makes my life easier – GitLab can syntax-check the CI config files! The\n`.gitlab-ci.yml` file describes the pipelines and stages, each of which has\na different function and can have its own tags, produce its own artifacts,\nand reuse artifacts from other stages. These stages can also run in parallel\nif needed. Here’s an example of what a basic config file looks like with R:\n\n\n```\n\nimage: jangorecki/r-base-dev\n\ntest:\n script:\n - R CMD build . --no-build-vignettes --no-manual\n - PKG_FILE_NAME=$(ls -1t *.tar.gz | head -n 1)\n - R CMD check \"${PKG_FILE_NAME}\" --no-build-vignettes --no-manual --as-cran\n```\n\n\nAnd here’s an example of building a website using the GitLab and the static\nsite generator, Nikola:\n\n\n```\n\nimage: registry.gitlab.com/paddy-hack/nikola:7.8.7\n\ntest:\n script:\n - nikola build\n except:\n - master\n\npages:\n script:\n - nikola build\n artifacts:\n paths:\n - public\n only:\n - master\n```\n\n\nIt’s also worth noting that you can use different containers per step in\nyour workflow, if you outline it in your .gitlab-ci.yml. If your data\ncollection script runs in one environment but your analysis script needs\nanother, that’s perfectly fine using GitLab, and others have the information\nto reproduce it easily! Another feature that puts GitLab apart is that a\nbuild of one project can trigger a build of another – AKA, multi-project\npipelines. For those of you working with big data, you can automatically\nspin up and down VMs to make sure your builds get processed immediately with\nGitLab’s CI as well.\n\n\nHere are some other great resources and examples of using GitLab to make\nresearch more reproducible:\n\n\n+ [Gitlab-CI for R packages](https://gitlab.com/jangorecki/r.gitlab.ci)\n\n+ [Blog Post explaining GitLab + reproducibility - Jon\nZelner](http://www.jonzelner.net/statistics/make/docker/reproducibility/2016/05/31/reproducibility-pt-1/)\n\n+ [GitLab repo accompanying blog post - Jon\nZelner](https://gitlab.com/jzelner/reproducible-stan)\n\n+ [Continuous Integration with Gitlab - Tony\nWildish](https://www.nersc.gov/assets/Uploads/2017-02-06-Gitlab-CI.pdf)\n\n\nBeyond reproducibility, there are a lot of features that make GitLab an\nideal place for me to work and organize my research. I’d urge folks to look\nat the [feature list](/pricing/feature-comparison/) and see how they can get started!\n\n\n## About the Guest Author\n\n\nVicky Steeves is the Librarian for Research Data Management and\nReproducibility at New York University, a dual appointment between the\nDivision of Libraries and Center for Data Science. In this role, she works\nsupporting researchers in creating well-managed, high quality, and\nreproducible research through facilitating use of tools such as ReproZip.\nHer research centers on integrating reproducible practices into the research\nworkflow, advocating openness in all facets of scholarship, and\nbuilding/contributing to open infrastructure.\n\n\n“[research](https://www.flickr.com/photos/alovesdc/3464555556/)” by [a loves\ndc](https://www.flickr.com/photos/alovesdc/) is licensed under [CC BY\n2.0](https://creativecommons.org/licenses/by/2.0/legalcode)\n\n{: .note}\n",[787,9,1263],{"slug":2191,"featured":6,"template":698},"gitlab-and-reproducibility","content:en-us:blog:gitlab-and-reproducibility.yml","Gitlab And Reproducibility","en-us/blog/gitlab-and-reproducibility.yml","en-us/blog/gitlab-and-reproducibility",{"_path":2197,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2198,"content":2203,"config":2209,"_id":2211,"_type":13,"title":2212,"_source":15,"_file":2213,"_stem":2214,"_extension":18},"/en-us/blog/gitlab-and-testify-sec-witness-alliance",{"title":2199,"description":2200,"ogTitle":2199,"ogDescription":2200,"noIndex":6,"ogImage":1131,"ogUrl":2201,"ogSiteName":685,"ogType":686,"canonicalUrls":2201,"schema":2202},"How to enhance supply chain security with GitLab and TestifySec","New alliance partner TestifySec makes Witness available in GitLab","https://about.gitlab.com/blog/gitlab-and-testify-sec-witness-alliance","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to enhance supply chain security with GitLab and TestifySec\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nicole Schwartz\"}],\n \"datePublished\": \"2022-03-16\",\n }",{"title":2199,"description":2200,"authors":2204,"heroImage":1131,"date":2206,"body":2207,"category":1053,"tags":2208},[2205],"Nicole Schwartz","2022-03-16","\n\n_This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._\n\nToday, GitLab is excited to announce that our partner [TestifySec](https://www.testifysec.com/) has integrated their [Witness](https://github.com/testifysec/witness) open-source tool into GitLab allowing us to take another step along our [Secure Software Supply Chain Direction](https://about.gitlab.com/direction/supply-chain/).\n\n## Secure software supply chain \n\nAn emerging concern in the software development space is being able to secure your software supply chain, an important element of which is documenting the entire supply chain and development progress by creating a chain of custody starting from code creation, build, test, package, and going through deployment. One important element of this chain of custody is commonly referred to as a Software Bill of Materials [SBOM](https://www.ntia.gov/SBOM). There are also frameworks, such as [SLSA](https://slsa.dev/) which collect additional elements about the process. Together these documents are becoming critical components to satisfying regulated industry requirements.\n\nThere are many opportunities as a DevOps Platform to rise to the challenge of creating transparency around software components or artifacts. \n\n## TestifySec Witness\n\nRecent compromises and attacks on the software supply chain such as Solarburst and Log4shell highlight the need for a new way of securing CI systems and their artifacts. This is why [TestifySec](https://www.testifysec.com/) created [Witness](https://github.com/testifysec/witness).\n\nCI systems are an incredible source of data. Many CI systems such as GitLab, along with their cloud infrastructure, provide tokens with non-falseable data. Witness verifies and records this data, along with inputs and outputs from a CI process in a verifiable and standardized way.\n\nIn current generation CI systems we restrict the release of artifacts based on pass or failure of build steps. However, most organizations have no standardized way to leverage the metadata available during the CI process in order to inform policy decisions in production environments.\n\nIn next-generation CI systems, data collected during the CI process is not thrown away. Instead, we make this data available to security administrators for use at any policy enforcement point. With [Witness](https://github.com/testifysec/witness), you shift security left, while communicating risk right. \n\nOnce an artifact is built it becomes difficult to understand where it was built. Most major cloud providers provide some sort of identity mechanism to verify the instance identity. On AWS this is called the Instance metadata service. The data available in this API is verifiable and is a perfect data structure to make an Witness attestation.\n\nWitness records AWS identity metadata and cryptographically links it to the build artifact and any other events in that CI process. \n\nYou can [see the demo](https://gitlab.com/testifysec/demos/witness-demo).\n\nGitLab and TestifySec will be enhancing our features around this as time goes on - keep an eye out for more!\n\nRead more about GitLab's [Secure Software Supply Chain Direction](https://about.gitlab.com/direction/supply-chain/).\n",[807,9,912],{"slug":2210,"featured":6,"template":698},"gitlab-and-testify-sec-witness-alliance","content:en-us:blog:gitlab-and-testify-sec-witness-alliance.yml","Gitlab And Testify Sec Witness Alliance","en-us/blog/gitlab-and-testify-sec-witness-alliance.yml","en-us/blog/gitlab-and-testify-sec-witness-alliance",{"_path":2216,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2217,"content":2222,"config":2227,"_id":2229,"_type":13,"title":2230,"_source":15,"_file":2231,"_stem":2232,"_extension":18},"/en-us/blog/gitlab-at-scale",{"title":2218,"description":2219,"ogTitle":2218,"ogDescription":2219,"noIndex":6,"ogImage":1462,"ogUrl":2220,"ogSiteName":685,"ogType":686,"canonicalUrls":2220,"schema":2221},"Join the GitLab Community Day at SCaLE 18x!","If you're attending SCaLE 18x, here's how you can find the GitLab community at the event.","https://about.gitlab.com/blog/gitlab-at-scale","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Join the GitLab Community Day at SCaLE 18x!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2020-02-17\",\n }",{"title":2218,"description":2219,"authors":2223,"heroImage":1462,"date":2224,"body":2225,"category":716,"tags":2226},[1281],"2020-02-17","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nWe just returned from [FOSDEM](https://fosdem.org/2020/), where we had a great time meeting with and talking to GitLab community members. We will be on the road again to Southern California in a few weeks at [SCaLE 18x](https://www.socallinuxexpo.org/scale/18x), and hope to meet with wider GitLab community members at the event! If you are not familiar with SCaLE, it is the largest volunteer-organized open-source and free software event in North America. This year will be the 18th edition of the conference, and the SCaLE team provided us with a 40% discount code for GitLab community. When you [register](https://register.socallinuxexpo.org/reg6/), you can use the code `GIT` for the discount!\n\n### GitLab Community Day\n\nThis year, we are organizing a [GitLab Community Day](https://www.socallinuxexpo.org/scale/18x/gitlab-community-day), where we will have a discussion on resources for the wider community, a hands-on workshop on how you can contribute to GitLab, and a tutorial on how to use GitLab.\n\nSeveral team members from the [GitLab Developer Relations team](https://about.gitlab.com/company/team/?department=community-relations) will be at SCaLE 18x this time around. If you're interested in learning more about GitLab's programs for supporting code contributors, educational institutions, evangelists, open source communities, and more, we'd love to meet you in person.\n\n- **WHEN**: Friday, March 6th, from 1:30 p.m to 5:30 p.m. \n- **WHERE**: **Ballroom F** at the Pasadena Convention Center\n\nYou can find more information on topics and speakers on the [Gitlab Community Day issue](https://gitlab.com/gitlab-com/marketing/community-relations/evangelist-program/general/issues/900). You are welcome to add feedback or suggestions directly on the issue. \n\n### DevOpsDay LA \n\nGitLab will again be a sponsor for [DevOpsDay LA](https://www.socallinuxexpo.org/scale/18x/devopsday-la) at SCaLE, and we will have a **GitLab booth** in the DevOpsDay LA exhibit area on March 6th. If you want to come talk to GitLab team members about anything DevOps, please swing by our booth and checkout some GitLab swag. Speaking of swag, there will also be a raffle at 3:35pm where the winner will get a Nintendo Switch! So, please be sure to enter the raffle while you visit the GitLab booth. \n\n- **WHEN**: Friday, March 6th, all day \n- **WHERE**: **Ballroom DE** at the Pasadena Convention Center\n\n\n### Talks given by GitLab team members at SCaLE 18x\n\nA couple of GitLab team members will be speaking at the conference:\n\n- On Friday March 6th, [Francis Potter](https://gitlab.com/francispotter) will discuss [The Future of DevOps and the Importance of Right-to-Left Thinking](https://www.socallinuxexpo.org/scale/18x/presentations/future-devops-and-importance-right-left-thinking) in the DevOps track.\n- On Saturday March 7th, I ([Ray Paik](https://gitlab.com/rpaik)) will be talking about [Building a thriving community in (for-profit) open source projects](https://www.socallinuxexpo.org/scale/18x/presentations/building-thriving-community-profit-open-source-projects) in the Mentoring track. \n\n\n\nPlease come say hi 👋 at SCaLE, and we look forward to seeing many of you in sunny Southern California!\n",[268,9,787],{"slug":2228,"featured":6,"template":698},"gitlab-at-scale","content:en-us:blog:gitlab-at-scale.yml","Gitlab At Scale","en-us/blog/gitlab-at-scale.yml","en-us/blog/gitlab-at-scale",{"_path":2234,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2235,"content":2241,"config":2246,"_id":2248,"_type":13,"title":2249,"_source":15,"_file":2250,"_stem":2251,"_extension":18},"/en-us/blog/gitlab-education-virtual-meetup",{"title":2236,"description":2237,"ogTitle":2236,"ogDescription":2237,"noIndex":6,"ogImage":2238,"ogUrl":2239,"ogSiteName":685,"ogType":686,"canonicalUrls":2239,"schema":2240},"GitLab for Education: First Virtual Meetup","The GitLab for Education Program is excited to announce our first global virtual meetup on May 6th!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669510/Blog/Hero%20Images/classroom.jpg","https://about.gitlab.com/blog/gitlab-education-virtual-meetup","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab for Education: First Virtual Meetup\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"}],\n \"datePublished\": \"2020-04-28\",\n }",{"title":2236,"description":2237,"authors":2242,"heroImage":2238,"date":2243,"body":2244,"category":716,"tags":2245},[1136],"2020-04-28","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nThe GitLab for Education Program is excited to announce our first global virtual meetup on May 6th ([1:00 pm EDT/ 5:00 pm UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200506T1700))!\n\n## About GitLab Meetups\n\nGitLab has a vibrant global meetup community with over 10,000 members from 20 plus countries. If you are new to GitLab meetups, they are events organized by our community members, community groups, or GitLab team members, where people get together to network, share ideas, and learn more about a broad range of topics in DevOps. Generally, there are speakers and some Q&A with plenty of time for interaction between attendees. While the majority of our previous meetups were in person, we recently launched virtual meetups with great success! We love virtual meetups because they can be more efficient, more collaborative, and more diverse and inclusive.\n\n## GitLab for Education\n\nThe [GitLab for Education Program](/solutions/education/), one of several programs run by the [Developer Relations team](/handbook/marketing/developer-relations/#our-mission), is where we foster the adoption of GitLab at educational institutions ranging from primary school up through Universities by providing free licenses of GitLab Gold or Ulitmate for the purposes of [teaching, learning, or research to qualifying educational institutions](/handbook/marketing/developer-relations/community-programs/education-program/#education-program-requirements). We are thrilled with the success thus far - we’ve issued **1.486 million seats to 800 institutions in 65 countries around the world** - and we’re excited to build on this organic interest and take the program to the next level.\n\nAs we look forward to expanding our GitLab for Education Program in 2020, our primary goal is to foster a vibrant community for building relationships and sharing knowledge for all things related to education and DevOps. In this spirit, we’re excited to announce our first-ever Education Program Virtual Meetup. We invite anyone who is interested to join us - you do not need to be a current Education Program member to attend. Our focus on the Developer Relations team has been to create a community where [everyone can contribute](/company/mission/#mission) and we are thrilled to extend these efforts into growing the education community.\n\n### Here is an overview of what we’ll cover:\n\n#### Introduction to our Team Members and overview of the GitLab for Education Program\n\nWe’ll start by introducing a few of our team members, John Coghlan our Senior Evangelist Program Manager, and Christina Hupy our Senior Education Program Manager. John runs our GitLab Meetup and GitLab Heroes programs. Next, we’ll introduce Christina (that’s me!), who runs our GitLab for Education Program, and a few our Community Advocates. Then we’ll highlight a few key points about the GitLab for Education Program such as the types of licenses we offer, how your institution can sign up for them, and how you can contribute directly by engaging with us on issues on GitLab itself. We’ll answer any questions you might have about the program.\n\n#### We’ll touch on a broad range of topics including:\n\n* **Use Cases**\n * How is your institution using GitLab? We’d love to learn more about how your institution is using GitLab or how you are thinking about using GitLab if you are not yet signed up.\n\n* **Challenges**\n * What are your biggest challenges in growing adoption of DevOps on your campus? Share ideas with us on what challenges you face while implementing and growing adoption of GitLab at your institution.\n\n* **Resources**\n * What kinds of resources have been and would be most useful to you while using GitLab at your institution? What organizations have been you been involved with? As we continue to grow the Education Program, providing resources to our education community is a top priority. We’d love to hear from you on what would help you be successful.\n\n### Why join us?\n\nThis is a great opportunity to grow your network in education whether you are a student learning DevOps or a faculty or staff looking to share best practices for implementation on campus. Meetups are also a great way to increase your skillset by learning more about DevOps and GitLab alike. They are great forums for sharing ideas that could inspire you in your everyday workflows.\n\n**We hope you’ll consider joining us.** We are super excited to connect with all of you! Please feel free to share the invite to anyone who may be interested in learning more.\n\nThis event has taken place – you can [view the recording here](https://www.youtube.com/watch?v=r5axFWHj0SU).\n{: .alert .alert-info .text-center}\n\nPlease [email us](mailto:education@gitlab.com) with any questions.\n\nInterested in hosting your own meetup? Check out our [meetups page](https://about.gitlab.com/community/meetups/).\n\nCover image by [NeONBRAND](https://unsplash.com/photos/1-aA2Fadydc) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[268,9,278],{"slug":2247,"featured":6,"template":698},"gitlab-education-virtual-meetup","content:en-us:blog:gitlab-education-virtual-meetup.yml","Gitlab Education Virtual Meetup","en-us/blog/gitlab-education-virtual-meetup.yml","en-us/blog/gitlab-education-virtual-meetup",{"_path":2253,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2254,"content":2260,"config":2267,"_id":2269,"_type":13,"title":2270,"_source":15,"_file":2271,"_stem":2272,"_extension":18},"/en-us/blog/gitlab-for-agile-portfolio-planning-project-management",{"title":2255,"description":2256,"ogTitle":2255,"ogDescription":2256,"noIndex":6,"ogImage":2257,"ogUrl":2258,"ogSiteName":685,"ogType":686,"canonicalUrls":2258,"schema":2259},"How to use GitLab for Agile portfolio planning and project management","GitLab provides features that are flexible enough to be used for scaled Agile portfolio planning and project management, regardless of the framework you choose.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669575/Blog/Hero%20Images/agilemultipleteams.jpg","https://about.gitlab.com/blog/gitlab-for-agile-portfolio-planning-project-management","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to use GitLab for Agile portfolio planning and project management\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Hernandez\"},{\"@type\":\"Person\",\"name\":\"Julie Byrne\"}],\n \"datePublished\": \"2020-11-11\",\n }",{"title":2255,"description":2256,"authors":2261,"heroImage":2257,"date":2264,"body":2265,"category":1053,"tags":2266},[2262,2263],"Victor Hernandez","Julie Byrne","2020-11-11","\nMany organizations using GitLab want to understand how to best apply the various features to support [Agile project and portfolio management](/solutions/agile-delivery/) processes (PPM) at scale. These organizations use different Agile frameworks. In a previous blog post, we outlined [an approach for using GitLab for Agile software development](/blog/gitlab-for-agile-software-development/). Since the original post, we've continued to enhance functionality for lean/Agile portfolio planning and Agile project management. In this blog post, we’re updating recommendations for using Agile based on these enhancements and we describe how these features can be utilized for a variety of different scaling frameworks.\n\n## Agile software development at scale\n\nFirst, let’s take a look at a typical scaling model of [Agile software development](/topics/agile-delivery/) beyond the individual team level. Whether you’ve adopted a specific scaling framework such as the [Scaled Agile Framework (SAFe)](https://www.scaledagileframework.com/), [Disciplined Agile (DA)](https://www.pmi.org/disciplined-agile), [Large Scale Scrum (LeSS)](https://less.works/), or [Spotify](https://medium.com/scaled-agile-framework/exploring-key-elements-of-spotifys-agile-scaling-model-471d2a23d7ea), most scaling models have similarities in their approach, organizing Agile teams into teams of teams, and even into teams of teams of teams.\n\n![](https://about.gitlab.com/images/blogimages/team-teams2.png){: .medium.center}\n\nTypically, scaling frameworks use these types of labels to describe each level:\n\n| **Level** | **Common Names** | **Description** |\n| ----- | ----- | ----- |\n| Team | Scrum team, Kanban team, Squad | A cross functional group (including BA, Dev, Test, and other supporting roles) implementing stories and bug fixes for an application or set of applications|\n| Team of Teams | Program, Release Train, Tribe | A set of teams who plan together and coordinate efforts to implement features for a system involving one or more applications |\n| Team of Teams of Teams | Portfolio, Business Unit, Alliance | One or more programs with a shared set of strategic goals and themes, typically funded with a single budget |\n\nNow that we've reviewed the different levels of Agile at scale, let’s next think about what types of data and visibility are required for agility at each level.\n\nThe scrum master/project manager/tribe lead, product owner, and team members are part of the Team level that is focused on short-term planning, typically weekly to monthly. They will want:\n\n- A board view to show flow of work\n- Current and upcoming iteration plan\n- A task list for each work item\n- Visibility into team progress\n- Team predictability\n\nThe program manager/release train engineer, product manager/product area lead, and design lead guide the Team of Teams, with a focus is on mid-range planning, monthly to quarterly (or potentially a bit longer). They will want visibility into:\n\n- A prioritized feature list with anticipated business value captured\n- Feature roadmap\n- View of mid-range plan\n- Epic health\n- Progress against plan\n- Program predictability\n\nFinally, portfolio managers, business leaders, and chief architects perform strategic long-term planning, typically quarterly to annually or longer, at the Team of Teams of Teams level. They will want to see:\n\n- A list of long-term epics/initiatives/business projects, categorized by theme and/or strategic goals\n- The long-term strategic roadmap\n\n## How can we best support these needs using GitLab?\n\nFirst, we need to understand what GitLab object types to use for support the appropriate visibility at each level.\n\n| **GitLab Structure** | **Team** | **Team of Teams** | **Team of Teams of Teams** |\n| ----- | ----- | ----- | ----- |\n| Org structure | Project or sub-sub-group | Sub-group | Top level group |\n| Work items | Issue | Child epic | Parent epic |\n| Time boxes | Iteration | Milestone | Roadmap across milestones |\n\nIn GitLab, epics can be defined in a hierarchy to break down long-term epics into a set of shorter-term epics that can each be delivered by a single Team-of-Teams. While we will use a single parent-child epic hierarchy in this blog to keep things simple, you can use more levels of nesting. The lowest level of epic in the hierarchy would be linked to a set of issues to define the work each team will do in order to implement that epic. GitLab is very flexible and does not enforce a hierarchy. For example, when there are cases when an epic should be tracked at the portfolio level but be decomposed directly into issues, with no features in between, GitLab will allow you to do that linking directly without having to create dummy features in the middle.\n\n![](https://about.gitlab.com/images/blogimages/epic_hierarchy2.png){: .medium.center}\n\nWe recommend using [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to define epic types, e.g., you might define long-term epics to be portfolio epics, and decompose them into shorter-term features. Using _epic::portfolio-epic_ and _epic::feature_ will allow you to appropriately categorize and filter a list of epics and make sure that each epic exists in the appropriate location.\n\nA [group](https://docs.gitlab.com/ee/user/group/) can be used to organize projects. And groups can be nested, e.g., a parent group can contain multiple child groups, and each child group can have its own subgroups, etc. A GitLab [project](https://docs.gitlab.com/ee/user/project/) contains a single source code repository, issue tracker, and associated tools and functionality in order to collaborate on software development for that repository.\n\n![](https://about.gitlab.com/images/blogimages/group_project2.png){: .medium.center}\n\nNote: Group permissions are propagated down the tree from the top-level, so, e.g., a maintainer in the top-level group will have maintainer permissions in the entire group hierarchy.\n\nWe recommend that you use a nested group hierarchy to define your scaled organizational structure for Team of Teams of Teams, Team of Teams, and Teams. For example, consider an electronic banking program that is part of the digital services portfolio for a financial services provider. The electronic banking program might have separate teams that work on web, mobile, backend, and middleware. You would use a parent group for the digital services portfolio, a sub-group for the electronic banking program, and a separate project within the sub-group for each team.\n\n![](https://about.gitlab.com/images/blogimages/group_project_example.png){: .medium.center}\n\nGenerally speaking, parent epics would be defined within the top-level group since they define work that can span the sub-groups. Each parent epic would be broken down into multiple child epics, each of which is defined within the appropriate child group (representing a Team-of-Teams).\n\nThe example above is simple in that each Agile team is working on a single repository. But what if that’s not the case?\n\n- If a single team works exclusively on multiple repositories (but no other team works on the them), then create a sub-group for the team, and include each repo as a project.\n- If multiple teams work on a collection of repositories, use the Team of Teams group for collaboration across all Teams in all projects, and use individual scoped labels for each team to track their issues on filtered boards.\n\nGitLab provides an [issue tracker](https://docs.gitlab.com/ee/user/project/issues/) for any types of issues you want to manage and track. Typically, for Agile software development teams, these would be things like user stories and defects. We recommend that you use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to define the different issue types, for ease of filtering and reporting. The great news is that you can have as many or as few issue types as you see fit. GitLab does not provide the ability to define a custom schema for each issue type as that tends to complicate both administration and usage of issues and gets in the way of software development. Instead, use [custom issue templates](https://docs.gitlab.com/ee/user/project/description_templates.html#creating-issue-templates) to provide guidance to the end user on what types of information should be captured for each issue type, and even to set labels automatically on the issue as it is created.\n\nGitLab makes project status reporting easy with the issue [health status](https://docs.gitlab.com/ee/user/project/issues/#health-status). Each issue can have a status of `On Track`, `Needs Attention`, or `At Risk`. The health statuses of all issues for an epic are reported within the epic details for a quick snapshot of the health of the overall epic.\n\nFinally, we have to define timeboxes to use for our planning cadences. We tend to use [milestones](https://docs.gitlab.com/ee/user/project/milestones/) for our mid-range planning, i.e., a quarterly development plan. Define the milestone at the highest group level that will be using that cadence, e.g., if the entire portfolio plans on a quarterly basis, then the planning milestone should be defined at the top-level group level. If each team of teams plans on a different mid-range cadence, then you would want to define separate milestones at each child group level. Note that milestones get added directly to issues, so the projects that will use the milestones must be within the group hierarchy where the milestone is defined. One other consideration is that an issue can only have a single milestone associated with it, so it’s a good idea to align on the best use of milestones across the Team of Teams before starting to use them.\n\nWe recently released our [iterations MVC](https://gitlab.com/groups/gitlab-org/-/epics/4012) in GitLab! This allows you to define, at the group or individual project level, short-term cadences that a team or set of teams uses for planning and tracking their work. While, as an MVC, iteration functionality is not yet as robust as milestones, we do have plans for enhancements including using iterations on boards, filtering issue lists by iteration, and burnup/burndown charts. You can view the epic [Iterations in GitLab](https://gitlab.com/groups/gitlab-org/-/epics/2422) to learn more about planned enhancements. And that doesn’t mean Kanban teams are out of luck. We innately support Kanban in GitLab, too, with issue boards, so you can have a mix of iteration based teams and continuous flow teams working together.\n\n## Agile PPM: putting it all together\n\nHere’s how the GitLab features come together to support Agile at scale to allow planning from the highest level down to the individual team, and to provide visibility, traceability, and reporting at each level:\n\n![](https://about.gitlab.com/images/blogimages/epic_hierarchy.png){: .medium.center}\n\nYou can also check out the video below to see how the structure comes together in GitLab.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/5J0bonGoECs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Read more about Agile at GitLab\n\n- [See more information about our Agile delivery solution](/solutions/agile-delivery/)\n- [Build your Agile roadmap in GitLab](https://docs.gitlab.com/ee/user/group/roadmap/)\n- [Learn how to create iterations](https://docs.gitlab.com/ee/user/group/iterations/)\n\nCover image by [Martin Sanchez](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/MD6E2Sv__iA)\n{: .note}\n",[891,829,912,9],{"slug":2268,"featured":6,"template":698},"gitlab-for-agile-portfolio-planning-project-management","content:en-us:blog:gitlab-for-agile-portfolio-planning-project-management.yml","Gitlab For Agile Portfolio Planning Project Management","en-us/blog/gitlab-for-agile-portfolio-planning-project-management.yml","en-us/blog/gitlab-for-agile-portfolio-planning-project-management",{"_path":2274,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2275,"content":2281,"config":2287,"_id":2289,"_type":13,"title":2290,"_source":15,"_file":2291,"_stem":2292,"_extension":18},"/en-us/blog/gitlab-for-agile-software-development",{"title":2276,"description":2277,"ogTitle":2276,"ogDescription":2277,"noIndex":6,"ogImage":2278,"ogUrl":2279,"ogSiteName":685,"ogType":686,"canonicalUrls":2279,"schema":2280},"How to use GitLab for Agile software development","How Agile artifacts map to GitLab features and how an Agile iteration looks in GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to use GitLab for Agile software development\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n \"datePublished\": \"2018-03-05\",\n }",{"title":2276,"description":2277,"authors":2282,"heroImage":2278,"date":2283,"body":2284,"category":1031,"tags":2285,"updatedDate":2286},[1447,1925],"2018-03-05","Ever wondered if GitLab supports [Agile methodology](https://about.gitlab.com/solutions/agile-delivery/)? If you're considering using GitLab it might not be obvious how the DevSecOps platform's features correspond with Agile artifacts, so we've broken it down for you.\n\nAgile is one of the most important and transformative methodologies introduced to the software engineering discipline in recent decades. While not everyone can agree on the detailed terminology of Agile concepts, it has nonetheless made a significant positive impact on software development teams efficiently creating customer-centric products through [Agile software development](https://about.gitlab.com/topics/agile-delivery/) and delivery processes.\n\nGitLab is designed to be flexible enough to adapt to your software development methodology, whether Agile or influenced by it. In this post, we'll show a simple mapping of Agile artifacts to GitLab features, and explain how customers have successfully run high-performing [Agile software delivery teams](https://about.gitlab.com/solutions/agile-delivery/) with GitLab.\n\n## Mapping Agile artifacts to GitLab features\n\n### Agile artifact → GitLab feature\n\n- User story –> [Issues](https://docs.gitlab.com/ee/user/project/issues/)\n- Task –> [Tasks](https://docs.gitlab.com/ee/user/tasks.html)\n- Epic –> [Epics](https://docs.gitlab.com/ee/user/group/epics/)\n- Points and estimation –> [Issue weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html)\n- Product backlog –> [Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Sprint/iteration –> [Iterations](https://docs.gitlab.com/ee/user/group/iterations/)\n- Agile board –> [Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Team workload –> [Issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Burndown chart –> [Burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## An Agile iteration with GitLab\n\n### User stories → GitLab Issues\n\nIn Agile software development methodology, you often start with a user story that captures a single feature to deliver business value for users. In GitLab, an [issue](https://docs.gitlab.com/ee/user/project/issues/) serves this purpose with ease. GitLab Issues are essential for Agile teams, providing an effective method to manage tasks and projects. Software developers can create, assign, and track issues, ensuring clear accountability and progress visibility. Issues come with robust metadata such as assignee, iteration, weight, and labels, which enhances task prioritization and workflow management throughout the software development process. Additionally, team collaboration on issues is streamlined with discussion threads, attachments, and real-time updates, enabling effective communication and teamwork.\n\n![screenshot of a GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nThe GitLab Issue has a title and a description area in the middle, providing a space to document any details, such as the business value and relevant personas in a user story. The sidebar at the right provides integration with other Agile-compatible features like the epic parent that the issue belongs to, the iteration in which the issue is to be worked on, and the weight of the issue, reflecting the estimated effort.\n\n### Task → Tasks\n\nOften, a user story is further separated into individual tasks. GitLab [Tasks](https://docs.gitlab.com/ee/user/tasks.html) streamline project management by allowing Agile teams to break down user stories into discrete pieces of work. This feature supports the Agile framework by enabling software developers to create, assign, and track tasks within their projects. By integrating task management directly into GitLab, teams can maintain a cohesive workflow, ensuring all software development project activities are easily tracked and managed.\n\n![screenshot showing precise task management and project tracking using GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nEnhance user value by enabling precise task management and project tracking using GitLab. Tasks are equipped with the same metadata as issues, including assignee, iteration, weight, labels, time tracking, and collaboration features. This comprehensive feature set allows Agile teams and project managers to manage workloads effectively, prioritize tasks, and ensure seamless collaboration among software developers.\n\n### Epics → GitLab Epics\nIn the other direction, some Agile practitioners specify an abstraction above user stories, often called an epic, that indicates a larger user flow consisting of multiple features. In GitLab, an [epic](https://docs.gitlab.com/ee/user/group/epics/) also contains a title and description, much like an issue, but it allows you to attach multiple child issues to it to indicate that hierarchy.\n\n![screenshot of nested GitLab Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nGitLab Epics allows Agile teams to organize and manage large projects efficiently by nesting epics up to nine layers deep. This hierarchical structure provides a clear view of the project's roadmap, helping software developers and project managers break down complex initiatives into manageable components. By utilizing child and [linked epics](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html), teams can better track progress, dependencies, and project milestones, enhancing collaboration and ensuring cohesive agile delivery.\n\n### Product backlog → GitLab Issue Boards\n\nThe product or business owners typically create these user stories to reflect the needs of the business and customers. They are prioritized in a product backlog to capture urgency and desired order of development. The product owner communicates with stakeholders to determine the priorities and constantly refines the backlog. In GitLab, an [issue board](https://docs.gitlab.com/ee/user/project/issue_board.html) organized with iterations as lists offers a drag-and-drop workflow experience that allows you to effortlessly prioritize your backlog and assign stories to an upcoming sprint.\n\n![Gif of GitLab Issue Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\n### Sprints → GitLab iterations\n\nA sprint represents a finite time period in which the work is to be completed, which may be a week, a few weeks, or perhaps a month or more. The product owner and the development team meet to decide the work that is in scope for the upcoming sprint. GitLab's [iterations](https://docs.gitlab.com/ee/user/group/iterations/) feature supports this: Assign iterations a start date and a due date to capture the time period of the iteration. The team then puts issues into the sprint by assigning them to that particular iteration.\n\nBy using iterations, you leverage GitLab’s enhanced capabilities for Agile project management, providing better visibility and control over your Agile planning and delivery.\n\n### Points and estimation → GitLab issue weight\n\nAlso in this meeting, user stories are communicated, and the level of technical effort is estimated for each in-scope user story. In GitLab, issues have a [weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) attribute, which you would use to indicate the estimated effort.\n\nIn this meeting (or in subsequent ones), user stories are further broken down to technical deliverables, sometimes documenting technical plans and architecture. In GitLab, this information can be documented in the issue, or in the [merge request description](https://docs.gitlab.com/ee/user/project/merge_requests/), as the merge request is often the place where technical collaboration happens.\n\nDuring the sprint (GitLab iteration), software development team members pick up user stories to work on, one by one. In GitLab, issues have assignees. So you would [assign](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html) yourself to an issue to reflect that you are now working on it. We'd recommend that you [create an empty and linked-to-issue merge request](https://docs.gitlab.com/ee/user/project/issues/) right away to start the technical collaboration process, even before creating a single line of code.\n\n### Agile board → GitLab Issue Boards\n\nThroughout the sprint, issues move through various stages, such as `Ready for dev`, `In dev`, `In QA`, `In review`, `Done`, depending on the workflow in your particular organization. Typically these are columns in an Agile board. In GitLab, [issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html) allow you to define your stages and enable you to move issues through them. The team can [configure the board](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration) with respect to the iteration and other relevant attributes. During daily stand-ups, the team looks at the board together, to see the status of the sprint from a workflow perspective.\n\n![screenshot of GitLab Issue Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\n\nThe GitLab Issue Board also pulls in issues dynamically, similar to the GitLab issue list. But it allows for more flexible workflows. You can set up individual lists in the board, to reflect Agile board stages. Your team can then control and track user stories as they move from for example, `Ready for dev`, all the way to `Released to production`.\n\n### Team workload → GitLab Issue Boards\n\nAgile teams can optimize their workflows by creating issue boards with lists scoped to assignees in GitLab. This feature allows you to visualize the distribution of tasks among team members, enhancing Agile delivery. To set it up, navigate to your project or group, create a new board in the \"Boards\" section, and [add lists](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) for each assignee. Assign issues to team members, and they will automatically appear in the corresponding lists. This dynamic view empowers balanced workloads and effective task management.\n\n![Screenshot of organized GitLab Issue Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097468380.png)\n\nOrganize an issue board by assignee or by squad using [scoped labels]. GitLab’s Issue Board is incredibly diverse and supports workflows across the software development lifecycle.\n\n### Burndown charts → GitLab Burndown Charts\n\nThe development team wants to know if they are on track in real time, and mitigate risks as they arise. GitLab provides [burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), allowing the team to visualize the work scoped in the current sprint \"burning down\" as they are being completed.\n\nToward the end of the sprint, the development team demos completed features to various stakeholders. With GitLab, this process is made simple using [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) so that even code not yet released to production, but in various testing, staging or UAT environments can be demoed. Review Apps and [CI/CD features](https://docs.gitlab.com/ee/ci/) are integrated with the merge request itself.\n\nThese same tools are useful for Developers and QA roles to maintain software quality, whether through automated testing with CI/CD, or manual testing in a Review App environment.\n\n![Screenshot of GitLab Burndown Chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097468381.png)\n\nThe GitLab Burndown Chart allows a team to track scoped work \"burning down,\" as they are being completed in a sprint. This allows you to react to risks sooner and adapt accordingly, for example, informing your business stakeholders that certain features are anticipated to be delayed to a future sprint.\n\nTeam retrospectives at the end of the sprint can be documented in GitLab’s [wiki](https://docs.gitlab.com/ee/user/project/wiki/index.html), so that lessons learned and action items are tracked over time. During the actual retrospective, the team can look at the [iteration report](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report), which displays the burndown chart and other statistics of the completed sprint.\n\n## Start your Agile journey with GitLab\nReady to elevate your Agile project management? GitLab offers a comprehensive suite of features tailored to Agile teams, software developers, and project managers, ensuring seamless collaboration and efficient workflows. Explore our pricing options, start a free trial and discover how GitLab can transform your Agile delivery processes.\n\n> [Learn more about GitLab Agile planning](https://about.gitlab.com/pricing/) and get started on your journey today!\n",[891,829,912,9],"2024-07-09",{"slug":2288,"featured":6,"template":698},"gitlab-for-agile-software-development","content:en-us:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","en-us/blog/gitlab-for-agile-software-development.yml","en-us/blog/gitlab-for-agile-software-development",{"_path":2294,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2295,"content":2301,"config":2307,"_id":2309,"_type":13,"title":2310,"_source":15,"_file":2311,"_stem":2312,"_extension":18},"/en-us/blog/gitlab-for-designers",{"title":2296,"description":2297,"ogTitle":2296,"ogDescription":2297,"noIndex":6,"ogImage":2298,"ogUrl":2299,"ogSiteName":685,"ogType":686,"canonicalUrls":2299,"schema":2300},"Help us shape the future of design discussion in GitLab","We've identified the need for full integration of user experience design within the DevOps lifecycle, and would love your feedback on how to make that happen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680008/Blog/Hero%20Images/design-discussion.jpg","https://about.gitlab.com/blog/gitlab-for-designers","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Help us shape the future of design discussion in GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sarrah Vesselov\"}],\n \"datePublished\": \"2018-11-08\",\n }",{"title":2296,"description":2297,"authors":2302,"heroImage":2298,"date":2304,"body":2305,"category":300,"tags":2306},[2303],"Sarrah Vesselov","2018-11-08","\n\nAt GitLab, we do everything using, well, GitLab. Using our product as part of our workflow allows us to experience, firsthand, the limitations and frustrations that may prevent our users (and us) from being able to get work done quickly and efficiently. In the user experience (UX) department, we've found ourselves struggling with some important aspects of our day-to-day work – this is what we've found, and how we hope to address it:\n\n## Design discussions quickly become hard to follow\n\nDesign discussion happens inside of issues at GitLab. Typically, a designer will post a wireframe, mockup, or prototype within a comment on an issue to elicit feedback from others. The transparency is excellent: product managers, engineers, and designers can all come together to talk over the problem and the possible solutions. Problems creep in when conversations get too lengthy, hard to follow, and involve multiple iterations of a design. How can we make design discussion at GitLab more useful and accessible?\n\n## We need version control for design files\n\nWe use Sketch for our day-to-day design work. The UX department's Sketch files live within a [design repository](https://gitlab.com/gitlab-org/gitlab-design) to ensure that all designers have access to current patterns and solutions. However these files are not version controlled within the repository, so designers keep personal folders for work-in-progress designs. How can we version control our files within GitLab and eliminate the need to keep multiple versions of a particular design?\n\n## A competitive analysis of design platforms and applications\n\nTo start looking for solutions to these problems, we conducted a competitive analysis of the other platforms and applications out there tackling design creation, collaboration, and handoff. We wanted to know: What are other design teams doing to address these problems? Are there existing aspects of GitLab we can leverage to solve these problems? If not, what would an [MVC](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) look like to integrate designers more efficiently into GitLab?\n\n### Summary of findings\n\nToday's average user is tech savvy, with high expectations for interface usability. Products must be useful and easy to use for users with a wide range of backgrounds, experiences, and expectations. As a result, enterprise-level companies have invested heavily in building UX teams to produce beneficial experiences. These UX teams have distinct requirements for the toolsets they use. Design tools must be able to:\n\n* Improve UX consistency\n* Enable research and testing of designs with users\n* Clarify requirements\n* Facilitate collaboration between teams (Engineering, PM, UX)\n* Version control design files\n* Minimize duplication of work with an SSOT\n* Minimize context switching\n\nThe last requirement, minimize context switching, really stood out. Enterprise designers work on a variety of platforms. The market has exploded over the past decade, with a majority of designers moving from using desktop software to cloud-based platforms. Designers want and need a single-platform approach. They must have the ability to design, collaborate, and share their work with the rest of the organization within one platform.\n\nThis single-platform approach presents a unique opportunity for us. GitLab is the first single application built from the ground up for all stages of the DevOps lifecycle for Product, Development, QA, Security, and Operations teams to work concurrently on the same project. A significant missing piece of this lifecycle is UX design.\n\n### Areas of opportunity for GitLab:\n\n* Review and collaboration\n* Interaction design\n* Version control\n* Developer handoff\n* Design system management\n\nThe total market potential is over US $4 billion and growing. With no clear winners in the design tool space, there is a significant opportunity for an application that can successfully engage developers and design teams in the DevOps lifecycle.\n\nYou can view the [complete competitive analysis here](https://docs.google.com/document/d/12o6h6Fm7bAjhW5AK1r-PNhvn0QrQwZncorYNia12e3Q/edit?usp=sharing).\n\n## What's next?\n\nA logical place to start is by improving discussion within issues. Design proposals are available in issue descriptions, shared and discussed in comments, and it's not always clear which is the latest version. While we have the option to mark and [comment on specific image spots in the blob view and merge requests](https://docs.gitlab.com/ee/user/discussions/#image-discussions), the actual design collaboration happens much earlier in the process.\n\nOne idea is to make design artifacts a first-class citizen by linking to design assets in the side navigation of an issue. We could allow for commenting on images and propagate these comments in the sidebar for focused and cohesive discussion.\n\nWe want to know what you think! You can take a look at and comment on the [design artifacts discovery issue here](https://gitlab.com/gitlab-org/gitlab-ce/issues/53587).\n\n[Photo](https://www.pexels.com/photo/notes-clean-whiteboard-board-7067/) by [Startup Stock Photos](https://www.pexels.com/@startup-stock-photos) on Pexels.\n{: .note}\n",[9,934,1099,1096,695],{"slug":2308,"featured":6,"template":698},"gitlab-for-designers","content:en-us:blog:gitlab-for-designers.yml","Gitlab For Designers","en-us/blog/gitlab-for-designers.yml","en-us/blog/gitlab-for-designers",{"_path":2314,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2315,"content":2320,"config":2326,"_id":2328,"_type":13,"title":2329,"_source":15,"_file":2330,"_stem":2331,"_extension":18},"/en-us/blog/gitlab-for-education-student-spotlights",{"title":2316,"description":2317,"ogTitle":2316,"ogDescription":2317,"noIndex":6,"ogImage":1174,"ogUrl":2318,"ogSiteName":685,"ogType":686,"canonicalUrls":2318,"schema":2319},"Apply to be featured as a GitLab Student Spotlight","Feature your work on GitLab.com and get GitLab swag!","https://about.gitlab.com/blog/gitlab-for-education-student-spotlights","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Apply to be featured as a GitLab Student Spotlight\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"}],\n \"datePublished\": \"2020-06-17\",\n }",{"title":2316,"description":2317,"authors":2321,"heroImage":1174,"date":2322,"body":2323,"category":716,"tags":2324},[1136],"2020-06-17","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nCalling all Students, Professors, and participants in the [GitLab Education Program](https://about.gitlab.com/solutions/education/): [Apply to the GitLab Student Spotlights](https://docs.google.com/forms/d/e/1FAIpQLSdHzG0IEDw6VlUQDqWsweNRDIdM2HQpoBH-t2OzK1m0_SMeiQ/viewform?usp=sf_link), have your work featured on GitLab.com, and earn some GitLab Swag!\n\nWe want to know: how are you using GitLab for teaching, learning, or research?\n\n## GitLab for Education\n\nSince 2018, the [GitLab for Education](https://about.gitlab.com/solutions/education/) program has been providing free Gold subscriptions and Ultimate licenses to qualifying institutions for the purpose of teaching and learning. In two years, we’ve already provided licenses to over 800 educational institutions worldwide, with a total of 1.6+ million participants!\n\nAt GitLab, we believe that [Everyone can Contribute](https://about.gitlab.com/community/contribute/) - and we want to learn more about how our education communities around the world are contributing to and using GitLab.\n\n## What are Student Spotlights?\n\nThe Student Spotlights program will highlight amazing projects that students and professors are building and creating using GitLab.\n\nSelected projects will be featured via a video-recorded interview with the students and professors (if available) involved. Interviews and project links will be featured on the GitLab Unfiltered YouTube channel and the GitLab for Education main webpage!\n\nThe aim of Student Spotlights is two-fold. By showcasing the great work of our program participants, we want to inspire others to join and share their GitLab projects. Your stories and your work are the best way to share and spread the word!\n\nWe also want to connect and build relationships with institutions already using GitLab for teaching and learning. Our student spotlight participants will be some of the first engaged in our quickly growing education community!\n\n## Who Qualifies\n\nStudents, professors, researchers, and leaders in education using GitLab for Education licenses are eligible to submit projects to the Student Spotlights program.\n\n### Examples of Projects for Student Spotlights\n\n- Students using GitLab to host a blog or portfolio\n- Hosting a coding project using a GitLab repository\n- Managing a student club or project using GitLab issues\n- And more! We want to see all the creative, challenging, and dynamic ways you’re using GitLab.\n\n## Apply for the Student Spotlights Program\n\n- [Submit the Google Form to apply to be featured as a Student Spotlight](https://docs.google.com/forms/d/e/1FAIpQLSdHzG0IEDw6VlUQDqWsweNRDIdM2HQpoBH-t2OzK1m0_SMeiQ/viewform?usp=sf_link)\n- Project applications will be reviewed by the Developer Relations team within 1 week of receiving your application.\n- If your project is chosen, you will be contacted via email to select a time for your video-recorded interview.\n- Christina Hupy, Program Manager of the GitLab Education program, or Samantha Lee, GitLab Community Advocate, will host a 15 minute recorded video interview with each participant to highlight their projects and share how they use GitLab for Education\n- Recorded interviews will be uploaded to GitLab Unfiltered and projects will be featured on the GitLab.com GitLab for Education page\n\n\nHave questions about GitLab Student Spotlights, or the GitLab for Education program? Email us at education@gitlab.com and let us know. We can't wait to see how you are using GitLab for Education!\n",[268,2325,9,1263],"production",{"slug":2327,"featured":6,"template":698},"gitlab-for-education-student-spotlights","content:en-us:blog:gitlab-for-education-student-spotlights.yml","Gitlab For Education Student Spotlights","en-us/blog/gitlab-for-education-student-spotlights.yml","en-us/blog/gitlab-for-education-student-spotlights",{"_path":2333,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2334,"content":2340,"config":2345,"_id":2347,"_type":13,"title":2348,"_source":15,"_file":2349,"_stem":2350,"_extension":18},"/en-us/blog/gitlab-for-project-management-one",{"title":2335,"description":2336,"ogTitle":2335,"ogDescription":2336,"noIndex":6,"ogImage":2337,"ogUrl":2338,"ogSiteName":685,"ogType":686,"canonicalUrls":2338,"schema":2339},"How our tool fosters collaborative project management","Our marketing team explains how we use GitLab to manage complex projects. Read how GitLab can improve your collaboration on projects.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680908/Blog/Hero%20Images/stickynotes.jpg","https://about.gitlab.com/blog/gitlab-for-project-management-one","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How our tool fosters collaborative project management\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2019-12-06\",\n }",{"title":2335,"description":2336,"authors":2341,"heroImage":2337,"date":2342,"body":2343,"category":1053,"tags":2344},[1325],"2019-12-06","\n\n_While it is true that there are few non-technical roles left in today’s business environment, it is notable that even folks outside of engineering use GitLab technology for collaborative project management. In this first part of our two-part series we outline the problems of siloed communications and how GitLab is structured to solve that for developers and everyone else. In part two, we’ll take a deep dive into how we used GitLab to manage an integrated marketing campaign and how our product marketing team uses GitLab for complex project management._\n\nImagine you’re trying to launch a new, integrated campaign. This campaign has a central message (e.g., \"Everyone can contribute\") and it pulls in representatives from many different teams – like social media, blogs, and field marketing – to create the designs and content that make this campaign a reality. The campaign structure is built and you’re ready to go – but wait – you’re working in a silo where communication between teams is challenging and there are strict rules about how information is conveyed.\n\nMarketing programs manager [Jackie Gragnola](/company/team/#jgragnola) kicked off the “GitLab for Non-Tech & Project Management Use\" breakout session at [GitLab Contribute New Orleans](/events/gitlab-contribute/) with an icebreaker game that mirrors this very conundrum. Breakout group participants were assigned teams as they tried to rebuild a gumdrop structure, but with strict communication guidelines. One person could see the structure, and relay what the structure looks like to three runners, who then described the structure to one builder.\n\nNeedless to say, the inefficiencies mounted quickly.\n\n\"The problem was one person could use their eyes, one person could use their mouth, one person could use their ears,\" said [Joyce Tompsett](/company/team/#Tompsett), analyst relations manager at GitLab and an observer/reporter in this game. \"So, even though everybody had all the component pieces they were only allowed to use one function at a time and then there was no return communication allowed.\"\n\nThe “can’t see the whole picture” problem is a common one in every industry and the solution is to make collaboration painless. [Collaboration is one of our core values at GitLab](https://handbook.gitlab.com/handbook/values/#collaboration) and it is fundamental to how we run our business and how we designed our tool. To understand how GitLab can work outside of software development it’s helpful to understand the underpinnings.\n\n## How GitLab works\n\nDeveloping software is similar in concept to baking a layer cake. You need a really strong foundation to keep your cake upright, and each coating of frosting between the cake layers acts as the glue that holds it all together. The top layer of frosting makes sure that all of your layers stay in one place (and makes sure that the layer cake is looking like a cake).\n\n![layercake](https://about.gitlab.com/images/blogimages/gitlab-for-proj-management/layercakev2.jpg){: .shadow.medium.center}\nA layer cake is a great analogy for how GitLab works as a project management tool.\n{: .note.text-center}\n\n\"The frosting between those layers is like webhooks or APIs; they’re actually the integrations that make the two pieces of software talk to each other,\" explains [JJ Cordz](/company/team/#jjcordz), senior marketing ops manager. \"Each task that's above the next one can get more complex because it's building off the foundation that you've already put into place.\"\n\nThe difference between the typical DevOps layer cake and the GitLab layer cake is that every activity or function fulfilled by a different layer of the cake (i.e., discrete piece of software) happens entirely within GitLab. In the GitLab layer cake, everything from project planning to execution allows teams to collaborate together within a single tool.\n\nOur description of the GitLab layer cake is actually how GitLab is structured today: With groups at the top, followed by epics, and projects that have issues, templates, etc. All of the layers can work together to build a fluid workflow, or they can be used independently.\n\n\"So all of those pieces together can actually standalone or you can put them all together and it makes a really awesome process in a workflow,\" says JJ. \"You can actually have lots of teams working together to get something massive done, but you've broken it down into little pieces.\"\n\n## Project management within GitLab\n\nIf you want to start thinking about getting \"something massive done\" within GitLab consider these basic steps:\n\n* **Create a framework**: Before diving into a new project, a good project manager will first define what the ideal state is and will then build a framework for achieving this ideal state.\n* **Assign directly responsible individuals (DRIs)**: The PM will assign DRIs to different components of the project. Each DRI is responsible for that particular component and is the person that you can follow-up with regarding that component throughout the project.\n* **Templatize repeated tasks**: Keep things efficient with templates.\n* **Set service level agreements (SLAs) at each handoff point**: Think about the due date and work backward to sort out how long different tasks should be taking.\n* **Write rules of engagement and fallback instructions**\n* **Define the feedback process**: Ensure that you have a place for people to ask questions, and make the room to iterate as you go along.\n\nWhat does this look like in the real world? Our marketing team built a project management structure within GitLab that allows multiple teams to collaborate within the [marketing group](https://gitlab.com/gitlab-com/marketing). Each team (e.g., [corporate marketing](https://gitlab.com/gitlab-com/marketing/corporate-marketing)) has their own project, where other groups and projects can live.\n\n[Epics](https://docs.gitlab.com/ee/user/group/epics/) – which represent projects that contain multiple issues – also live at the marketing group level rather than living within smaller team projects. The [epics live at the marketing group level](/handbook/marketing/#issues-milestones-and-epics) because oftentimes multiple marketing teams (e.g., corporate marketing, product marketing, etc.) will be tagged in different issues within a particular epic.\n\n[Efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) is another one of our values at GitLab and the marketing team created templates within different marketing teams for repeat tasks to keep processes more uniform and efficient.\n\nWe also created a unified, global view that allows us to track the progress of various marketing projects. We have four labels: work in progress (wip), plan, review, and scheduled, that are assigned to a marketing issue that indicates the various stages. The labels allow [Todd Barr](/company/team/#tbarr), our chief marketing officer, and anyone else on the marketing team to see a global overview of various issues within marketing as they move from the idea to completion phase.\n\n![unifiedview](https://about.gitlab.com/images/blogimages/gitlab-for-proj-management/labels.png){: .shadow.large.center}\nA global overview of all the activities happening in marketing, separated and labeled according to their current status.\n{: .note.text-center}\n\nThe marketing team uses two-tiers for our epics: the highest level is the ancestor (formerly called \"parent\") epic, and below that is the child epic. There can be multiple issues associated with the child epic, but an issue can only be associated with one epic.\n\n![epic-diagram](https://about.gitlab.com/images/blogimages/gitlab-for-proj-management/parent-child-epics.png){: .shadow.large.center}\nHow the marketing team uses ancestor epics and child epics.\n{: .note.text-center}\n\nNow that you understand the basics of GitLab and project management within GitLab, watch the video on executing sophisticated and integrated marketing programs.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/tbg8KSyIWVg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nAnd don’t miss the second part of this series where we put the spotlight on our internal successes using GitLab for project management.\n\nCover image by [Startaê Team](https://unsplash.com/@startaeteam) on [Unsplash](https://unsplash.com/s/photos/sticky-notes).\n{: .note}\n",[695,912,9],{"slug":2346,"featured":6,"template":698},"gitlab-for-project-management-one","content:en-us:blog:gitlab-for-project-management-one.yml","Gitlab For Project Management One","en-us/blog/gitlab-for-project-management-one.yml","en-us/blog/gitlab-for-project-management-one",{"_path":2352,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2353,"content":2358,"config":2363,"_id":2365,"_type":13,"title":2366,"_source":15,"_file":2367,"_stem":2368,"_extension":18},"/en-us/blog/gitlab-hackathon",{"title":2354,"description":2355,"ogTitle":2354,"ogDescription":2355,"noIndex":6,"ogImage":1462,"ogUrl":2356,"ogSiteName":685,"ogType":686,"canonicalUrls":2356,"schema":2357},"Announcing the GitLab Hackathon","The first Hackathon event for the GitLab community will take place September 27-28.","https://about.gitlab.com/blog/gitlab-hackathon","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Announcing the GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-09-17\",\n }",{"title":2354,"description":2355,"authors":2359,"heroImage":1462,"date":2360,"body":2361,"category":784,"tags":2362},[1281],"2018-09-17","\n\nWhat makes GitLab a great community is that contributions to the GitLab product come from everyone, regardless of whether they are employed by GitLab or not. Concrete evidence of broad community contribution can be seen in the more than 2,500 merged [“community contribution”](https://gitlab.com/groups/gitlab-org/-/merge_requests?label_name%5B%5D=Community+contribution&scope=all&sort=weight&state=merged) MRs. This community contribution not only helps to enhance the GitLab product, but also brings fresh ideas and perspectives.\n\n![Screenshot showing more than 2,500 merged community MRs](https://about.gitlab.com/images/blogimages/2018-09-13-gitlab-hackathon-inline.png){: .shadow.medium.center}\n*\u003Csmall>MRs from community members not employed by GitLab\u003C/small>*\n\n## What's the deal?\n\n In order to build momentum and to provide a forum for community members to get together, I'm excited to announce that we're holding a [GitLab Hackathon on September 27 and 28](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/wikis/Q3%272018-hackathon). This virtual event will kick off at 07:00 UTC on the 27th and the focus will be to work on issues that are [\"Accepting merge requests\"](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=Accepting+merge+requests&sort=weight_asc). As an incentive, anyone who has their MRs merged within a week of Hackathon period will receive a voucher for GitLab swag. We will also have a bigger prize for the person with the most MRs merged.\n\n## What else is going on?\n\nIn addition to hacking, we plan to invite community experts for quick presentations plus Q&A sessions on various topics over the two days. These sessions will also be recorded and available on [GitLab YouTube channel](https://www.youtube.com/gitlab). The Hackathon will be followed by the [Issue Bash](/community/issue-bash/) from September 29-30.\n\n## Where can I find help?\n\nFor communications during the Hackathon, we will use the new [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community). We already have a [gitlabhq room](https://gitter.im/gitlabhq/gitlabhq) that’s been active with support discussions. However, we wanted to create a separate community room where contributors to GitLab can come together to have community-related discussions and to help each other as people have questions while contributing to GitLab. This is open to everyone, so please [join the room](https://gitter.im/gitlabhq/community) if you are not part of it already.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel).\n{: .note}\n",[268,9,787,278],{"slug":2364,"featured":6,"template":698},"gitlab-hackathon","content:en-us:blog:gitlab-hackathon.yml","Gitlab Hackathon","en-us/blog/gitlab-hackathon.yml","en-us/blog/gitlab-hackathon",{"_path":2370,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2371,"content":2376,"config":2383,"_id":2385,"_type":13,"title":2386,"_source":15,"_file":2387,"_stem":2388,"_extension":18},"/en-us/blog/gitlab-helm-package-registry",{"title":2372,"description":2373,"ogTitle":2372,"ogDescription":2373,"noIndex":6,"ogImage":1131,"ogUrl":2374,"ogSiteName":685,"ogType":686,"canonicalUrls":2374,"schema":2375},"Introducing the GitLab Helm Package Registry","Develop and deploy cloud native applications with a built-in Helm registry.","https://about.gitlab.com/blog/gitlab-helm-package-registry","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Introducing the GitLab Helm Package Registry\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"William Chia\"}],\n \"datePublished\": \"2021-07-26\",\n }",{"title":2372,"description":2373,"authors":2377,"heroImage":1131,"date":2379,"body":2380,"category":1203,"tags":2381},[2378],"William Chia","2021-07-26","\n\nCloud native application architectures use containerization, microservices, and Kubernetes to run reliably at cloud-scale. With a built-in container registry and Kubernetes integration, GitLab is the best way to develop and deploy cloud native applications. [GitLab version 14.1](/releases/2021/07/22/gitlab-14-1-released/) also includes a Helm registry, which allows users to publish, install, and share Helm charts and packages from within our single application for the entire DevOps lifecycle.\n\n### What is Helm?\n\nHelm is a package manager for Kubernetes. A Chart is a Helm package that contains the resource definitions required to run an application inside a Kubernetes cluster. Helm allows you to manage complex applications by storing the application definition in a chart that can be versioned, shared, and collaborated on.\n\n### The differences between Helm Registry and Git\n\nWhy not simply store your Helm charts in a Git repository? After all, charts are YAML files that can be stored, versioned, and collaborated on like code.\n\nFor small projects and simple applications, it can be convenient to store the Helm chart in the same Git repository as the application code. However, this method starts to become unruly as the code scales. Applying this model with microservices architecture means you'd have many different charts spread out across many different repositories. Cluster-wide upgrades would certainly be a challenge. And sharing charts with other teams would require you to also grant permission to the code repository.\n\n### Comparing Helm registry and container registry\n\nAnother option for storing Helm charts is to use an OCI registry, like the GitLab Container Registry. However, this feature is new to Helm 3 and requires running Helm in experimental mode. Many organizations, especially those in highly regulated environments, prefer not to expose themselves to the additional risk of an experimental feature.\n\n### A built-in, dedicated Helm registry\n\nA Helm registry offers a centralized repository to store and share charts so large organizations can manage many complex applications in a controlled manner. The main benefits of having a dedicated registry are the security, efficiency, and reliability.\n\nWhen it comes to security, having all of the charts in one central location means they can be [systematically scanned for vulnerabilities](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). This is much more difficult to manage if your charts are stored in multiple locations. Similarly, user account and permission management is much easier to manage from a single location.\n\nA central registry also makes it much easier to distribute charts throughout your organization. Large organizations will often have a center of excellence that is responsible for creating, maintaining, and distributing charts to many different teams throughout the organization. Enabling a safe way to share charts and control access is critical.\n\nGitLab users can host all Helm charts from one central project, allowing users to control user access with SSO/SAML and authorization with deploy tokens, job tokens, or personal access tokens. Not to mention, the GitLab.com Package stage is 99.95% available.\n\n### How to get started\n\nThe new Helm Registry is currently at \"viable\" maturity. We do not recommended using it for production but it can be used for testing and planning. Visit the [Helm Repository docs](https://docs.gitlab.com/ee/user/packages/helm_repository/) for step-by-step commands to authenticate the registry and publish and install packages.\n\n### Contribute to the Helm Registry\n\nThe first iteration of the Helm registry was contributed to GitLab by community member [Mathieu Parent](https://gitlab.com/sathieu). We'd love your input and feedback and we continue to improve and mature the Helm registry capabilities. This [GitLab Epic outlines the path to make the Helm chart registry complete](https://gitlab.com/groups/gitlab-org/-/epics/6366). Comment in the epic and associated issues with your thoughts and feedback. As always, [code contributions](/community/contribute/development/) are welcome.\n",[9,695,829,2382],"kubernetes",{"slug":2384,"featured":6,"template":698},"gitlab-helm-package-registry","content:en-us:blog:gitlab-helm-package-registry.yml","Gitlab Helm Package Registry","en-us/blog/gitlab-helm-package-registry.yml","en-us/blog/gitlab-helm-package-registry",{"_path":2390,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2391,"content":2396,"config":2403,"_id":2405,"_type":13,"title":2406,"_source":15,"_file":2407,"_stem":2408,"_extension":18},"/en-us/blog/gitlab-incident-management",{"title":2392,"description":2393,"ogTitle":2392,"ogDescription":2393,"noIndex":6,"ogImage":1131,"ogUrl":2394,"ogSiteName":685,"ogType":686,"canonicalUrls":2394,"schema":2395},"Downtime happens, but GitLab Incident Management can help","GitLab's DevOps Platform doesn't just make it easy to release safe software faster, it also streamlines the process for problem solving. Here's a deep dive into GitLab Incident Management.","https://about.gitlab.com/blog/gitlab-incident-management","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Downtime happens, but GitLab Incident Management can help\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n \"datePublished\": \"2021-11-30\",\n }",{"title":2392,"description":2393,"authors":2397,"heroImage":1131,"date":2399,"body":2400,"category":757,"tags":2401},[2398],"Itzik Gan Baruch","2021-11-30","\n\nDowntime is expensive and the cost is growing. Software reliability is as important as the product itself – it doesn't matter what your product can do if your customers can't reliably access it. GitLab's Incident Management is built-in to our [DevOps Platform](/solutions/devops-platform/) and empowers teams with adaptable practices and a streamlined workflow for triage and resolving incidents. We offer tools that provide access to observability resources, such as metrics, logs, errors, runbooks, and traces, that foster easy collaboration across response teams, and that support continuous improvement via post-incident reviews and system recommendations. Here's a look at how it all works.\n\n## The costs of being down\n\nDowntime can cost companies hundreds of thousands of dollars in a single hour. Avoiding downtime is critical for organizations. Companies need to invest time, establish processes and culture around managing outages, and have processes to resolve them quickly. The larger an organization becomes, the more distributed their systems. This distribution leads to longer response times and more money lost. Investing in the right tools and fostering a culture of autonomy, feedback, quality, and automation leads to more time spent innovating and building software. If done well, teams will spend less time reacting to outages and racing to restore services. The tools your [DevOps](/topics/devops/) teams use to respond during incidents also have a huge effect on MTTR (Mean Time To Resolve, also known as Mean Time To Repair). \n\n## What is an incident? \n\nIncidents are anomalous conditions that result in — or may lead to — service degradation or outages. Those outages can impact employee productivity, and decrease customer satisfaction and trust. These events require human intervention to avert disruptions or restore service to operational status. Incidents are always given attention and resolved.\n\n## What is Incident Management? \n\nIncident Management is a process which is focused on restoring services as quickly as possible and proactively addressing early vulnerabilities and warnings, all while keeping employees productive and customers happy. \n\n## Meet GitLab Incident Management \n\n[GitLab Incident Management](https://docs.gitlab.com/ee/operations/incident_management/) aims to decrease the overhead of managing incidents so response teams can spend more time actually resolving problems. We accelerate problem resolution through efficient knowledge sharing in the same tool they already use to collaborate on development. Enabling teams to quickly gather resources in one central, aggregated view gives the team a single source of truth and shortens the MTTR. \n\nGitLab’s built-in Incident management solution provides tools for the triage, response, and remediation of incidents. It enables developers to easily triage and view the alerts and incidents generated by their application. By surfacing alerts and incidents _where the code is being developed_, problems can be resolved more efficiently. \n\n## Why Incident Management within GitLab?\n\nGitLab is a [DevOps Platform](/solutions/devops-platform/), delivered as a single application. As such, we believe there are additional benefits for DevOps users to manage incidents within GitLab.\n\n1. Co-location of code, CI/CD, monitoring tools, and incidents reduces context switching and enables GitLab to correlate what would be disparate events or processes within one single control pane.\n\n2. The same interface for development collaboration and incident response streamlines the process. The developers who are on-call can use the same interface they already use every day; this prevents the incident responders from having to use a tool they are unfamiliar with and thus hampering their ability to respond to the incident.\n\n## How to manage incidents in the GitLab DevOps Platform\n\n### Create an incident manually or automatically \n\nYou can create incidents manually or enable GitLab to create incidents automatically whenever an alert is triggered. If you use PagerDuty for incidents, you can [set up a webhook with PagerDuty](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#create-incidents-via-the-pagerduty-webhook) to automatically create a GitLab incident for each PagerDuty incident. \n\n![pd](https://about.gitlab.com/images/blogimages/incident-mgmt/pager.png)\n\n### Alert Management \n\n[Alerts](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) are a critical entity in incident management workflow. They represent a notable event that might indicate a service outage or disruption. GitLab can accept alerts from any source via a webhook receiver. GitLab provides a list view for triage and detail view for deeper investigation of what happened.\n\n![alert](https://about.gitlab.com/images/blogimages/incident-mgmt/alert.png)\n\n### On-Call Schedules\n\nTo maintain the availability of your software services you need to schedule on-call teams. [On-call schedule management](https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html) is being used to create schedules for responders to rotate on-call responsibilities. Within each schedule you can add team members to rotations that last hours, weeks or days depending on your team's needs. Some teams need to be on-call just during business hours, while others have someone on-call 24/7, 365; every team is different. \n\n![on-call](https://about.gitlab.com/images/blogimages/incident-mgmt/on-call.png)\n\n### Escalation Policies\n\n[Escalation Policies](https://docs.gitlab.com/ee/operations/incident_management/escalation_policies.html) determine when users on-call get notified and what happens if they don’t respond. They are the if/then logic that use on-call schedules to make sure teams never miss an incident. You can create an escalation policy in the GitLab project where you manage on-call schedules.\n\n![escalation](https://about.gitlab.com/images/blogimages/incident-mgmt/escalation.png) \n\n### Paging and Notifications \n\nWhen there is a new alert or incident, it is important for a responder to be notified immediately so they can triage and respond to the problem. GitLab Incident Management supports email notifications, with plans to add Slack notifications, SMS, and phone calls. \n\n\n\n\n\n\n",[695,9,2402],"performance",{"slug":2404,"featured":6,"template":698},"gitlab-incident-management","content:en-us:blog:gitlab-incident-management.yml","Gitlab Incident Management","en-us/blog/gitlab-incident-management.yml","en-us/blog/gitlab-incident-management",{"_path":2410,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2411,"content":2416,"config":2422,"_id":2424,"_type":13,"title":2425,"_source":15,"_file":2426,"_stem":2427,"_extension":18},"/en-us/blog/gitlab-incident-timelines",{"title":2412,"description":2413,"ogTitle":2412,"ogDescription":2413,"noIndex":6,"ogImage":1131,"ogUrl":2414,"ogSiteName":685,"ogType":686,"canonicalUrls":2414,"schema":2415},"How to leverage GitLab incident timelines","What actually happened before, during, and after the incident? Now it's easier to keep track.","https://about.gitlab.com/blog/gitlab-incident-timelines","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to leverage GitLab incident timelines\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n \"datePublished\": \"2022-10-18\",\n }",{"title":2412,"description":2413,"authors":2417,"heroImage":1131,"date":2419,"body":2420,"category":757,"tags":2421},[2418],"Alana Bellucci","2022-10-18","\n\n_When you're working on an incident, every second counts._ Team members and leadership are looking for updates. Any interruption can make you lose track of where you were. Finding the root cause or working on a code change to resolve the incident requires time and focus. After the incident is resolved, you'll need to provide a summary of what happened during the post-incident review. How can you provide updates and keep track of important events while working on the incident?\n\n## Incident timelines with GitLab\n\nGitLab recently launched [incident timelines](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html). Incident timelines are the single source of truth (SSoT) for key updates and events that happen during an incident. They typically include things like when the incident was declared, who is actively working on the incident, and other important events during the incident; i.e. \"Disabling Canary to test a hot fix.\"\n\nUpdating the timeline needs to be done quickly and efficiently. Use GitLab quick actions to add multiple timeline items programmatically.\n\n![quick_action](https://about.gitlab.com/images/blogimages/incident-mgmt/incident_timeline_quick_actions.png)\n\nOr [add any comment from the incident to the timeline](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html#from-a-comment-on-the-incident) by clicking on the clock icon. This helps avoid the unnecessary shoulder taping for updates so users can focus on firefighting. \n\nWhen you're at the end of your on-call shift, you can share the timeline as you hand off the incident to summarize what's happened so far. If you've missed adding something important to the timeline, you can always add the event retroactively and post-date it to the correct time. When you wake up for your next shift, you can review what happened while you were away.\n\n## Keeping a record with incident timelines\n\nOnce an incident has been resolved, it can be hard to piece together what actually happened. Sometimes, post-incident reviews don't happen until days after you've worked on the incident. _Did the incident originate from an alert or was it from a customer email?_ _Did we meet our Service Level Agreement (SLA)?_ Since you've kept track along the way, incident timelines can be a quick way to refresh your memory on what happened during the incident. \n\nEstablishing incident timelines as a SSoT minimizes the time spent on incident \"paperwork.\" This gives you time to focus on resolving the incident. Once the incident resolves you can review with team members to minimize the chance of the same incident occurring again.\n\nThe [GitLab Infrastructure Team](/handbook/engineering/infrastructure/#dogfooding) has been testing [dogfooding](https://www.urbandictionary.com/define.php?term=Dog%20fooding) and using incident timelines. We'd love to hear about how you are constructing and recording what happens during an incident. You can also take a look at [Improving the Incident Timeline](https://gitlab.com/groups/gitlab-org/-/epics/8256) and help influence what we build next.\n",[1388,9,829],{"slug":2423,"featured":6,"template":698},"gitlab-incident-timelines","content:en-us:blog:gitlab-incident-timelines.yml","Gitlab Incident Timelines","en-us/blog/gitlab-incident-timelines.yml","en-us/blog/gitlab-incident-timelines",{"_path":2429,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2430,"content":2435,"config":2440,"_id":2442,"_type":13,"title":2443,"_source":15,"_file":2444,"_stem":2445,"_extension":18},"/en-us/blog/gitlab-mental-health-awareness-week-recap",{"title":2431,"description":2432,"ogTitle":2431,"ogDescription":2432,"noIndex":6,"ogImage":1174,"ogUrl":2433,"ogSiteName":685,"ogType":686,"canonicalUrls":2433,"schema":2434},"GitLab Mental Health Awareness Week Recap","A recap of the Learning and Development Mental Health Awareness week","https://about.gitlab.com/blog/gitlab-mental-health-awareness-week-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Mental Health Awareness Week Recap\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Samantha Lee\"}],\n \"datePublished\": \"2020-12-21\",\n }",{"title":2431,"description":2432,"authors":2436,"heroImage":1174,"date":2437,"body":2438,"category":716,"tags":2439},[1693],"2020-12-21","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nAs an [all-remote](https://about.gitlab.com/company/culture/all-remote/guide/#why-remote) company, the GitLab team is distributed across the globe. Our team is used to working online, scheduling Zoom social hours, and using asynchronous communication strategies.\n\nEven with all these work from home skills in our back pockets, 2020 has been a challenge. Over the year, we've adapted to new work environments, taken on new roles within our families and communities, and found new and creative ways to connect from a distance. It's been chaotic and it has taken a toll on our mental health.\n\nOver the last few months, the [Learning and Development (L&D) team at GitLab](https://about.gitlab.com/handbook/people-group/learning-and-development/\n) heard team members express feelings of burnout. Personally, in [coffee chats](https://about.gitlab.com/company/culture/all-remote/informal-communication/#coffee-chats) and slack conversations, I heard team members speak of feeling exhausted and overwhelmed. The combination of maintaining a regular work schedule, caring for family, and finding time to relax and recharge, all while living through a global pandemic, is taking its toll.\n\nI could relate. I was feeling this overwhelm, too.\n\nIn response to these conversations, the L&D team launched an asynchronous [internal learning campaign](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#internal-learning-campaigns) for the GitLab team with the goal of increasing awareness of, and access to, existing [mental health](https://about.gitlab.com/company/culture/all-remote/mental-health/\n) resources at GitLab. This was a new [learning initiative](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#learning-initiatives-introduction) for the team, leveraging GitLab issues, Slack reminders, polls, and a [learning speaker series](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#learning-speaker-series-overview) to engage and educate team members.\n\nTake a few minutes to read the rest of this post to learn about the intentions behind the initiative, major takeaways, and what we're doing moving forward to continue the conversation.\n\n## Why participate asynchronously?\n\n[Asynchronous communication](https://about.gitlab.com/company/culture/all-remote/asynchronous/) gives team members the opportunity to work [efficiently](https://handbook.gitlab.com/handbook/values/#efficiency), [collaborate](https://handbook.gitlab.com/handbook/values/#collaboration), and put [friends and family first](https://handbook.gitlab.com/handbook/values/#family-and-friends-first-work-second). \n\nWhen it comes to engaging learning content, applying asynchronous strategies can be challenging. Many learners are used to learning in collaborative, co-located groups or calls. The GitLab L&D team is always exploring and experimenting with new ways to make asynchronous learning just as engaging as synchronous learning. With this campaign, we used [GitLab issues](https://gitlab.com/gitlab-com/people-group/learning-development/challenges/-/boards), Slack, the [Polly app](https://www.polly.ai/), and Zoom to deliver information and host discussion.\n\nThis awareness campaign needed to be designed with as many asynchronous elements as possible to\n\n1. Make content accessible and consumable for all team members, regardless of their time zone or location\n1. Avoid creating additional overwhelm for participants related to attending synchronous calls, and instead let team members review content on their own time\n1. Document content for future self-paced learning paths\n\nIn addition to making this awareness campaign asynchronous, all participation was optional. Discussing mental health and [burnout](https://about.gitlab.com/blog/preventing-burnout/) can be challenging and uncomfortable. We wanted to allow space to discuss burnout only when team members felt comfortable and ready.\n\n\n## So, how'd it go!\n\nA few great wins from the week:\n\nFirst, we collaboratively stood up our [mental health tool stack](https://about.gitlab.com/company/culture/all-remote/mental-health/#mental-health-tool-stack) as part of our [day 2 issue](https://gitlab.com/gitlab-com/people-group/learning-development/challenges/-/issues/35). Team members were asked to open an MR and contribute tools they use to manage burnout. Together we collected 12 resources. If you have one to add, please [contribute!](https://about.gitlab.com/community/contribute/)\n\nSecond, we created, tested, and documented a new learning initiative, [internal learning campaigns!](https://about.gitlab.com/handbook/people-group/learning-and-development/learning-initiatives/#internal-learning-campaigns). The L&D team is exploring new ways to deliver bite-sized learning, and this is one we will try again in the future.\n\nAnd finally, we hosted a fantastic [live speaker series with John Fitch](https://www.youtube.com/watch?v=BDvpoouM-us&feature=emb_logo), author of the book [Time Off](https://www.timeoffbook.com/). Team members asked questions about how to take meaningful time off, how to return from PTO, and how managers can encourage team members to take time off. Approximately 100 team members attended synchronously, and many watched the recorded replay.\n\nA little more about John - he's the co-author of the international bestseller [Time Off: A Practical Guide to Building Your Rest Ethic and Finding Success Without the Stress](https://www.timeoffbook.com/), a book that expands our value of time off, and how our rest and leisure are as important as our work. John is a recovering workaholic who wrote this book for a former version of himself. He cares deeply about the future of work and is optimistic that everyone has the opportunity to join the creative class in the near future. John is now building tools for helping people and teams design their rest ethic and manage their time off more effectively. He would love to hear from you if you are passionate about intentional time off.\n\nWatch the replay of our live speaker series below!\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/BDvpoouM-us\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\n## What didn't go so well?\n\nOne of the goals for the week was to increase the number of team members who answered 'Yes' to the following question: 'I know where and how to access resources to manage my mental health at GitLab'. Based on the Polly polls we shared in our #what's-happening-at-GitLab Slack channel, we saw a 3% increase in the number of team members who answered 'Yes', increasing from 73% to 76%\n\nHere are some screenshots of the poll data:\n\nOur initial poll data, collecting information _before_ the awareness week:\n\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/pre-poll-results.jpg){: .shadow}\n\n\nAnd our final poll data, collecting information _after_ the awareness week:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/post-poll-results.jpg){: .shadow}\n\n\nWhile this shows a slight increase, it's not enough, and the L&D team recognizes we need to do more as a company to communicate this information more widely and empower team members to use the available resources. A few issues we noticed with this data collection:\n\n1. We aren't sure if the people who took the first poll also took the second poll since the poll is anonymous\n1. We also aren't sure if the people who took either poll particiapted in any or all of the awareness week content. Since participation was completion optional, we didn't track who decided to get involved\n1. Fewer people responded to the final poll than the initial poll\n\n\n## Now what?\n\nThe role of Learning & Development at GitLab has evolved during Covid-19 to include more support for mental health and wellbeing of our team members. Looking after team members wellness is no longer a passing priority. The increasing pace of monumental change and stress indicates otherwise. The pandemic is a marathon, not a sprint, and our role as learning leaders is equipping our team members with a set of tools to build resilience, manage through change, and take care of their mental health.\n\nThis internal awareness campaign was just the start of a series of learning opportunities the L&D team is creating for team members to explore their mental health and learn strategies for managing burnout. We're working on [new mental health and burnout management inititiaves](https://gitlab.com/groups/gitlab-com/people-group/learning-development/-/epics/24) for 2021 to continue this conversation beyond this awareness campaign.\n\nWe're also working on creating a self-paced learning path through this awareness campaign content, so that team members who missed the content, future team members, and our wider community can review the material. Follow the updates from our new GitLab Learn platform to find out when this learning path will be available.\n\nIn the meantime, we encourage you to check out the content from the week shared via GitLab issues!\n\n\n| Issue Link | Content |\n|",[9,934,1097],{"slug":2441,"featured":6,"template":698},"gitlab-mental-health-awareness-week-recap","content:en-us:blog:gitlab-mental-health-awareness-week-recap.yml","Gitlab Mental Health Awareness Week Recap","en-us/blog/gitlab-mental-health-awareness-week-recap.yml","en-us/blog/gitlab-mental-health-awareness-week-recap",{"_path":2447,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2448,"content":2454,"config":2460,"_id":2462,"_type":13,"title":2463,"_source":15,"_file":2464,"_stem":2465,"_extension":18},"/en-us/blog/gitlab-partner-of-year-emea-apac-award-winners",{"title":2449,"description":2450,"ogTitle":2449,"ogDescription":2450,"noIndex":6,"ogImage":2451,"ogUrl":2452,"ogSiteName":685,"ogType":686,"canonicalUrls":2452,"schema":2453},"Meet the 2023 GitLab Partner of the Year award winners for EMEA and APAC","We recognized our channel, technology, and cloud partners in EMEA and APAC for their collaboration and contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679312/Blog/Hero%20Images/awardstars.jpg","https://about.gitlab.com/blog/gitlab-partner-of-year-emea-apac-award-winners","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Meet the 2023 GitLab Partner of the Year award winners for EMEA and APAC\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Patty Cheung\"}],\n \"datePublished\": \"2023-10-02\",\n }",{"title":2449,"description":2450,"authors":2455,"heroImage":2451,"date":2457,"body":2458,"category":1203,"tags":2459},[2456],"Patty Cheung","2023-10-02","\nAt GitLab’s second annual EMEA Partner Leadership Summit, held in London last month, we invited channel, technology, and cloud partners to join us to celebrate their achievements, empower their success, and provide resources and support for the year to come. \n\nWe recognized our partners for their contributions via the Partner Leadership Awards, including EMEA and APAC Partner of the Year, EMEA Distributor of the Year, and EMEA Services Partner of the Year. \n\nGitLab strives to create collaborative and mutually beneficial relationships with our partners, and we also encourage our partners to embrace GitLab’s values of Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency ([CREDIT](https://handbook.gitlab.com/handbook/values/)). Each award winner demonstrated a strong partnership with GitLab and alignment with CREDIT values.\n\nOur 2023 Partner Leadership Summit Award winners for EMEA and APAC are:\n\n## EMEA Partner of the Year: SVA System Vertrieb Alexander GmbH\n_SVA is one of Germany’s leading IT services providers. With products from leading manufacturers, their project know-how and range of services, and flexibility, they develop optimal solutions for companies and public-sector clients._\n\nSVA's approach to customer engagement is a testament to their dedication to helping businesses tackle their distinctive challenges through the transformative power of DevSecOps. They have also invested in GitLab to **efficiently** manage their own workloads thus creating a strong GitLab culture and proficient technical teams. SVA works to ensure that customers not only embrace DevSecOps but also reap the full benefits, ensuring a substantial return on investment. \n\n## APAC Partner of the Year: Infograb LC\n_Infograb is a DevOps Tech company with Agile-based software development and DevOps framework technology know-how in various institutions, mainly the financial sector._\n\nInfograb was one of our first partners in Korea, and they immediately saw the value and opportunity to not only sell GitLab but provide great value for their customers through a strong services practice. Infograb has continued to grow their GitLab practice year after year, becoming a stand-out partner for us in the region. Infograb has been instrumental in helping win some of the largest enterprise customers in Korea supported by an outstanding solution engineering team who always delivers amazing **results** for their customers.\n\n## EMEA Distributor of the Year: Amazic\n_Amazic is a trusted supplier and solution advisor for partners, individuals, and many of the world’s largest organizations across different industry verticals by offering a unique platform for purchasing technology products and services and accessing training courses._\n\nAmazic earned Distributor of the Year as a result of their continued focus on developing a DevSecOps Ecosystem with GitLab throughout EMEA. They manage a dedicated open partner base, ensuring technical enablement and training around GitLab to support customer development. Their marketing department is continually **iterating** innovative campaigns highlighting business opportunities to help customers develop their own DevSecOps journey. The Amazic marketplace simplifies and consolidates customers’ product purchasing, saving time and money. \n\n## EMEA Services Partner of the Year: Adfinis\n_Adfinis is a leading service provider of Open Source solutions for over 20 years and is based in Switzerland, Germany, the Netherlands, and Australia. As a company, Adfinis contributes to sustainable and reliable IT solutions by being intensely involved in the Open Source community._\n\nAdfinis joined forces to partner with GitLab back in 2020 sharing a similar vision of working with open source solutions. Since then they have been true to their word, investing in their professional services capabilities and becoming a team of highly proficient DevSecOps engineers operating across EMEA. They always keep abreast of GitLab product releases, often being the first to prove these innovations in the field, we recognize them as a true **collaborator** to GitLab as they are to their customers. \n\nOur heartfelt congratulations to all the winners! We look forward to further collaboration in the year to come. \n\nLearn more about [GitLab’s Partner Program](https://partners.gitlab.com/English/).\n",[283,1203,9],{"slug":2461,"featured":6,"template":698},"gitlab-partner-of-year-emea-apac-award-winners","content:en-us:blog:gitlab-partner-of-year-emea-apac-award-winners.yml","Gitlab Partner Of Year Emea Apac Award Winners","en-us/blog/gitlab-partner-of-year-emea-apac-award-winners.yml","en-us/blog/gitlab-partner-of-year-emea-apac-award-winners",{"_path":2467,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2468,"content":2474,"config":2481,"_id":2483,"_type":13,"title":2484,"_source":15,"_file":2485,"_stem":2486,"_extension":18},"/en-us/blog/gitlab-release-date-change",{"title":2469,"description":2470,"ogTitle":2469,"ogDescription":2470,"noIndex":6,"ogImage":2471,"ogUrl":2472,"ogSiteName":685,"ogType":686,"canonicalUrls":2472,"schema":2473},"GitLab releases moving to the third Thursday of the month","This move will create more predictability for our customers in terms of the day of week for the release while continuing our monthly pace of self-managed releases.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/gitlab-release-date-change","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab releases moving to the third Thursday of the month\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ian Pedowitz\"}],\n \"datePublished\": \"2023-09-18\",\n }",{"title":2469,"description":2470,"authors":2475,"heroImage":2471,"date":2477,"body":2478,"category":1203,"tags":2479},[2476],"Ian Pedowitz","2023-09-18","\n\nStarting with GitLab 16.6, which will be released on Nov. 16, 2023, **our monthly release date will change from the 22nd of every month to the third Thursday of every month**. This iteration in our release processes will ensure consistency and create more predictability for our customers in terms of the day of the week for the release while continuing our monthly pace of self-managed releases.\n\n## What does this change mean for you?\nIf you’re using GitLab.com SaaS, not much will change as GitLab.com SaaS will continue to deploy multiple times a day.\n\nIf you’re using GitLab self-managed, releases will happen on the third Thursday of every month. If you have any processes, tooling, or automation that is based around the GitLab self-managed release being the 22nd of the month, it will need to be updated to support this new schedule of the third Thursday of the month.\n\nA new rolling 12-month schedule has been added to the [releases page](https://about.gitlab.com/releases/) with more details about these changes, and can be added to your bookmarks. A machine-readable version is also available at [`data/releases.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/releases.yml).\n",[1203,9,1388,2480],"releases",{"slug":2482,"featured":6,"template":698},"gitlab-release-date-change","content:en-us:blog:gitlab-release-date-change.yml","Gitlab Release Date Change","en-us/blog/gitlab-release-date-change.yml","en-us/blog/gitlab-release-date-change",{"_path":2488,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2489,"content":2495,"config":2502,"_id":2504,"_type":13,"title":2505,"_source":15,"_file":2506,"_stem":2507,"_extension":18},"/en-us/blog/gitlab-suggested-reviewers",{"title":2490,"description":2491,"ogTitle":2490,"ogDescription":2491,"noIndex":6,"ogImage":2492,"ogUrl":2493,"ogSiteName":685,"ogType":686,"canonicalUrls":2493,"schema":2494},"Unblock code reviews with GitLab Suggested Reviewers","Identify the right reviewers more quickly, saving time and accelerating the software development lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666316/Blog/Hero%20Images/codereview2.png","https://about.gitlab.com/blog/gitlab-suggested-reviewers","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Unblock code reviews with GitLab Suggested Reviewers\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n \"datePublished\": \"2023-09-21\",\n }",{"title":2490,"description":2491,"authors":2496,"heroImage":2492,"date":2497,"body":2498,"category":2499,"tags":2500},[2398],"2023-09-21","\nIn the world of software development, speed is of the essence. The faster you can merge your code, the quicker you can iterate, innovate, and deliver value to your users. However, there's a roadblock that often hinders this need for speed – the arduous process of finding the right reviewer for your merge request (MR).\n\nImagine this: You've just finished a brilliant piece of code that's ready to be integrated into your project. You're excited to see it in action, and so are your teammates. But before your masterpiece can join the project, it must go through the crucial stage of code review. Here's where the challenge begins.\n\nIn many development teams, finding the ideal reviewer can be a time-consuming task. You might need someone with expertise in a particular area, someone who's available at the moment, and someone who can provide insightful feedback promptly. The longer it takes to locate the right reviewer, the more your code languishes in review limbo, delaying the entire development cycle.\n\nAnd let's not forget the frustration of starting a review with the wrong person, only to realize that their insights aren't quite what you needed. Backtracking to find another reviewer can be a difficult process, compounding the delays and creating unnecessary bottlenecks.\n\nThis challenge becomes even more pronounced as software projects grow in size and complexity, especially when multiple teams are involved. Coordinating reviews across team boundaries can be a logistical nightmare. \n\nWhat's worse is that these delays often set off a chain reaction, leading to even more delays down the line, as other tasks and dependencies pile up, affecting not just the current MR but the entire project's timeline.\n\n![development graphic](https://about.gitlab.com/images/blogimages/2023-09-22-suggested-reviewers/code-review.png)\n\nIn this blog post, we'll introduce you to [GitLab Suggested Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers). Suggested Reviewers is designed to streamline your MR workflow by ensuring that you connect with the right reviewers quickly and efficiently. Say goodbye to wasted time and welcome to a faster, more agile development cycle.\n\n## What is Suggested Reviewers?\nSuggested Reviewers leverages a machine learning algorithm that analyzes the changes in an MR and a project’s contribution graph to suggest reviewers with contextual knowledge. It generates a list of up to five suggested reviewers. The list is presented in the Reviewers dropdown in the merge request sidebar, empowering the author to immediately select available reviewers. These suggestions are contextual to the changes in the MR. Additional commits to MRs may change the reviewer suggestions, which are automatically updated in the reviewer dropdown list.\n\nIt also will display if a suggestion is a code owner or if they can merge the changes,helping drive towards action.\n\n![suggested reviewers](https://about.gitlab.com/images/blogimages/2023-09-22-suggested-reviewers/suggested-reviewers.png) \n\n## Key benefits of Suggested Reviewers\nHere are the key benefits of Suggested Reviewers.\n- **Time savings.** Suggested Reviewers eliminates the need for guesswork or manual reviewer selection. The feature automates the process, saving time for developers.\n- **Enhanced collaboration.** By connecting you with the right reviewers, Suggested Reviewers promotes collaboration and encourages knowledge sharing among team members.\n- **Improved code quality.** Suggested Reviewers enables developers to have the most qualified individuals review their code, resulting in better quality and more reliable software.\n- **Reduced bottlenecks.** Suggested Reviewers speeds up the review process and reduces bottlenecks by quickly identifying available and willing reviewers.\n- **Personalized suggestions.** Suggested Reviewers considers individual expertise and past interactions, providing tailored recommendations.\n\n## How to get started with Suggested Reviewers\n\nIn this blog post, we've explored how Suggested Reviewers transforms the development lifecycle. It's not just about faster code reviews; it's about faster, more efficient, and more collaborative software development from start to finish. \n\n> Learn more in our [Suggested Reviewers documentation](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers).\n","ai-ml",[1264,9,2501],"AI/ML",{"slug":2503,"featured":6,"template":698},"gitlab-suggested-reviewers","content:en-us:blog:gitlab-suggested-reviewers.yml","Gitlab Suggested Reviewers","en-us/blog/gitlab-suggested-reviewers.yml","en-us/blog/gitlab-suggested-reviewers",{"_path":2509,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2510,"content":2515,"config":2520,"_id":2522,"_type":13,"title":2523,"_source":15,"_file":2524,"_stem":2525,"_extension":18},"/en-us/blog/gl-for-pm-prt-2",{"title":2511,"description":2512,"ogTitle":2511,"ogDescription":2512,"noIndex":6,"ogImage":2337,"ogUrl":2513,"ogSiteName":685,"ogType":686,"canonicalUrls":2513,"schema":2514},"2 Examples of how marketing uses GitLab to manage complex projects","How GitLab technology powers integrated marketing campaigns and product marketing projects.","https://about.gitlab.com/blog/gl-for-pm-prt-2","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"2 Examples of how marketing uses GitLab to manage complex projects\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2019-12-11\",\n }",{"title":2511,"description":2512,"authors":2516,"heroImage":2337,"date":2517,"body":2518,"category":1053,"tags":2519},[1325],"2019-12-11","\n\n_In [part one of this series](/blog/gitlab-for-project-management-one/) we looked at the pervasive problems around collaboration and how GitLab was built to resolve those challenges both in and out of the software development space. In this second part we take a detailed look at how our marketing teams used GitLab for project management._\n\nWhen we jumped in to using GitLab for project management, we did it in a big way. The [Just Commit marketing campaign](https://gitlab.com/groups/gitlab-com/marketing/-/epics/7) which launched in January 2019 is a good example of how the marketing team uses GitLab features like issues and epics.\n\n\"It was our first integrated campaign, and if you're not familiar with what that means, it's basically landing a single message across all channels,\" says [Jackie Gragnola](/company/team/#jgragnola), marketing programs manager. “So using social media, digital marketing, all of our content, our website. and in doing so, it was involving a lot of different team members.\"\n\nSince there were so many stakeholders involved, it was unrealistic that something like a Google Doc could provide the infrastructure necessary for efficient and transparent collaboration. Jackie migrated her kick-off document from Google Docs over to GitLab. \"It was the first test into using epics to give the high-level information and then organize the group into a single unified vision for what this campaign would become,\" she explains.\n\n![justcommit-integratedcampaign](https://about.gitlab.com/images/blogimages/gitlab-for-proj-management2/justcommit_integratedcampaign.png){: .shadow.large.center}\nThe Just Commit integrated campaign epic included the JustCommit label, as well as campaign goals, personas the campaign is targeting, links to recorded meetings, and more.\n{: .note.text-center}\n\nThe Just Commit ancestor epic also included details such as [UTM tracking links](https://gitlab.com/groups/gitlab-com/marketing/-/epics/7#utm-for-tracking-urls), a [list of teams and DRIs involved in the campaign](https://gitlab.com/groups/gitlab-com/marketing/-/epics/7#teams-involved-roles-responsibilities), and a [timeline of key dates and deliverables](https://gitlab.com/groups/gitlab-com/marketing/-/epics/7#key-timeline-dates) in the lead-up to the Feb. 18, 2019 launch.\n\nA level below the ancestor epic are child epics, which were organized by areas of action items. Some examples include organic search, webcasts, emails, and events; messaging and positioning, etc.\n\n![justcommit-child epics](https://about.gitlab.com/images/blogimages/gitlab-for-proj-management2/jc-childepics.png){: .shadow.large.center}\nExamples of some of the child epics for the Just Commit integrated campaign.\n{: .note.text-center}\n\nThe Just Commit label that was created was tagged to issues related to the campaign. It is simple enough to get a high-level overview of what issues are related to the Just Commit campaign by searching for the label.\n\nIn order to dig deeper into the different categories of work, you’d look at the issue list within the different child epics. The issue list functions essentially as a list of what needs to get done, and provides a good overview of what’s left to accomplish on the list.\n\n![justcommit-issue list](https://about.gitlab.com/images/blogimages/gitlab-for-proj-management2/jc-strategy-and-design.png){: .shadow.large.center}\nThis is an example of the issue list from the strategy and design child epic.\n{: .note.text-center}\n\nInside each issue is a DRI and a due date. The due dates were important not just to stay ahead of deadline, but also because there were a lot of dependencies baked into the integrated campaign.\n\n\"We couldn't work on the content until we knew what the message was, and we couldn't work on anything related to digital marketing until we had the designs approved,\" says Jackie. \"So, this just kept us organized by saying what we needed to get done by what dates and kept us up-to-date on the timeline that would help us hit that delivery date.\"\n\nBy using GitLab features such as ancestor epics, child epics, issues, and labels, the Just Commit integrated campaign kept all stakeholders updated on their progress and accountable for their deliverables.\n\n## How product marketing uses GitLab\n\n[Tye Davis](/company/team/#davistye) is a technical marketing manager and he uses GitLab for managing product marketing projects.\n\n### Use issue boards to get a global overview of work\n\nTye works primarily within the [product marketing project](https://gitlab.com/gitlab-com/marketing/product-marketing), which is housed in the broader marketing group. Just like we saw in the Just Commit integrated campaign, there are various ancestor epics, child epics, and issues housed within this project.\n\nThe [issue board view](https://docs.gitlab.com/ee/user/project/issue_board.html) is a useful way to visualize and organize all the issues and activity happening within a specific group or project. Viewing an issue board is simple enough: Just select boards under the issues tab to see all of the issues within a specific group, or to narrow the scope select a specific project. But building one is another matter entirely.\n\nIt is important to think strategically about the level at which you build your issue board, because that will impact how much information is rolled up into the board.\n\n\"You have to think about where your work lies and where you should be building your issue boards in epics,\" says [JJ Cordz](/company/team/#jjcordz), senior marketing ops manager. \"As an example, in marketing ops we presently work across departments so we do a lot of with sales ops, biz ops, sales in general, and all of those are individual projects and groups. So our issue board is actually built at this highest level (i.e., marketing group level) because we need to pull in everything else.\"\n\nBut not every team is as integrated as marketing ops. Sometimes building an issue board at the team level, instead of the group or project level, makes the most sense for your workflow.\n\nThe [technical marketing team has its own issue board](https://gitlab.com/gitlab-com/marketing/product-marketing/-/boards/926375?&label_name[]=tech-pmm), and it is sorted by labels. The labels it uses are uniform across the marketing group to indicate the status of a particular issue – `status: plan`, `status: WIP`, `status: scheduled`, or `status: review`. The labels automatically change when a particular issue is dragged between label lanes.\n\nThe use of these labels and the different team boards that live within the product marketing group allows anyone to take a look at the status of both individual issues and larger projects.\n\n### Team boards\n\nAnother option to configure an issue board is to base it on teams and sort based on an assignee. The team board view sorted by assignee allows you to see what each team member is working on.\n\n“We create boards based on assignee. This allows us to see who has what issue and what they're working on,\" says Tye. “Maybe your manager just wants to see what the team's working on or you're being a collaborative Agile team and want to just see what everyone's doing or what you could work on together.\"\n\n### Tracking progress\n\nThere are two main options for measuring work progress from a project management perspective: [milestones](https://docs.gitlab.com/ee/user/project/milestones/#project-milestones-and-group-milestones) and [burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html).\n\nMilestones are time-bound and track work output based on a specific timeframe (e.g., Q1 FY20 – a four-month period). When creating an issue, you can assign it to a specific milestone.\n\nBurndown charts reflect all the issues that are completed within the specific milestone. Once the time period (e.g., Q1 FY20), is up, you move any remaining and new work over to the next milestone (e.g., Q2 FY 2020).\n\n### Relating to GitLab customers\n\nWhile the marketing team and other teams across the company use GitLab as a project management tool, the majority of our customers are engineers that use GitLab as an Agile planning tool for developing code.\n\nWe can still relate to our customers through our use of issues and merge requests to make changes to the handbook, publish blog posts, among other activities in different repositories within GitLab.\n\nWhether you’re an infrastructure engineer, product marketing manager, or even an editor for the GitLab blog, the GitLab product functions as a sophisticated and customizable project management tool where collaboration and efficiency are baked into the function and design.\n\nWatch the video from [GitLab Contribute](/events/gitlab-contribute/) in New Orleans to see an overview of how GitLab can be used for project management, plus more on using GitLab for integrated campaigns and product marketing.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/tbg8KSyIWVg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nCover image by [Startaê Team](https://unsplash.com/@startaeteam) on [Unsplash](https://unsplash.com/s/photos/sticky-notes).\n{: .note}\n",[695,912,9],{"slug":2521,"featured":6,"template":698},"gl-for-pm-prt-2","content:en-us:blog:gl-for-pm-prt-2.yml","Gl For Pm Prt 2","en-us/blog/gl-for-pm-prt-2.yml","en-us/blog/gl-for-pm-prt-2",{"_path":2527,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2528,"content":2533,"config":2540,"_id":2542,"_type":13,"title":2543,"_source":15,"_file":2544,"_stem":2545,"_extension":18},"/en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare",{"title":2529,"description":2530,"ogTitle":2529,"ogDescription":2530,"noIndex":6,"ogImage":2471,"ogUrl":2531,"ogSiteName":685,"ogType":686,"canonicalUrls":2531,"schema":2532},"Google Summer of Code 2024: Contribute to GitLab and Git to prepare","Learning how to contribute to GitLab and Git can help you get ready to apply for Google's program for open source development.","https://about.gitlab.com/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Google Summer of Code 2024: Contribute to GitLab and Git to prepare\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Veenhof\"},{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n \"datePublished\": \"2023-12-20\",\n }",{"title":2529,"description":2530,"authors":2534,"heroImage":2471,"date":2537,"body":2538,"category":784,"tags":2539},[2535,2536],"Nick Veenhof","Christian Couder","2023-12-20","Google Summer of Code ([GSoC](https://summerofcode.withgoogle.com/)), a program that helps bring new contributors into open source software development, is just around the corner. So now is the time to start learning [how to contribute to GitLab](https://about.gitlab.com/community/contribute/) or Git and prepare ideas for GSOC 2024. GitLab has participated in GSOC for more than five years of the program's 20-year history, and the mentorship opportunity aligns well with our \"[Everyone can contribute](https://handbook.gitlab.com/handbook/company/mission/)\" mission.\n\nIn 2023, GitLab team members mentored GSoC contributors working on GitLab and Git open source projects throughout the 12-week program. One example was the “Unify ref-filter formats with other --pretty formats” Git project. \n\n## Implementing new formatting options for Git commands\n\nKousik Sanagavarapu was selected as a 2023 GSOC contributor and was mentored by [Christian Couder](https://gitlab.com/chriscool), staff backend engineer on the GitLab Gitaly::Git team.\n\nKousik’s work focused on implementing some [new formatting options for Git commands](https://summerofcode.withgoogle.com/programs/2023/projects/rck3kmq2) like `git branch`, `git tag` and `git for-each-ref`. These commands use a formatting mechanism called the “ref-filter” format. The formatting options Kousik worked on were already available for other commands like `git log`, that use a different formatting mechanism called the “pretty” format. So the work involved porting these options from the “pretty” format to the “ref-filter” format.\n\nThanks to Kousik’s work, it’s now possible to use a number of new placeholders like %(signature), %(authoremail:mailmap), or %(describe) in the –format option of `git branch`, `git tag`, and `git for-each-ref` to get more information about the commits that branches, tags, or refs in general point to. [Read the documentation](https://git-scm.com/docs/git-for-each-ref/2.43.0#_field_names) for a description of these placeholders.\n\nThese improvements are available in the recently released Git 2.43.\n\n## How GSOC works\n\nOpen source organizations who participate – such as GitLab and Git – have to propose projects and provide mentors. Selected contributors are helped by the mentors and paid by Google during 12 or more weeks while they work on their projects. Contributors are evaluated three times by mentors: after a “Community Bonding” period, in the middle of the coding period, and after the coding period for a final evaluation. \n\n## How to participate as a contributor\n\nTo apply to become a contributor for GSOC 2024, check out the [GSoC website](https://summerofcode.withgoogle.com/) and the [Google Open Source blog](https://opensource.googleblog.com). Interested parties should register [when selected organizations are announced](https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html), which will happen in a few months. \n\nContributors will then be selected by the mentors after they have made a small contribution and after they have prepared an application document that details how they plan to achieve the proposed project they want to work on.\n\nProspective contributors can start learning about GitLab or Git right now to be fully ready to make a small contribution and prepare an application. [As Google says](https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html), “The most successful applications come from contributors who start preparing now.” \n\nGitLab has a lot of documentation and tutorials [to learn how to contribute](https://about.gitlab.com/community/contribute/), while Git has a [Hacking Git page](https://git.github.io/Hacking-Git/) with a lot of helpful links.\n\n## How GitLab team members participate\n\nGitLab participates in GSOC as an open source organization and team members from different functional areas volunteer to mentor contributors and propose projects for them to work on. \n\nIn 2023, GitLab team members mentored contributors on a number of GitLab-related projects, including Pajamas Migration with the GitLab Foundations Team and improving the documentation for the contributor journey to GitLab.\n\n## How Git developers participate\n\nThe Git project also participates in GSoC as an open source organization, and Git developers who are interested in mentoring propose projects, and then select GSoC contributors.\n\nLast summer, in addition to the \"Unify ref-filter formats with other --pretty formats\" project, Git developers proposed the \"[More Sparse Index integrations](https://summerofcode.withgoogle.com/programs/2023/projects/Rkbc1Abe)\" project.\n\n## Mentoring and GitLab \n\nGitLab’s mission is “Everyone can contribute” and we understand that helping potential contributors through mentoring can achieve this goal. In addition to participating in external programs like GSOC and [Outreachy](https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020/), GitLab has internal mentoring programs, including a [CEO Shadow program](https://handbook.gitlab.com/handbook/ceo/shadow/) and a [Mentorship program for women](https://handbook.gitlab.com/handbook/company/culture/inclusion/tmrg-gitlab-women/mentorship-program/).\n\nLearn more about [mentoring at GitLab](https://handbook.gitlab.com/handbook/people-group/learning-and-development/mentor/).",[787,268,1285,1242,9],{"slug":2541,"featured":6,"template":698},"google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare","content:en-us:blog:google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare.yml","Google Summer Of Code 2024 Contribute To Gitlab And Git To Prepare","en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare.yml","en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare",{"_path":2547,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2548,"content":2553,"config":2558,"_id":2560,"_type":13,"title":2561,"_source":15,"_file":2562,"_stem":2563,"_extension":18},"/en-us/blog/hackathon-recap",{"title":2549,"description":2550,"ogTitle":2549,"ogDescription":2550,"noIndex":6,"ogImage":1462,"ogUrl":2551,"ogSiteName":685,"ogType":686,"canonicalUrls":2551,"schema":2552},"Recapping the first GitLab Hackathon","What we accomplished and learned from the Hackathon on September 27-28.","https://about.gitlab.com/blog/hackathon-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Recapping the first GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-10-09\",\n }",{"title":2549,"description":2550,"authors":2554,"heroImage":1462,"date":2555,"body":2556,"category":784,"tags":2557},[1281],"2018-10-09","\n\nWhen we wrapped up our first Hackathon on September 28th, I was impressed both\nwith the energy from participants (including many first-time contributors) and\nwhat the GitLab community accomplished over two days.\n\n## So what did we accomplish?\n\nOne of the key goals of the event was to encourage community members to contribute\nMerge Requests (MRs), and the community delivered more than 20 MRs, with 15 of\nthem merged as of October 8th. You can see the list of MRs at the\n[Hackathon Community MRs page](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/4).\nThis is pretty impressive when you consider that community members had a less than\n2-weeks notice for the event.\n\n## What else happened during the event?\n\nIn addition to hacking, we had several community experts deliver tutorial\nsessions on topics ranging from\n[GitLab Development Kit](https://www.youtube.com/watch?v=gxn-0KSfNaU),\n[documentation](https://www.youtube.com/watch?v=8GT2XOkpSi4&feature=youtu.be),\n[internationalization/translation](https://www.youtube.com/watch?v=LJ9oSSx0qyY&feature=youtu.be),\n[UX design](https://www.youtube.com/watch?v=q_nq5OCiktE&feature=youtu.be), and\n[Merge Request Coaches](https://www.youtube.com/watch?v=daCFv9tAQXw&feature=youtu.be).\nRecordings/slides from all the sessions can also be found on the [Hackathon wiki page](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/wikis/Q3%272018-hackathon).\nWe also identified a number of issues/bugs as listed on the [wiki](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/wikis/Q3%272018-hackathon#issuesbugs-found-during-the-hackathon),\nand we will certainly be following up on these.\n\n## Will there be another Hackathon event in the future?\n\nOur plan is to have a Hackathon event every quarter, and I'm excited to announce\nthat the Q4 Hackthon will take place on November 14-15. Stay tuned for further\nannouncements in another blog post and discussions on the\n[GitLab Community room in Gitter](https://gitter.im/gitlabhq/community)\nand on the [GitLab forum](https://forum.gitlab.com/). In addition,\nif you have any suggestions for topics and/or feedback on last month's event,\nplease mention them on the [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community)\nto help us improve future Hackathons.\n\n## Hackathon prizes\n\nAs we announced at the Hackathon kickoff, everyone who had MRs merged will\nreceive a token of our appreciation so they can purchase GitLab merchandise at\nthe [GitLab store](https://shop.gitlab.com/). During the Hackathon period,\neight people had MRs merged and the \"grand prize\" winner with most MRs merged is\n[George Tsiolis](https://gitlab.com/gtsiolis) with seven merged MRs!\nCongratulations to everyone! I will reach out to all winners shortly.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel).\n{: .note}\n",[268,9,787,278],{"slug":2559,"featured":6,"template":698},"hackathon-recap","content:en-us:blog:hackathon-recap.yml","Hackathon Recap","en-us/blog/hackathon-recap.yml","en-us/blog/hackathon-recap",{"_path":2565,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2566,"content":2572,"config":2579,"_id":2581,"_type":13,"title":2582,"_source":15,"_file":2583,"_stem":2584,"_extension":18},"/en-us/blog/high-efficiency-innovation",{"title":2567,"description":2568,"ogTitle":2567,"ogDescription":2568,"noIndex":6,"ogImage":2569,"ogUrl":2570,"ogSiteName":685,"ogType":686,"canonicalUrls":2570,"schema":2571},"3 lessons for innovation and rapid execution from GitLab","Guest author Jay Newman recently shadowed our CEO to discover how we move so quickly.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680169/Blog/Hero%20Images/high-efficiency-innovation.jpg","https://about.gitlab.com/blog/high-efficiency-innovation","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jay Newman\"}],\n \"datePublished\": \"2018-03-27\",\n }",{"title":2573,"description":2568,"authors":2574,"heroImage":2569,"date":2576,"body":2577,"category":910,"tags":2578},"High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution",[2575],"Jay Newman","2018-03-27","\n\nAll companies have different ways of creating new products and services. Despite that, there are a few patterns that show up consistently. At [Jump](http://www.jumpassociates.com), we like to call those patterns the different \"cultures\" of innovation. One such pattern has to do with execution. Great executors (like GE and FedEx) are masters of sharp focus and efficient machine-making.\n\nMany of the Fortune 500 companies that we work with do their best innovation this way. They've built infrastructure that excels at launching products globally, coordinating thousands of employees and operating at massive scale. These companies often ask us what they can learn from what's going on in Silicon Valley. There's much to learn, of course, from the startups and entrepreneurial ecosystem here.\n\nThe important question is not \"How do they do things in Silicon Valley?\" Instead, it's \"What can I learn that would work well in my organization?\" It's always exciting to come across a startup that's doing what these big companies do best – execute at scale – and doing it in a completely different way.\n\nGitLab is one such company. They're an open source software company powering many of the world's largest corporations. They've developed a surprising – and strong – culture of innovation. They're a remote-only company. There's no physical headquarters or office space for their 200+ employees located worldwide. They proudly admit that they value \"boring solutions.\" Their [entire business strategy is available](/company/strategy/) for the public and their competitors to see. They're respected for their [product](/blog/gitlab-leader-continuous-integration-forrester-wave/), their [culture](/company/culture/), and their [results](http://www.businessinsider.com/gitlab-raises-20-million-from-gv-2017-10).\n\nMany companies pride themselves on their ability to iterate quickly and answer yes/no decisions rapidly. Even they might be surprised at the scope and scale of GitLab's efficiency. GitLab drives high-efficiency innovation through a culture of rapid execution. They weave speed directly into the fabric of who they are and what they do. Do you want to learn how they do it? I recently shadowed GitLab's CEO, [Sid Sijbrandij](/company/team/#sytses), and his team for a day.\n\nHere's how they make it happen.\n\n## When the answer is clear, build for speed. Speed wins.\n\n*Why build a culture of rapid execution?*\n\nWith such a unique team culture and set of business practices, the first thing I wanted to learn from Sid was why GitLab operates the way it does. What became clear was that it's all very intentional.\n\nA few key beliefs are central to the decisions they've made:\n\n### Belief 1: The solution required to win is already super clear to everyone.\n\nThey're operating in a market called DevOps, which is about creating platforms and tools for software developers to use in their work. It's a market where both the unmet customer need and the ideal solution are clear to everyone.\n\nThey were newer to the game than some brand name and legacy competitors, so they chose to prioritize speed over invention to get to the finish line first.\n\n### Belief 2: If you don't do anything new, you can do things faster, bigger and better.\n\nThe folks at GitLab believe that it's better to be boring. They value \"boring solutions.\" It's not because boring is better in and of itself. It's because boring is efficient. It's faster. And faster can become bigger. And when you add in collaboration with a global open source community, bigger can become better.\n\nIf there's a market standard, they don't try to create something different. They get on board. As Sid says, \"It's about convention over conviction. We make sure everyone [in the open source community] is enticed to participate. If the rest of the world is doing it in some way, we should be doing it in that way.\"\n\n### Belief 3: It's OK not to make everyone happy.\n\nIt's hard for most companies – and most people – to change to what made them successful in the first place. For GitLab, making those kinds of changes is critical to achieving the growth they seek. So on a daily basis, they choose to act quickly, make mistakes quickly, and learn from those mistakes quickly.\n\nThat can lead to decisions – big and small – that might not make everyone happy.\n\nWhen they launch a completely new version of GitLab (they're on version [10.6](/releases/2018/03/22/gitlab-10-6-released/) right now), they always add some things that will frustrate some existing customers, and they often take away things that other customers love.\n\n\"There's way more people not using GitLab than that are. So we should always optimize for those future customers, not your current ones. That's why companies slow down. They start listening. Engineers want to fix the current bugs. Sales wants to keep the old deck that works for them. You start listening to your customers and what they need you to maintain or fix. The natural motion of any company is to slow down. So as CEO you need to get the company beyond that.\"\n\nSo what does high-efficiency innovation and rapid execution look like at GitLab?\n\nHere are a few examples of the pace at which they operate:\n\n1. They release a new version of GitLab every single month.\n1. Everything is in draft and subject to change. It's always under construction.\n1. They don't repeat themselves. GitLab documents how it does things in a [handbook](https://handbook.gitlab.com/handbook/). It's 1,000 pages long. If it's in the handbook, don't repeat it.\n1. Every conference call starts on time. No wasted minutes. Sid checks 15-30 action items off the list in each of his 25-minute 1-on-1 meetings.\n1. They trust their team to multi-task appropriately. If you want to check email during a meeting, it's probably more important than the meeting is to you.\n\nThere's a final, often-overlooked value of speed: it's exciting. Workplaces that manage to pair speed with evident progress allow their teams to feel accomplished, motivated, and on the edge of their seats. It's an easy hack for maintaining employee engagement.\n\n## Don't sacrifice long-term vision for short-term speed. Be accountable for both.\n\n*What is GitLab is rapidly executing on?*\n\nMany companies who prize execution do a great job at sustaining and growing their existing products. They're often quite efficient – though they could learn something from the speed at which GitLab operates. But they're more likely to struggle with thinking far out into the future.\n\nTo paraphrase Stephen Covey, there's a big difference between efficiency and effectiveness. A jet flying 1,000 miles per hour is efficient; a jet flying 1,000 miles per hour in the right direction is effective.\n\n#### So if GitLab as an organization is a jet built for speed – where is it going?\n\nSid wants GitLab to help multiply the potential for progress that humanity can drive into the world. \"Our mission is 'Everyone can contribute.' That's a long-term vision. That's 10 years. It means changing all of our culture to read-write. Think Wikipedia. They allow everyone to contribute. Imagine if we can do that. You release a lot of progress. You 10x the progress. [Multipliers like that are] thrown around so easily in Silicon Valley that you have to be cautious. But if you look at 100,000 companies using GitLab, and really being able to get their out software faster. I'm willing to stand behind that.\"\n\nThat means that not only is GitLab thinking about efficiency and effectiveness, but it's also thinking about impact. Impact on the scale of human progress and global culture.\n\nThat's pretty big and pretty far out. So how do they make sure the pilots keep looking way out there on the horizon while flying at supersonic speeds and maneuvring around today's obstacles?\n\nFirst, you set the mission and vision. Everything starts with that mission in mind. Everyone knows it, and Sid talks about it [every chance he gets](https://blog.ycombinator.com/gitlab-distributed-startup/).\n\nNext, you draw that vision back into today's actions with cascading plans. Create a three-to-five-year strategy about how to get there. Craft a yearly plan and [product vision](/blog/gitlabs-2018-product-vision/) – one that's concrete enough that you could show screenshots of what it will look like a year from now. Define quarterly goals (GitLab's [OKRs](/company/okrs/) are public), monthly targets, and smaller sprints to get you there.\n\nThird, you make each of these regular goals highly ambitious, close-in, unambiguous, and concrete. \"Setting high goals pushes people beyond their comfort zone,\" Sid told me. At Y Combinator, he says they taught GitLab that \"20 percent is the new 10 percent.\" That's 20 percent growth, every single week. It's a high number, and it forces them to make completely different types of decisions.\n\nFinally, because the short-term goals are incredibly high, you focus on iteration. [Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is one of GitLab's core values. They define it clearly: \"We do the smallest possible thing and get it out as quickly as possible.\" And they don't just ask developers and designers to work this way. \"We put the whole company on that diet. It made sense for the product. But for marketing, sales, etc., we've gotten them there. If you say 'Grow XYZ in the next two weeks,' you do completely different things. I don't know why that is, but you do.\"\n\n### Encode culture and values to keep the company moving faster.\n\n*How does GitLab do what they do?*\n\nIt was GitLab's strong culture and values orientation that first drew me to them as an organization. I'm often on the lookout for how leaders drive values through their organizations – from Jon Stewart on \"The Daily Show\" to the frontline teams at Starbucks and Zappos.\n\nThe best values-oriented organizations draw explicit links between their values, their competitive advantages, and their daily activities.\n\nHere's where GitLab stands out.\n\nIn just one day of shadowing GitLab's staff, the team talked about values during a product meeting, two interviews with prospective employees, an analyst call and a 1-on-1 with a teammate. The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).\n\n>The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).\n\nSo how does that work? It requires leaders choosing to identify not just the values that matter, but also how to organize around them. Sid told us \"I didn't do a very good job coding GitLab [when he and his co-founders all started back in 2011]. But I think I'm doing a good job coding GitLab the company.\"\n\nAs a remote-only company, \"coding the company\" means (1) writing things down, (2) referencing back to what's been written and (3) reinforcing it through rewards.\n\nAll of this \"GitLab the company\" code is captured in its handbook. The handbook is referenced in almost every conversation. The handbook consists of over 1,000 pages of text. It's a tool that GitLab uses to capture and detail out decisions that have already been made about all of its core business practices – marketing, sales, product, team operations, finance, and more. It's a constant practice for Sid and the team to reference the handbook in meetings, and to send people to look there first before continuing the conversation.\n\nThe values take a prime place in the handbook. There, values are defined, not just described. Words can mean different things in different contexts – and these values indicate a particular thing at GitLab. The definitions are brought to life with 5-15 concrete actions that employees often take for each of the six values. As Sid says, \"The culture got stronger because it is written down. And because it improves and is edited over time.\" And then they're reinforced every day through hiring, coaching, performance reviews and casual conversations.\n\nIt's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work. What GitLab has unlocked with its values orientation is not just good and meaningful work. It has also opened the most important competitive advantage in its business model – speed.\n\n>It's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work.\n\nIt says it right there in the 'Why have values' section of the handbook: \"Values are a framework for distributed decision-making; they allow you to determine what to do without asking your manager.\" By encoding values deep into everyday activities of the company, everyone on GitLab's team can make decisions faster.\n\nIn DevOps, winning is about getting there first. GitLab coded values right into its organizational design to make sure it could always be the fastest to market.\n\n## Parting thoughts: Will high-efficiency innovation work for you?\n\nAlthough they weren't thinking about large corporations, the oracles of Delphi were right. The most important maxim is to \"know thyself.\" The GitLab prescription isn't right for every company. What's most important is to build a culture of innovation that reflects your strengths and your values.\n\nGitLab is a company of executors, of coders and of people who aren't afraid to work out in the open and make mistakes. They see clear problems. Then they attack. GitLab built a method of innovation that works well for them, but it's not a one-size-fits-all approach. It won't work for everyone, but it might work for you.\n\n#### Here are the questions you should ask:\n\n1. Is the problem you're facing clear to you and your competitors?\n1. Would the people on your team prioritize efficiency over novelty if it'll get you there first?\n1. Do you know how to make trade-offs between what works for your existing customers and what might work better for future customers?\n\nIf you answered yes, pay close attention to what GitLab is doing. Their unrelentingly quick iterative process might be just what the doctor ordered to scale your innovation.\n\nIf not, the GitLab system isn't the right fit for you. You'll want to organize your innovation in a different way.\n\nAs one example, we built Jump to handle an entirely different type of [highly ambiguous problems](https://www.forbes.com/sites/brucerogers/2018/01/25/innovation-leaders-dev-patnaik-co-founder-and-ceo-jump-associates/3/#42518f211238). So it makes sense that some of Jump's values (Passion, Curiosity, Enthusiasm, Intention, Acuity, Initiative and Play) look very much the opposite of GitLab's values (Collaboration, Results, Efficiency, Diversity, Iteration and Transparency).\n\nJump and GitLab are both deeply values-oriented companies with rich and collaborative cultures focused on innovation. And yet we value different things, have different org structures, hire different types of people and work on very different types of problems.\n\nSo what if you're like me and your company's approach or market situation is quite different than GitLab's? Take this as an opportunity to learn from seeing your mirror image.\n\nFirst, test parts of their approach. See what works for you and your team. Then, consider the polar opposites. Find the points where you value distinctly different things, and ask why. Learn why their method works for them, and why it wouldn't work for you. Then flip the script – what's an approach to innovation that GitLab would never do that would be a difference maker for you if you did it?\n\nEither way, take note of what GitLab is doing and how they're doing it. It's amazing, effective, growing like crazy and a great place to work. And ask yourself – should my team be innovating like that?\n\n## About the guest author\n\nJay Newman is Director of Strategy at Jump Associates, a leading strategy and innovation firm. Learn more at [jumpassociates.com](http://www.jumpassociates.com) and connect directly with Jay on [LinkedIn](https://www.linkedin.com/in/jaynewman1).\n\nPhoto by [Karsten Würth](https://unsplash.com/photos/ZKWgoRUYuMk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[934,9,912],{"slug":2580,"featured":6,"template":698},"high-efficiency-innovation","content:en-us:blog:high-efficiency-innovation.yml","High Efficiency Innovation","en-us/blog/high-efficiency-innovation.yml","en-us/blog/high-efficiency-innovation",{"_path":2586,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2587,"content":2593,"config":2598,"_id":2600,"_type":13,"title":2601,"_source":15,"_file":2602,"_stem":2603,"_extension":18},"/en-us/blog/how-a-devops-platform-can-help-solve-5-key-smb-frustrations",{"title":2588,"description":2589,"ogTitle":2588,"ogDescription":2589,"noIndex":6,"ogImage":2590,"ogUrl":2591,"ogSiteName":685,"ogType":686,"canonicalUrls":2591,"schema":2592},"How a DevOps platform can help solve 5 key SMB frustrations","SMBs already wear all of the hats. Here are 5 ways a DevOps platform can ease the burden.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668242/Blog/Hero%20Images/assembly-3830652.jpg","https://about.gitlab.com/blog/how-a-devops-platform-can-help-solve-5-key-smb-frustrations","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How a DevOps platform can help solve 5 key SMB frustrations\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-04-25\",\n }",{"title":2588,"description":2589,"authors":2594,"heroImage":2590,"date":2595,"body":2596,"category":757,"tags":2597},[734],"2022-04-25","\n\nStart-ups and small or medium-sized businesses (SMBs) face plenty of challenges, but several of those hurdles can be eased by [adopting a DevOps platform](https://page.gitlab.com/resources-ebook-smb-beginners-guide-devops.html). A DevOps platform can help not only address the issue at hand but the benefits can spread across the company, [helping it grow in a competitive and unpredictable market](/blog/6-ways-smbs-can-leverage-the-power-of-a-devops-platform/).\n\nThe United States alone is home to 32.5 million small businesses, making up 99.9 percent of all companies in the country, according to a [2021 report from the Small Business Administration’s Office of Advocacy](https://cdn.advocacy.sba.gov/wp-content/uploads/2021/08/30143723/Small-Business-Economic-Profile-US.pdf). And all of these companies have a tough road to travel – so tough that 20 percent of U.S. small businesses fail within the first year, according to the [U.S. Bureau of Labor Statistics](https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm). By the end of the fifth year, about 50 percent are shuttered.\n\nStressed with common problems like worker overload, finding time for collaboration, and meeting customer and market needs, smaller businesses are under a lot of pressure. With SMBs and small or medium-sized enterprises (SMEs) facing such significant challenges, it only makes sense to streamline software development, [speed up deployments](/blog/pipelines-as-code/), automate repetitive tasks and [foster collaboration](/blog/collaboration-communication-best-practices/). Taking all those steps can greatly improve an SMB’s odds of success. \n\nHere’s how a DevOps platform can help take on some major SMB frustrations:\n\n## Ease worker fatigue and improve work/life balance\n\nSMBs, by definition, have fewer employees than their larger, more-established competitors. That means there are fewer people to take on all the tasks that need to be done. And that’s no different for the software development team, which could very well be a team of one. With everyone in an SMB having to wear so many hats and take on so many different jobs, it can be exhausting. That’s not only hard on productivity, it’s hard on employees’ work/life balance, and therefore not good for the business or the workforce.\n\nA DevOps platform offers an environment that fosters communication, collaboration and automation, which help ease the burdens on the IT staff. This will help [get work done more efficiently and faster](/blog/why-improving-continuously-speeds-up-delivery/), leaving employees with more time for other projects.\n\n## Satisfy customers\n\nHow can you find new customers when you’re not a household name? You do it by keeping the buyers you have and pulling in more by satisfying, and even delighting, your customer base. Satisfied consumers stick around, buy more, and give free word-of-mouth marketing.\n\nA DevOps platform helps SMBs create customer satisfaction by automating the customer feedback process and accelerating [software development and deployment](/blog/how-to-keep-up-with-ci-cd-best-practices/). \n\n## Increase communication and collaboration\n\nWorkers in start-ups and small businesses often take on a multitude of projects, and try to chip away at their burgeoning workflows. Meetings – within a department or cross-functional – may be either low priority or tough to arrange. A “heads’ down” attitude is understandable, but means different demographics and perspectives often won’t come together to [better innovate](/blog/pipelines-as-code/) and create more well-rounded products for a wider range of consumers. \n\nA DevOps platform promotes collaboration by eliminating barriers not just between IT workers but within an entire company. And that leads to more innovative features and products, improves productivity, and keeps employees happier and more engaged. Collaborative workers also are continuously learning from each other.\n\n## Adapt to the market with speed and agility\n\nEvery market can be unpredictable. New competitors appear. Customer expectations shift. Supply chain problems affect production. SMBs need to be able to change on a dime, to meet or get ahead of new demands and even new competitors.\n\nA DevOps platform [can keep a business of any size agile](/blog/can-an-smb-or-start-up-be-too-small-for-a-devops-platform/) by enabling a tech team to scale development and deployment to quickly and efficiently turning ideas into new features or new products.\n\n## Multiply a small business’ tech muscle\n\nSince small businesses, by definition, have fewer people, they obviously have smaller IT departments. They may even have a department of one. That can make it difficult to design, develop and deploy new software, not to mention come up with new and better ways to serve and communicate with customers and the supply chain. When [project planning is a joint, cross-functional effort](/blog/achieve-devsecops-collaboration/) it’s possible to do more with less. And having fewer DevOps tools involved - even having everyone use the same tool - can make a big difference.\n\nA DevOps platform, with automated options for everything from testing to monitoring and [doing GitOps with GitLab](/blog/the-ultimate-guide-to-gitops-with-gitlab/), can lessen the hands-on workload, giving IT people more time for other, more creative, projects.\n",[695,1141,9],{"slug":2599,"featured":6,"template":698},"how-a-devops-platform-can-help-solve-5-key-smb-frustrations","content:en-us:blog:how-a-devops-platform-can-help-solve-5-key-smb-frustrations.yml","How A Devops Platform Can Help Solve 5 Key Smb Frustrations","en-us/blog/how-a-devops-platform-can-help-solve-5-key-smb-frustrations.yml","en-us/blog/how-a-devops-platform-can-help-solve-5-key-smb-frustrations",{"_path":2605,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2606,"content":2612,"config":2617,"_id":2619,"_type":13,"title":2620,"_source":15,"_file":2621,"_stem":2622,"_extension":18},"/en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career",{"title":2607,"description":2608,"ogTitle":2607,"ogDescription":2608,"noIndex":6,"ogImage":2609,"ogUrl":2610,"ogSiteName":685,"ogType":686,"canonicalUrls":2610,"schema":2611},"My experience as a recruiting intern at GitLab","Why interning for an asynchronous and all-remote company is the best way to go.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673044/Blog/Hero%20Images/books-internship-post.jpg","https://about.gitlab.com/blog/how-a-remote-internship-at-gitlab-shaped-my-career","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"My experience as a recruiting intern at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Trevor Knudsen\"}],\n \"datePublished\": \"2019-12-06\",\n }",{"title":2607,"description":2608,"authors":2613,"heroImage":2609,"date":2342,"body":2615,"category":910,"tags":2616},[2614],"Trevor Knudsen","\n\n[Applications for GitLab's engineering internship program are open! Apply now](/handbook/engineering/internships/).\n{: .alert .alert-gitlab-purple .text-center}\n\nWhile a remote internship may seem like a foreign idea with many limitations to some, in reality, the options can be far less limiting than office work. Working remotely comes with many perks, including work-life balance, ability to travel, and the flexibility to work wherever you please, but the benefits go beyond that. Taking an internship away from the office offers learning experiences. You have the opportunity to work with people outside your city – and instead collaborate with people from all around the world. Flexibility, learning opportunities, mentors, and work experience are all so accessible with a remote internship.\n\n## Why I joined GitLab\n\nAs a communications major at California State University, Fullerton, I was required to find an internship. While I was looking for an internship, the [all-remote](/blog/the-remote-manifesto/) setup of GitLab immediatly caught my attention, and there was an opportunity as recruiting intern that I could not pass up. I applied and after going through the interview process I was offered the position. 🎉\n\n### Globally distributed team\n\nI started with GitLab in October 2017, which was my senior year of college. My first day with GitLab was such a rush. I met with my mentor, manager, and the team, and went through onboarding. I was welcomed as if I was a full-time employee by my team, and I quickly realized my entire team was my mentor. I had coworkers in the United Kingdom, South Africa, and all across the United States. While every team member was helpful, one of my greatest mentors was (and continues to be) [Nadia Vatalidis](/company/team/#vatalidis). She worked as a recruiter also and checked in with me on a regular basis to make sure I felt comfortable using the GitLab tool and see what tasks I was working on. We also collaborated on different projects the recruting team was working on.\n\n### Our values\n\nGitLab is guided by its values, and each day I saw these [values](https://handbook.gitlab.com/handbook/values/) used in every aspect of our work. The [diversity](https://handbook.gitlab.com/handbook/values/#diversity-inclusion) of the recruiting team was a strength, bringing creative solutions to the table each day. The entire company [collaborated](https://handbook.gitlab.com/handbook/values/#collaboration) on projects and shared ideas, while always respecting each other's thoughts and opinions. One of the great things about working with GitLab was that if an idea was presented, it could be implemented after a bit of discussion even if not yet refined. This ensured that we operated with [efficency](https://handbook.gitlab.com/handbook/values/#efficiency) and [transparency](https://handbook.gitlab.com/handbook/values/#transparency) values. Our team would push forward initiatives and ideas and [iterate](https://handbook.gitlab.com/handbook/values/#iteration) on them as they were implemented.\n\n### All-remote and asyncronous workflows\n\nThe wonderful thing about GitLab is I was able to work when I wanted. When I had midterms coming up, I was able to take a few days off to study. Vacation was never a hindrance, I simply took the days off. GitLab has a [no ask, must tell](/handbook/paid-time-off/) PTO policy, meaning as long as I shared my plans with manager and team, I could take the time off. Working remotely also allowed me to work from anywhere. When I took a trip to Zion National Park in Utah with friends, I was able to adjust my working hours so I could explore by day and work in the evenings. On a snowy day in Zion, I sat on the back patio next to a warm fire, watching the beauty of the snowfall. It was this experience that helped me recognize the true potential of all-remote. The best part about the flexibility is even when I adjusted my work hours, I was never truly alone. Team members in Europe, the Middle East, and even in Africa were online when the team in the Americas has already logged out. Someone was always online and available for support.\n\n## Not your average internship\n\nMy experience as a GitLab intern was not typical, because it was a true work experience. I got the pleasure of working alongside the team on major projects, such as looking into a new application tracking system. I got to be involved in screening calls, scheduling interviews for candidates, and helped implement a better solution on how to maintain company assets. My internship helped me learn and grow the skills necessary to be part of the recruiting team, and ultimately landed me a full-time position at GitLab just six months into my internship.\n\nI learned so much as a GitLab team member, and met so many people who continue to be a mentor to me today. An all-remote internship was also ideal for me as a student, because I was able to have a solid work-life balance – something I continue to enjoy today.\n\nIf you're a student or career-changer searching for an internship, be sure to not undercut remote work opportunities. Check out GitLab's [current internship opportunites](/handbook/engineering/internships/). You can really learn so much as part of a fully distributed team.\n\n_Read more about [making remote internships successful](/blog/making-remote-internships-successful/)._\n\nCover image by Patrick Tomasso on [Unsplash](https://unsplash.com)\n{: .note}\n",[9,934,1097],{"slug":2618,"featured":6,"template":698},"how-a-remote-internship-at-gitlab-shaped-my-career","content:en-us:blog:how-a-remote-internship-at-gitlab-shaped-my-career.yml","How A Remote Internship At Gitlab Shaped My Career","en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career.yml","en-us/blog/how-a-remote-internship-at-gitlab-shaped-my-career",{"_path":2624,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2625,"content":2631,"config":2637,"_id":2639,"_type":13,"title":2640,"_source":15,"_file":2641,"_stem":2642,"_extension":18},"/en-us/blog/how-automation-is-making-devops-pros-jobs-easier",{"title":2626,"description":2627,"ogTitle":2626,"ogDescription":2627,"noIndex":6,"ogImage":2628,"ogUrl":2629,"ogSiteName":685,"ogType":686,"canonicalUrls":2629,"schema":2630},"How automation is making DevOps pros’ jobs easier","Six ways automation in a DevSecOps platform aids security, monitoring, compliance, and CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662504/Blog/Hero%20Images/devsecops-automated-security.jpg","https://about.gitlab.com/blog/how-automation-is-making-devops-pros-jobs-easier","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How automation is making DevOps pros’ jobs easier\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-12-12\",\n }",{"title":2626,"description":2627,"authors":2632,"heroImage":2628,"date":2633,"body":2634,"category":757,"tags":2635},[734],"2022-12-12","\nAs DevOps professionals look for ways to save time, money, and tech muscle as they work to push better and more secure software out the door, they’re increasingly seeing the advantages of automation — and that those advantages seamlessly come with adopting an end-to-end [DevSecOps](/topics/devsecops/) platform. \n\nIn a 2022 GitLab quiz, more than 82% of respondents said automation plays a “vital” role in developing and deploying safer and faster releases. \n\nIt’s clear that DevOps professionals are realizing that automation minimizes the need for a lot of extra hands-on and time-consuming work, like backup, installation, and maintenance. It also can reduce the potential for human error and provide consistency. A DevSecOps platform, unlike a cobbled-together [DIY toolchain](https://page.gitlab.com/resources-ebook-trading-diy-devops-for-a-single-platform.html), offers many advantages, like visibility and collaboration. Another major benefit is that it offers automation for everything from alerts to [testing](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/) and monitoring.\n\n## Benefits of DevSecOps automation\n\nHere is how automation throughout the software lifecycle could help DevOps teams cut time and money spent on repetitive tasks, eliminate human errors, and streamline the whole DevOps process:\n\n1. Security – A critical benefit of migrating to a full DevSecOps platform is that software won’t simply get a security test at the end of the pipeline – an inefficient, and often costly, feedback system. When [security is shifted left](/blog/efficient-devsecops-nine-tips-shift-left/), if a vulnerability or compliance issue is introduced into the code, it’s identified almost immediately thanks to automated and consistent testing. Automation built into a DevOps platform leads to better software and reduces the time between designing new, higher-quality features and rolling them out into production. And that maximizes the overall return on software development.\n\n2. Compliance – With a single DevSecOps application, [compliance confirmation](/stages-devops-lifecycle/govern/) lives within the platform and is automated. That means professionals can verify the compliance of their code without leaving their workflow, removing the need for compliance managers to require developers to context switch among different point solutions in a DIY toolchain, which can lead to the loss of productivity and efficiency. \n\n3. Configuration – It’s a complicated job to set up, manage, and maintain application environments. [Automated configuration management](/stages-devops-lifecycle/configure/) is designed to handle these complex environments across servers, networks, and storage systems.\n\n4. Continuous integration (CI) – This is the step that enables the DevOps practice of iteration by committing changes to a shared source code repository early and often – often several times a day. [CI](/blog/basics-of-gitlab-ci-updated/) is all about efficiency. By automating manual work and testing code more frequently, teams can iterate faster and deploy new features with fewer bugs more often.\n\n5. Continuous delivery (CD) – This is a software development process that works in conjunction with continuous integration to automate the application release process. When [deployments are handled automatically](/blog/cd-automated-integrated/), software release [processes are low-risk, consistent, and repeatable](/blog/boring-solutions-faster-iteration/). \n\n6. Monitoring – This is a proactive, automated part of the process, focused on tracking software, infrastructure, and networks to trace status and raise alerts to problems. [Monitoring](/stages-devops-lifecycle/monitor/) increases security, reliability, and agility. \n\n## Automation by the numbers\n\nIn fact, the [GitLab 2022 Global DevSecOps Survey](https://learn.gitlab.com/dev-survey-22/2022-devsecops-report), which polled more than 5,000 DevSecOps professionals, showed that automation is becoming increasingly critical to all DevOps teams.\n\nThe survey found that 47% of teams report their testing is fully automated today, up from 25% last year. Another 21% plan to roll out test automation at some point in 2022, and 15% hope to do so in the next two or more years. And three-quarters of respondents told us their teams use a DevSecOps platform or plan to use one this year. \n\nWhy are they using a platform? Well, security professionals called out easier automation and more streamlined deployments.\n\n## Fewer repetitive and unnecessary tasks\n\nSo what is all of this automation enabling DevOps professionals to do? They’re able to let go of a lot of work. \n \nAccording to the DevSecOps Survey, respondents said they’ve been able to reduce a lot of repetitive tasks. For instance, they say they no longer have to do as much infrastructure “handholding” — they’re not manually testing their code, writing messy code, and ignoring code quality. \n \nWith automation, each task is performed identically and with consistency, reliability, and accuracy. This promotes speed and increases deliveries, and, ultimately, deployments. While it doesn’t remove humans from the picture, automation minimizes dependency on humans for managing recurring tasks. \n\nAnd with GitLab’s single, end-to-end DevSecOps platform, automation is a system feature and not something that has to be added in. Automation with the GitLab platform is ready to go. Check out the [“Ditching DIY DevOps for GitLab’s Single Platform”](https://page.gitlab.com/resources-ebook-trading-diy-devops-for-a-single-platform.html) to learn more ways a platform can help DevOps teams.\n",[695,9,1306,2636],"CD",{"slug":2638,"featured":6,"template":698},"how-automation-is-making-devops-pros-jobs-easier","content:en-us:blog:how-automation-is-making-devops-pros-jobs-easier.yml","How Automation Is Making Devops Pros Jobs Easier","en-us/blog/how-automation-is-making-devops-pros-jobs-easier.yml","en-us/blog/how-automation-is-making-devops-pros-jobs-easier",{"_path":2644,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2645,"content":2651,"config":2656,"_id":2658,"_type":13,"title":2659,"_source":15,"_file":2660,"_stem":2661,"_extension":18},"/en-us/blog/how-do-we-handle-engineering-led-initiatives-that-dont-belong-to-one-team",{"title":2646,"description":2647,"ogTitle":2646,"ogDescription":2647,"noIndex":6,"ogImage":2648,"ogUrl":2649,"ogSiteName":685,"ogType":686,"canonicalUrls":2649,"schema":2650},"How do we handle engineering-led issues that don't belong to one team?","A recent issue sparked a lively discussion between engineering and product leadership about how 'cross-vertical' issues should be prioritized to avoid the bystander effect.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678916/Blog/Hero%20Images/how-do-we-handle-engineering-led-initiatives.jpg","https://about.gitlab.com/blog/how-do-we-handle-engineering-led-initiatives-that-dont-belong-to-one-team","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How do we handle engineering-led issues that don't belong to one team?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n \"datePublished\": \"2018-10-30\",\n }",{"title":2646,"description":2647,"authors":2652,"heroImage":2648,"date":2653,"body":2654,"category":300,"tags":2655},[1487],"2018-10-30","\nThe GitLab engineering team is split according to [product category](https://handbook.gitlab.com/handbook/product/categories/), so that team members in each category can [focus, specialize, and collaborate](/blog/configure-post/) on the same issues at the same time. They are semi-siloed by design, so what happens to issues, like tech debt, that are everyone and no one’s responsibility?\n\nThe short answer is, teams are still figuring it out. A recent [issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/52150) sparked a lively discussion and video call, which you can watch below. Listen in below on the discussion between engineering and product leadership about how technical debt or other engineering initiatives that are \"cross-vertical\" (that is, touch on many different product areas) should be prioritized given that there isn't one clear point of contact or responsibility for those issues.\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/3ZEI4W_Cb2g\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n### The gist\n\nThe issue that started it all had to do with a task that would have been assigned to the former Platform team, which used to be a catch-all that has since been split up into Create and Manage. Engineering Manager, Create [Douwe Maan](/company/team/#DouweM) explains, “With all backend teams now focused on specific product areas... there is no team to take on these kinds of backend-wide, non-product-area specific issues anymore.”\n\nHe continues, “Issues like this affect all backend teams equally, so we fall prey to the bystander effect. When an engineering manager gets to make room in a given release for an engineering-led initiative, they have the choice between issues like this, that any team could pick up, and product area-specific issues, that aren't going to get done unless their team does it, so the latter will have a far higher chance of being picked. Everyone cares about these kinds of issues, which means no one cares... there are many issues (technical debt and otherwise) that aren't currently anyone's responsibility, so they won't get done.”\n\nThis felt like a recurring problem due to other recent examples of cross-vertical initiatives stalling, like this issue to [switch to Rails 5 in production](https://gitlab.com/gitlab-org/gitlab-ce/issues/48991), and this issue to [update GitLab's referrer policy](https://gitlab.com/gitlab-org/gitlab-ce/issues/39147).\n\n### The research\n\nWe've heard from our community that this is a common problem, especially when working with others in different functions. In [recent interviews](https://drive.google.com/file/d/1A5mSNoPJydjcWKE4rdO2287sjnABxGDA/view) with 15 DevOps engineers, many expressed their frustration at the amount of reactive work and rework that they face, and identified a lack of successful coordination and empathy between different teams as the culprit. One interviewee said he thought this is inherent to working with some functions. Because of how release schedules work for developers and security engineers, he thinks these groups are the least likely to feel they are able to assign cycles to some proactive tasks, like fixing technical debt before it's critical.\n\nThe nearly 20 [software engineers](https://drive.google.com/file/d/1EVrjVcgIBbuNf4Gwenajsiy6Wv9HsTJw/view) we [interviewed](https://drive.google.com/file/d/15GksPiH0xmy4nRhylhMDIWmuvdHMWof4/view) also brought up their frustration at the way that technical debt can transform a seemingly simple task into a massive effort requiring them to rewrite or refactor a large chunk of code. More than the time spent on these tasks, several developers mentioned their concern that others might see them as dragging their feet and becoming a blocker when they take the time to resolve the technical debt. After all, it was just \"a simple task.\"\n\nThe responsibility to fix these issues becomes even more muddied when no particular team owns them. One [study of 95 teams in 25 leading corporations found that the majority of cross-functional teams are dysfunctional](https://hbr.org/2015/06/75-of-cross-functional-teams-are-dysfunctional), in large part because siloes self-perpetuate. The authors argue the solution is to create a “Portfolio Governance Team (PGT), where high-level leaders make complex decisions on the various projects in their portfolio together.\" The number one rule for making a PGT successful? \"Every project should have an end-to-end accountable leader.\"\n\n### The fix\n\nAlong these lines, one long-term solution being discussed at GitLab is establishing a dedicated team that will transcend the product areas and be responsible for these murky in-between issues. But Director of Engineering, Dev Backend [Tommy Morgan](/company/team/#itstommymorgan) adds, “Even if we had a team that was in place to handle issues like this one, there will always be boundary conditions. As Product is responsible for prioritizing work, if we need to do any horse-trading or other determination to figure out where the work should land, I think that's something that Product should work out.”\n\nShort of creating a new team, Product Managers and Engineering Managers will need to frankly discuss their own priorities and incentives in order to get these tasks scheduled.\n\nWhat has your org tried? Is it working? Tweet us [@gitlab](https://twitter.com/gitlab).\n\n[Photo](https://unsplash.com/photos/fIq0tET6llw) by [Diego PH](https://unsplash.com/@jdiegoph) on Unsplash.\n{: .note}\n",[9,695,934,912],{"slug":2657,"featured":6,"template":698},"how-do-we-handle-engineering-led-initiatives-that-dont-belong-to-one-team","content:en-us:blog:how-do-we-handle-engineering-led-initiatives-that-dont-belong-to-one-team.yml","How Do We Handle Engineering Led Initiatives That Dont Belong To One Team","en-us/blog/how-do-we-handle-engineering-led-initiatives-that-dont-belong-to-one-team.yml","en-us/blog/how-do-we-handle-engineering-led-initiatives-that-dont-belong-to-one-team",{"_path":2663,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2664,"content":2670,"config":2677,"_id":2679,"_type":13,"title":2680,"_source":15,"_file":2681,"_stem":2682,"_extension":18},"/en-us/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops",{"title":2665,"description":2666,"ogTitle":2665,"ogDescription":2666,"noIndex":6,"ogImage":2667,"ogUrl":2668,"ogSiteName":685,"ogType":686,"canonicalUrls":2668,"schema":2669},"Teams speed development with GitLab & Mattermost ChatOps","A complete DevOps toolchain plus open source messaging and ChatOps – what’s not to love?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680983/Blog/Hero%20Images/mattermost-gitlab.png","https://about.gitlab.com/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How enterprise dev teams use GitLab and Mattermost ChatOps to accelerate development\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Blais – Mattermost\"}],\n \"datePublished\": \"2020-01-13\",\n }",{"title":2671,"description":2666,"authors":2672,"heroImage":2667,"date":2674,"body":2675,"category":784,"tags":2676},"How enterprise dev teams use GitLab and Mattermost ChatOps to accelerate development",[2673],"Jason Blais – Mattermost","2020-01-13","\n\nThere has never been more pressure on development teams to build software faster and more efficiently. The rise in popularity of DevOps has largely been the result of its promise to speed up dev cycles, increase agility, and help teams resolve issues more quickly. And while the availability and sophistication of DevOps tools have improved greatly in the last few years, simply choosing the latest and greatest tools is no guarantee of a smooth, problem-free development lifecycle.\n\n## Why GitLab\n\nIn an ecosystem with exponentially increasing choice and complexity, GitLab provides a complete open source [DevOps platform](/solutions/devops-platform/) that can speed up cycles, reduce development costs, and improve developer efficiency. From planning and code to deployment and monitoring (and back again), GitLab brings a myriad of tools together into one open source toolset.\n\n## Why Mattermost ChatOps\n\nWe’re big fans of GitLab here at Mattermost, which is why Mattermost is packaged with GitLab Omnibus and why we work to make sure Mattermost is easy to [set up with GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc/gitlab-mattermost).\n\n[Mattermost’s open source ChatOps platform](https://mattermost.com/blog/introducing-mattermost-chatops/) allows you to surface relevant information to your team and enables you to take action directly where you’re having conversations. When an issue comes in, a ChatOps workflow can alert relevant team members, who all work together to make a fix directly within Mattermost.\n\nChatOps provides a method to interact with CI/CD jobs through messaging. Many organizations’ discussion, collaboration, and troubleshooting is taking place in messaging services these days, and having a method to run CI/CD jobs with output posted back to the channel can significantly accelerate a team’s workflow. ChatOps not only increases communication and collaboration, but a searchable history of the conversations associated with your development cycle increases transparency and creates a repository of valuable information for the team.\n\n## Mattermost + GitLab\n\nA complete DevOps toolchain plus open source messaging and ChatOps – what’s not to love? With GitLab and Mattermost, teams can not only simplify their DevOps process, but also bring their processes into the same chat interface where team members are discussing issues, collaborating, and making decisions.\n\nHere are a couple of examples of how development teams use Mattermost and GitLab together to accelerate developer productivity through ChatOps.\n\n### itk uses GitLab and Mattermost to ship more code on time and 6x production deployments per year\n\n[Itk](https://www.itk.fr/en/), based in Montpellier, France, develops tools and applications to help farmers optimize yields, increase the quality of crops, and manage risks more effectively.\n\nThey began using GitLab around 2014 and primarily used a legacy chat tool for day-to-day collaboration, messaging, and video calling. However, as the company grew, this tool didn’t scale with them; there was no persistent, easily searchable messaging, and collaboration across the team became more difficult. They began to look for an alternative.\n\nShortly thereafter, they discovered that the GitLab Omnibus package ships with an open source messaging platform for developers: Mattermost. They immediately fell in love with its easy code-sharing capabilities – including automatic syntax highlighting and full Markdown support, and the ease of sharing knowledge, searching past conversations, and collaborating on ideas across the team to develop new solutions all integrated together with GitLab.\n\nBefore switching to Mattermost, team members hadn’t been able to easily get notified about their development process. But they wanted to be able to visibly track projects, merge requests, and other activities from GitLab.\n\nThis is when Romain Maneschi, a software developer at itk, began writing a GitLab plugin for Mattermost that would further enable his team to subscribe to GitLab notifications in Mattermost and receive notifications about new issue assignments and review requests in one place.\n\nToday, [the plugin supports](https://github.com/mattermost/mattermost-plugin-gitlab):\n\n- **Daily reminders** – get informed on what issues and merge requests need your attention\n- **Notifications** – get notified in Mattermost when someone mentions you, requests your review, or assigns an issue to you on GitLab\n- **Sidebar buttons** – stay up-to-date with how many reviews, unread messages, assignments and open merge requests you have with buttons in the Mattermost sidebar\n- **Subscribe to projects** – use slash commands to subscribe a Mattermost channel to receive notifications of new merge requests or issues in a GitLab project\n\nNow, his whole company uses both GitLab and Mattermost to accelerate workflows through ChatOps. As a result, they now ship more code on time, resulting in 3x growth in the number of projects and microservices managed by the team and 6x growth in the number of production deployments within a year – all while growing their dev and agronomist teams by 5x.\n\n![GitLab Mattermost plugin](https://about.gitlab.com/images/blogimages/gitlab-mattermost-plugin.png){: .shadow.medium.center}\n\u003C!-- image: https://user-images.githubusercontent.com/13119842/70714554-5b52cc80-1cb6-11ea-9cd6-705a68f9ac1b.png -->\n\n### A software development company increases productivity through better transparency and visibility into code and configuration changes\n\nA software development and data services company based in the state of Maryland has also rolled out Mattermost integrated with GitLab to increase productivity and seamlessly collaborate. They provide analytics, data management, and software development services to biomedical researchers and organizations worldwide.\n\nGitLab is heavily used across their team and they consider it a huge asset in their DevOps workflows.\n\nThey have also integrated GitLab and Mattermost together by pushing GitLab commits to a single Mattermost channel via webhooks, enabling senior management to get a bird’s-eye view of everything that’s rolling through in a given day. It includes updates for configuration management and version control, giving a snapshot of different changes made to internal infrastructure and systems throughout the day.\n\nThe team has also set up separate “Heartbeat” channels to send notifications on application events. Having these messages funnel to specific Heartbeat channels avoids distracting the flow of conversations in regular project collaboration channels while empowering team members to jump on issues posted in the Heartbeat channels.\n\nOne of the key benefits this integration brings to the team is the visibility of changes made to versions and configuration management in real time; as soon as a change is committed and pushed live, a notification is sent to the Heartbeat channel which anyone can subscribe to. No more switching between apps, asking team members, or tracking down commits – it’s now all in one place inside Mattermost while configuration management and app development takes place in GitLab.\n\n### GitLab and Mattermost ChatOps improve transparency and productivity to accelerate development\n\nMattermost [ships as part of the GitLab Omnibus package](https://docs.gitlab.com/omnibus/gitlab-mattermost/), providing out-of-the box support for GitLab SSO, pre-packaged GitLab integrations, and PostgreSQL support, along with a Prometheus integration that enables systems monitoring and [incident response management](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#taking-action-on-incidents). Finally, Mattermost can now also be deployed [with GitLab Cloud Native](https://docs.mattermost.com/install/install-mmte-helm-gitlab-helm.html).\n\nThere’s never been a better time for DevOps teams to get the full benefits of open source ChatOps. Try it out by installing GitLab Omnibus with Mattermost today.",[9,232,787],{"slug":2678,"featured":6,"template":698},"how-enterprise-dev-teams-use-gitlab-mattermost-chatops","content:en-us:blog:how-enterprise-dev-teams-use-gitlab-mattermost-chatops.yml","How Enterprise Dev Teams Use Gitlab Mattermost Chatops","en-us/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops.yml","en-us/blog/how-enterprise-dev-teams-use-gitlab-mattermost-chatops",{"_path":2684,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2685,"content":2691,"config":2697,"_id":2699,"_type":13,"title":2700,"_source":15,"_file":2701,"_stem":2702,"_extension":18},"/en-us/blog/how-gitlab-empowers-translators-with-more-context",{"title":2686,"description":2687,"ogTitle":2686,"ogDescription":2687,"noIndex":6,"ogImage":2688,"ogUrl":2689,"ogSiteName":685,"ogType":686,"canonicalUrls":2689,"schema":2690},"How GitLab empowers translators with more context","Learn about the new translation context enhancement feature in GitLab. Join our translation community and help translate GitLab to your language.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab empowers translators with more context\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n \"datePublished\": \"2024-12-09\",\n }",{"title":2686,"description":2687,"authors":2692,"heroImage":2688,"date":2694,"body":2695,"category":784,"tags":2696},[2693],"Oleksandr Pysaryuk","2024-12-09","GitLab is continuously translated by our global community of translators and proofreaders. Through [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html), they help make our product more accessible to the world by translating it into 78 languages. GitLab translation community members are volunteer translators, working professionals who are GitLab users, and even [university students contributing to translators as part of their classroom projects](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### How the GitLab open-core model supports translators\n\nWhile this community collaboration is powerful, translators often face a crucial challenge: understanding the full context of the text that they are translating.\n\nGreat translation isn't just about converting words – it's about preserving meaning, intent, and usability in a target language. Software translation requires a unique blend of skills. Great translators usually specialize in multiple linguistic domains as well as the technical domain of the product itself. They perform myriad translation-adjacent tasks such as:\n\n* ensuring accuracy and consistency of technical terminology\n* creating new glossary terms for new concepts\n* adhering to the style and tone\n* navigating the complexity of [CLDR pluralization rules](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html)\n* understanding the translatability of composite messages and how to provide feedback to improve the source by making it localizable\n\nTranslators spend lots of time researching context, asking questions, and reading [GitLab product documentation](https://docs.gitlab.com/). Without proper context, even simple phrases can be mistranslated, potentially confusing or disrupting user workflows. What sets [GitLab apart is its open-core model](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/), which allows translators to access most of the product development context directly at the source. This transparency empowers them to actively contribute as true [co-creators of the GitLab global product](https://handbook.gitlab.com/handbook/company/mission/#mission).\n\n### Introducing our new context-enhancement feature\n\nTo support these needs and empower translators with context, GitLab has developed a new feature: we now [embed into each translatable string a contextual link](https://docs.gitlab.com/ee/development/i18n/translation.html#context) (more specifically, a link to our global in-product search) that lets translators locate all instances of that string in the codebase. These links allow translators to rely on [Git blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) to trace every string's history – from its current location in code, through commits in merge requests, and all the way up to the original planning discussions.\n\nFor example, when you are translating **Rotate**, the **AccessTokens|** [namespace](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) suggests that the context is, well, *access tokens*. However, there is no additional visual context for what **Rotate** means, and translators are left to wonder, guess, and provide the best possible assumption in a target language.\n\nWith the new context enhancement, here is what translators are now able to do:\n\n1. Click the URL in the **See where this string is used in code** section.\n\n![see where this string is used in code section](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Review the [result of the code search](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29®ex=true), and click the **View blame** icon:\n\n![Screen with View blame icon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Follow the link with the relevant merge request ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)):\n\n![Link with relevant merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. On the **Commits** page, follow the link to the actual merge request:\n\n![Commits page with link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Watch the screen recording that the software engineer added to the merge request:\n\n![screen recording in merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Research even further by going to:\n a. The linked issue [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) or its parent epic [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563):\n\n![linked issue and parent epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. The [related merge request that updates the GitLab product documentation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916):\n\n![related merge request to update GitLab product documentation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nAll these research steps will lead translators to better understand the technical concept of *access token rotation* and why the token rotation functionality was added, how it works, and what problem it solves for users.\n\nWith this rich research trail, translators get the maximum amount of context that will help provide the technically accurate and linguistically correct translation for the seemingly simple word **Rotate**.\n\nThis approach goes far beyond traditional translation aids like providing screenshots or exploring the product user interface. Translators can now fully understand the context by:\n\n* deriving context from paths and naming conventions used in code\n* viewing screenshots or video recordings that are added to original merge requests\n* reading original planning and development discussions\n* following the engineering, copywriting, and product management decision-making process that has led to specific wording\n\n### More AI-powered contextual features coming up\n\nThe GitLab Localization team isn't stopping here. We are working on [more context-enhancement features](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), including AI-powered tools to help translators understand string usage and placement. Imagine a system where translators could interact with an agent by asking questions or proactively receiving immediate code-aware responses about where and how strings are used in the product UI.\n\n> ### Join our [community on Crowdin](https://docs.gitlab.com/ee/development/i18n/) as a translator or a [proofreader](https://docs.gitlab.com/ee/development/i18n/#proofreading), try these new context features, and let us know how we can make the [translation experience and our product even better](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[268,9,1388,1285],{"slug":2698,"featured":6,"template":698},"how-gitlab-empowers-translators-with-more-context","content:en-us:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","en-us/blog/how-gitlab-empowers-translators-with-more-context.yml","en-us/blog/how-gitlab-empowers-translators-with-more-context",{"_path":2704,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2705,"content":2711,"config":2715,"_id":2717,"_type":13,"title":2718,"_source":15,"_file":2719,"_stem":2720,"_extension":18},"/en-us/blog/how-gitlab-handles-retrospectives",{"title":2706,"description":2707,"ogTitle":2706,"ogDescription":2707,"noIndex":6,"ogImage":2708,"ogUrl":2709,"ogSiteName":685,"ogType":686,"canonicalUrls":2709,"schema":2710},"How GitLab handles retrospectives","Take a peek at how the GitLab team holds monthly retrospectives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668426/Blog/Hero%20Images/retrospectivesgitlabpost.jpg","https://about.gitlab.com/blog/how-gitlab-handles-retrospectives","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab handles retrospectives\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-12-19\",\n }",{"title":2706,"description":2707,"authors":2712,"heroImage":2708,"date":2087,"body":2713,"category":300,"tags":2714},[951],"\nEach month, GitLab’s engineering team hold a retrospective to learn and improve as much as possible from [every monthly release](/releases/). Retrospectives are the preferred method for GitLab team members [focused on improvement](https://handbook.gitlab.com/handbook/values/#focus-on-improvement) and ensures that our technical debt doesn’t grow faster than our code base.\n\n> “When we say retrospective, here’s what we have in mind: A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and gener-ate action. Retrospectives go beyond checklist project audits or per-functory project closeouts. And, in contrast to traditional post-mortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues – if not more so.” — [Agile retrospectives: Making good teams great](https://www.amazon.com/Agile-Retrospectives-Making-Pragmatic-Programmers-ebook/dp/B00B03SRJW)\n\nSince retrospectives can cultivate a culture of transparency, trust, collaboration, and communication, we want to share the steps our team takes in order to ship every month.\n\n## Engineering-wide retrospectives\n\nIn line with our [value of transparency](https://handbook.gitlab.com/handbook/values/#transparency), we livestream the meetings to YouTube and monitor the chat for questions from viewers. We also have a publicly available document for [retrospective notes](https://docs.google.com/document/d/1nEkM_7Dj4bT21GJy0Ut3By76FZqCfLBmFQNVThmW2TY/edit?usp=sharing) so that we can [efficiently refer back to decisions, insight, and comments](https://handbook.gitlab.com/handbook/values/#write-things-down).\n\nIn each retrospective, the team methodically works through the same discussion points:\n\n1. **Previous retrospective improvement tasks**: The moderator reviews the improvements the team identified in the last retrospective and discuss progress on those items.\n1. **What went well this month**: Teams are encouraged to celebrate the ways in which we exceeded expectations either individually or as a team.\n1. **What went wrong this month**: Teams are encouraged to identify mistakes and unmet goals. The focus is to highlight areas that didn’t meet our expectations as a team.\n1. **How we can improve**: The team engages in [blameless problem solving](https://handbook.gitlab.com/handbook/values/#blameless-problem-solving) to identify how subsequent releases can improve. Are there changes we can make in workflow? Is there a potential silo forming? Do changes need to be made in communication and collaboration?\n1. **Improvements for next release to track**: At the end of each retrospective, the [Engineering Productivity team](/handbook/engineering/quality/#engineering-productivity) triages improvement items identified during the retrospective. Having a single owner of triaging enables the awareness of the bigger picture technical debt and backstage work required. The individuals issues are assigned to other teams or engineers to execute.\n\nRetrospectives are publicly live streamed each month. Take a look at the retrospective for 12.5. 🍿\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/tkwo9xisg90\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Team retrospectives\n\n[Team retrospectives](/handbook/engineering/management/group-retrospectives/) are held to inform the function-wide retrospective for any given release. [Sean McGivern](/company/team/#smcgivern), engineering manager, Plan:Project Management, wrote a [great article on using GitLab CI to automate monthly releases](/blog/how-we-used-gitlab-to-automate-our-monthly-retrospectives/). Using scheduled pipelines to create an issue early in the release cycle, teams can contribute to the retro issue while they’re still working on the release.\n\n> “It doesn’t matter whether you have four or five labels of things on your retro board, or exactly how you do the retro. What does matter is the notion of thinking about what we're doing and how we can do better, and it is the team that’s doing the work that does this, that is the central thing.” — [Martin Fowler](https://martinfowler.com/articles/agile-aus-2018.html)\n\nIn this [team retrospective issue](https://gitlab.com/gl-retrospectives/create-stage/editor/issues/6), the Create:Editor team takes a look at what went well, what didn’t go well, what can be improved, which issues shipped, and which issues slipped in the [12.5 release](/blog/gitlab-12-5-released). In team retro issues, individuals can gauge how others experienced the release and discuss points raised by teammates.\n\nHere’s a video of the [Plan team](https://handbook.gitlab.com/handbook/product/categories/#plan-stage) holding a retrospective to discuss recent slipped issues. 🍿\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/QA3LlJOi0Ik\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Asynchronous retrospectives\n\nSince GitLab is an [all-remote company](/company/culture/all-remote/), we strongly encourage [asynchronous communication](https://handbook.gitlab.com/handbook/communication/#internal-communication), since team members can be located in any of the [65 countries](/company/team/) where GitLab team members live. We apply asynchronous communication to our retrospectives to ensure that everyone can contribute and document their experiences.\n\nAsynchronous retrospectives are not just for remote teams. They can also be used by colocated teams to facilitate open discussion when team members have the bandwidth to dedicate to problem solving. Furthermore, asynch retros can serve as a dedicated place where people can quickly jot down their thoughts when they suddenly remember an experience, rather than be forced to remember everything during a dedicated call.\n\n## Retrospectives: The impact on culture\n\n[When retrospectives are run efficiently](/handbook/engineering/management/group-retrospectives/), these meetings can build mutual trust, communication, and collaboration. They cultivate a culture of continuous learning and improvement, two characteristics of any strong Agile team. The more teams can determine how to efficiently build software, the more value they can bring to users.\n\nCover image by [Shane Aldendorff](https://unsplash.com/@pluyar?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/mQHEgroKw2k).\n{: .note}\n",[891,9,912],{"slug":2716,"featured":6,"template":698},"how-gitlab-handles-retrospectives","content:en-us:blog:how-gitlab-handles-retrospectives.yml","How Gitlab Handles Retrospectives","en-us/blog/how-gitlab-handles-retrospectives.yml","en-us/blog/how-gitlab-handles-retrospectives",{"_path":2722,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2723,"content":2729,"config":2735,"_id":2737,"_type":13,"title":2738,"_source":15,"_file":2739,"_stem":2740,"_extension":18},"/en-us/blog/how-gitlab-protects-your-ip",{"title":2724,"description":2725,"ogTitle":2724,"ogDescription":2725,"noIndex":6,"ogImage":2726,"ogUrl":2727,"ogSiteName":685,"ogType":686,"canonicalUrls":2727,"schema":2728},"How GitLab protects your IP","There are many ways in which hosting intellectual property in GitLab is not only secure but also flexible and invites collaboration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667110/Blog/Hero%20Images/how-gitlab-protects-your-ip.jpg","https://about.gitlab.com/blog/how-gitlab-protects-your-ip","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab protects your IP\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jordi Mon\"}],\n \"datePublished\": \"2020-08-07\",\n }",{"title":2724,"description":2725,"authors":2730,"heroImage":2726,"date":2732,"body":2733,"category":1053,"tags":2734},[2731],"Jordi Mon","2020-08-07","\n## How safe is your IP?\n\nOne of the main assets of any company is stored in the shape of code. The originality of the code makes it intellectual property, and thus companies would like it to be protected. But storing it safely away from others will hinder the same effort that brought it to life: Collaboration. So how can companies keep their IP safe while allowing their employees to work on its maintenance and development?\n\nGitLab repos, whether hosted online or privately, store one of the most valuable things your company is able to create: The digital assets used to build software products and services. GitLab is designed to make versioning and the collaboration over those assets as seamless and productive as possible.\n\nAlbeit that, is GitLab a safe place to store such valuable assets?\n\nLet's explore user access within GitLab and to what extent these users can access your company's IP.\n\n## Ways to access GitLab\n\n### LDAP, active directory, SAML, SSO\n\nFor the self-managed solution, GitLab is able to connect to any Lightweight Direct Access Portal (LDAP) service that is already set up and validate which users have access permissions. Users that access GitLab instances with LDAP on will have access only to the groups and projects assigned to them. The same is applicable to active directory.\n\nIf you are using GitLab.com, Security Assertion Markup Language (SAML) technology will mostly do the same described above. System for Cross-domain Identity Management (SCIM), the open standards running beneath SAML, is currently supported for Okta and and Azure but it will have broader support in the future. For example, check single sign-on (SSO) for enterprises or the general direction of this category.\n\n## How users are organized in GitLab\n\nAssigning roles with permissions is an easy way to know which user will be able to access and make changes to the IP.\n\nThere are six roles:\n\n| Guest | Auditor | Developer | Reporter | Maintainer | Owner |\n|:--|:--|:--|:--|:--|:--|\n| | | | | | |\n\nBy default all users have the following permissions in a project:\n\n* Create issues\n* Leave comments\n* Clone or download the project code\n\nBut these are the specific definitions for each user role:\n\n1. **Guests** are not active contributors in private projects. They can only view, and leave comments on issues.\n1. **Auditors** are given read-only access to all projects, groups, and other resources on the GitLab instance.\n2. **Reporters** are read-only contributors: They can't write to the repository, but can write on issues.\n3. **Developers** are direct contributors, and have access to everything to go from idea to production, unless something has been explicitly restricted (e.g., through branch protection).\n4. **Maintainers** are super-developers: They can push to main (master) and deploy to production. This role is often held by maintainers and engineering managers.\n\nSo what's happening at the project level? Well, the meat of it: Collecting requirements, defining user stories, prune and groom backlog, and merge requests are popping up like branches. It is at the project level where these four roles interact. But they don't do it only with the permissions their role provides them. There are other features at this level that can stop them or enable them to do certain things that will allow the project owners to parcel and control who's doing what to the IP hosted in the repo. Let's look at these features.\n\n## Where is my IP stored?\n\nIntellectual property is stored in repos, projects, and groups. Let's first step back and explain what the structure of these elements in GitLab looks like. Once we have a clear understanding of what and where information is stored, we can then jump to explaining who can access what information.\n\n### Repos\n\nA repo is a folder that lives either on your machine or on GitLab.com. It is what Git tracks every time you add and commit a change. It hosts your code and all the branches.\n\n### Projects\n\nRepos are the core part of every project. This is where GitLab's core [version control and collaboration](/topics/version-control/) capabilities shine. GitLab has project management features such as epics, subepics and issues, Wikis, GitLab pages, a Web IDE and many more features that make the repo the central part of a fully-featured source code workflow.\n\n### Groups\n\nGroups are a collection of projects. Members of groups with permissions will keep those permissions on every project included in the Group.\n\n5. Admin-only features can only be found in /admin. Outside of that, admins are the same as the highest possible permission (owner).\n6. Owners are essentially group-admins. They can give access to groups and have destructive capabilities.\n\nWatch the video below for a deep dive into repos, projects, and groups.\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube-nocookie.com/embed/4TWfh1aKHHw\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n## How is my IP protected?\n\n### Protected branches\n\n[Protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html) are a simple method to keep IP protected. But if copies can be made, protected branches control who has access to those copies and for what purpose those copies are created.\n\n* Protect branches (PB) prevents everybody except users with *maintainer* permission from creating them.\n* PB prevents pushes from everybody except users with *allowed* permission.\n* PB prevents anyone from force pushing to the branch.\n* PB prevents anyone from deleting the branch.\n\nThese settings allow maintainers to forbid all pushes but allow incoming merges from developers. This forces every developer willing to make changes to the PB to open an MR. This exposes the changes he or she wants to commit and makes them subject to other security measures we will cover later, like push rules or MR approvals.\n\nAlso, pipeline security is a consequence of protected branches and you can read more about it [here](https://docs.gitlab.com/ee/user/project/repository/push_rules.html).\n\n### Protected tags\n\nAdding [protected tags](https://docs.gitlab.com/ee/user/project/protected_tags.html) to your repo is like bookmarking it in a way. The ability to label commits allows you to add details and context to what is happening at that point in time.\nIf a tag becomes an important milestone for the project you might as well protect it, right? That's is why only *maintainers* are allowed to create tags and, if protected, no one apart from them will be able to delete or modify them.\n\n### Push rules\n\nWe use [push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) at GitLab which prevents the majority of contributors from pushing directly to the main branch. We use GitLab Flow because we want to make small batch changes fast but also because we want to collaborate with our team members. A merge request flow like GitLab Flow does not push code to the main branch. This behavior, however, can be very common when working with Git.\nSo, push rules will use regular expression to scan commit messages, branch names or file details to prevent pushes from happening. These rules are usually used to enforce consistency throughout pushes. They allow teams to stay compliant with naming conventions, for example, or keep pushes linked to specific requirements by parsing for issue numbers. Non-GPG signed pushes can be automatically rejected with this feature too.\nThe possibilities are endless since push rules can be [customized](https://docs.gitlab.com/ee/development/changelog.html). Learn [here](https://docs.gitlab.com/ee/push_rules/push_rules.html#enabling-push-rules) what push rules are available on each tier.\n\n### Merge request approvals\n\nA merge request (MR) is a branch and the start to a conversation. When you open an MR you have effectively created a copy of the main branch hosted in the repo so you can make changes. Since the main branch is the IP's most valuable asset, all changes made in the opened MR [should require some extra sets of eyes on them](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/). When this feature is set it enforces code review. Does this imply that all changes will be reviewed by all team members? No, this feature can be customized in many ways.\n\nFirst, you can set approval rules that define how many approvals are required for the code change to be merged. You can even designate specific approvers, such as team lead. Designating approvers can be done in each MR or at the project level. If you know the MR may only affect the backend of the project, you might specify reviewer categories such as backend or database, QA and so on.\n\nOne special category is security. GitLab considers the [DevSecOps](/topics/devsecops/) use case as one of the fundamental trends in software development and is committed to provide the best security capabilities to software engineering teams.\nAmong other things, the ability to shift security checks left allows devs to run static code analysis at the rest level, and there is a [specific MR approval](/solutions/security-compliance/) that will prevent any MR from moving forward if certain security criteria are not met.\nTypically, these SASTs will look for security vulnerabilities and license compliance violations. Security teams can address problems that otherwise would have compounded by setting approvals to trigger when vulnerabilities or license violations are detected. DevSecOps with GitLab will automate security and compliance workflows to create an adaptable process for your development and security teams to work faster and better together.\n\n### Code owners\n\nThe code owners feature assigns ownership of files or paths to a certain group or user. Generally, this measure will allow the MR creator to determine who is the main stakeholder of certain files. Assigning code ownership fosters collaborative behaviors from users, such as asking for permission to merge or just requesting guidance. It becomes especially useful if the question for the code owner is unrelated to a code review or a MR approval.\nCode owners can become approvers of MRs if set to do so in an approval rule. Combining code ownership with protected branches is a good way to get more granular control over certain files and the changes applied on them.\n\n## How can I trace access and changes to my IP?\n\n### Audit events\n\nThe final method for controlling the security of your IP is by monitoring user activity. As in any other project management tool, users can access information in GitLab in many different ways and can interact with that information on multiple levels. The admin should be able to control events and stop those that do not comply with corporate policy. Access control and audit trails can provide increased layers of security and traceability that will improve your IP storage compliance.\n\n## How does this all work out for me?\n\nWell, you can follow the example of Northwestern Mutual. They manage permissions as code by dedicating a complete repo to host and manage their groups, teams, and deploy keys. Meaning, when a team wants to create a project that requires new roles, new access permissions, protected branches, etc., they’ll create an MR in the repo and submit those changes to the code owner for approval. Remember, in GitLab a MR is more than just a branch, it's also the start to a conversation, or even a proposed code change. This proposal particularly would imply changes in a yaml file that contain all admin level permissions.\n\nWatch the Northwestern Mutual team describe this in detail at GitLab Commit Brooklyn 2019:\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube-nocookie.com/embed/W1YMBc6kwUE\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\nCover image by [Jon Moore](https://unsplash.com/@thejmoore) on [Unsplash](https://unsplash.com/photos/bBavss4ZQcA)\n{: .note}\n",[807,9],{"slug":2736,"featured":6,"template":698},"how-gitlab-protects-your-ip","content:en-us:blog:how-gitlab-protects-your-ip.yml","How Gitlab Protects Your Ip","en-us/blog/how-gitlab-protects-your-ip.yml","en-us/blog/how-gitlab-protects-your-ip",{"_path":2742,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2743,"content":2748,"config":2754,"_id":2756,"_type":13,"title":2757,"_source":15,"_file":2758,"_stem":2759,"_extension":18},"/en-us/blog/how-gitlab-uses-third-party-security-ratings-to-build-customer-confidence",{"title":2744,"description":2745,"ogTitle":2744,"ogDescription":2745,"noIndex":6,"ogImage":1131,"ogUrl":2746,"ogSiteName":685,"ogType":686,"canonicalUrls":2746,"schema":2747},"How GitLab uses Third Party Security Rating to Build Customer Confidence","This blog is about how GitLab manages Third Party Security Rating platforms, why we chose to partner with BitSight, and how we are using BitSight’s external validation to increase customer confidence.","https://about.gitlab.com/blog/how-gitlab-uses-third-party-security-ratings-to-build-customer-confidence","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab uses Third Party Security Rating to Build Customer Confidence\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Meghan Maneval\"}],\n \"datePublished\": \"2020-12-18\",\n }",{"title":2744,"description":2745,"authors":2749,"heroImage":1131,"date":2751,"body":2752,"category":716,"tags":2753},[2750],"Meghan Maneval","2020-12-18","In today’s security world, it isn’t enough to **say** your product is secure, Customers and Prospects want you to **prove it**. GitLab understands how critical security is when making purchasing decisions and recognizes that many utilize results from Third Party Security Ratings platforms as a deciding factor. While these services can be extremely helpful, there is also the potential for inaccurate information to be presented as evidence on a company’s behalf, especially for a company like GitLab. That’s why GitLab aligned with [BitSight](https://www.bitsight.com/), a leading provider of Third Party Security ratings and loyal GitLab customer, with a mutual goal of removing misappropriated information, improving GitLab’s security rating, and building confidence in our security posture for our Customers and Prospects. Here’s how we did it. \n\n## The Downside to Third Party Ratings\n\nThird Party Security ratings are a great way to independently validate a company’s security. However, without proper diligence and review, ratings can be presented inaccurately. This was especially true in GitLab’s case. GitLab maintains multiple environments to properly segment our development and testing activities from our production environment. Within these non-production environments it is common to have older infrastructure or operating systems for backwards compatibility testing. However, with many Third Party Security Rating platforms, non-production environments are lumped together with production. Additionally, due to GitLabs dynamic nature, our team members often create infrastructure for testing, register the IP address, and then remove the infrastructure within a short period of time. This can lead to IP addresses that are no longer utilized by GitLab to be included in the ratings. Both of these resulted in a deceptively lower score on multiple Third Party Security Ratings platforms that were not accurately reflecting GitLab’s security posture. \n\n## Improving GitLab’s BitSight Rating\n\n![Third Party Ratings Workflow](https://about.gitlab.com/images/blogimages/third_party_ratings.png)\n\nIn **August 2020,** GitLab's BitSight rating was 530 (on a scale of 250-900) with documented vulnerabilities related to Compromised Systems and Application Security. \n\nWe began by validating our Digital Footprint - a list of IP addresses and domains that public DNS records associated with GitLab. By reviewing this list first, we were able to identify IPs that were no longer associated with GitLab and request they be removed. This increased our score. \n\nNext, we created Environment tags and created 3 custom ratings for Production, Pre-Production, and User Managed IPs. This allowed us to “remove” findings associated with non-production (non-customer impacting) IPs. This increased our score significantly. \n\nWith a narrowed down list of targeted findings, we reviewed the findings and associated infrastructure and took action. By the end of **September 2020** GitLab's BitSight rating was a 780 (on a scale of 250-900). \n\nA critical step in our success was the implementation of a Third Party Security Rating process for identifying new findings, managing our score, and tracking observations through remediation. This included utilizing BitSight’s built in functionality for score monitoring and alerting as well as regular auditing of the Digital Footprint and Observation Management procedures to track resolution of identified findings. To see our Monthly Summary Report, visit our [Customer Assurance Package](/security/cap/).\n\n## Partnering with BitSight\nWe began this process by conducting research into some of the most common Third Party Security Ratings platforms and understanding how each sourced their information, validated their information, and assigned ratings to identified findings. This allowed us to identify the platform that best suited our needs and focus on improving that rating specifically. \n\nFor GitLab, it was critical that the platform has:\n* Alerting and visibility when our rating changes\n* Re-scan options for remediated findings\n* Ability to remove IPs/Domains that aren’t ours\n* Individual reports or ratings for different environments (ie- production vs non-production)\n* Integrations/APIs for ingestion of data into our monitoring tools\n* Alerting and Visibility when our third parties or competitor’s ratings changes\n* Simple and clear factors and scoring\n* Sufficient detail about the finding to validate and remediate\n\nIn the end we decided we would move forward with BitSight due to their simple and transparent factors and scoring, the ability to segment out different environments, and their ability to support multiple GitLab use cases. And while we recognize that there are many other ratings platforms out there, GitLab is committing to a collaborative partnership with BitSight to maintain a simple and transparent security rating that we all can be proud of. You can read more about our Third Party Security rating process and view our latest ratings reports in GitLab’s [Customer Assurance Package](/security/cap/).\n",[807,9],{"slug":2755,"featured":6,"template":698},"how-gitlab-uses-third-party-security-ratings-to-build-customer-confidence","content:en-us:blog:how-gitlab-uses-third-party-security-ratings-to-build-customer-confidence.yml","How Gitlab Uses Third Party Security Ratings To Build Customer Confidence","en-us/blog/how-gitlab-uses-third-party-security-ratings-to-build-customer-confidence.yml","en-us/blog/how-gitlab-uses-third-party-security-ratings-to-build-customer-confidence",{"_path":2761,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2762,"content":2768,"config":2774,"_id":2776,"_type":13,"title":2777,"_source":15,"_file":2778,"_stem":2779,"_extension":18},"/en-us/blog/how-the-dora-metrics-can-help-devops-team-performance",{"title":2763,"description":2764,"ogTitle":2763,"ogDescription":2764,"noIndex":6,"ogImage":2765,"ogUrl":2766,"ogSiteName":685,"ogType":686,"canonicalUrls":2766,"schema":2767},"How the DORA metrics can help DevOps team performance ","The best DevOps teams measure their results. Here's a deep dive into the DORA metrics that matter.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676702/Blog/Hero%20Images/data.jpg","https://about.gitlab.com/blog/how-the-dora-metrics-can-help-devops-team-performance","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How the DORA metrics can help DevOps team performance \",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aathira Nair\"}],\n \"datePublished\": \"2022-04-20\",\n }",{"title":2763,"description":2764,"authors":2769,"heroImage":2765,"date":2771,"body":2772,"category":757,"tags":2773},[2770],"Aathira Nair","2022-04-20","\n\n_Accelerated adoption of the cloud requires tools that aid in faster software delivery and performance measurements. Delivering visibility across the value chain, the DORA metrics streamline alignment with business objectives, drive software velocity, and promote a collaborative culture._ \n\nSoftware delivery, operational efficiency, quality - there is no shortage of challenges around digital transformation for business leaders. \n\nCustomer satisfaction, a prominent business KPI, has paved the way for experimentation and faster analysis resulting in an increased volume of change in the software development lifecycle (SDLC). Leaders worldwide are helping drive this culture of innovation aligned with organization goals and objectives. However, it is not always about driving the culture alone; it is also about collaboration, visibility, velocity, and quality. \n\nCloud computing and microservices are driving the cloud-first approach for software delivery, helping to scale them independently, and allowing teams to move faster. But, without DevOps, the team doesn’t have the underlying core to move fast efficiently. DevOps has the power to enable the smallest changes that can have great effects. \n\nThis brings us to the question - how do you measure velocity and impact? Or how do you assess quality, and ensure that it is not hampered by velocity? The latter would be what is commonly referred to as technical debt.\n\n## A continuous journey needs continuous improvement\n\nAny improvement starts with measurement. Measuring and optimizing DevOps practices improves developer efficiency, overall team performance, and business outcomes. DevOps metrics demonstrate effectiveness, shaping a culture of innovation and ultimately overall digital transformation. In the [Accelerate State of DevOps 2021](https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report) report by the DevOps Research and Assessment (DORA) team at Google Cloud, which draws insights from 7 years of data collection and research, four metrics are the key to measure software delivery performance.\n\n## What are these metrics?\n\n- Deployment Frequency\n- Lead time for changes\n- Time to restore service\n- Change failure rate\n\n### Deployment Frequency\n\nLet’s start with the velocity of development. Deployment frequency measures how often the organization deploys code to production or releases it to end users. This metric borrows from lean manufacturing concepts, wherein small multiple batch sizes are the preferred approach for higher efficiency and more rapid adjustments.\n\n### Lead time for changes\n\nNow comes the extent of automation in your processes. Lead time for changes measures the time needed to take a committed code to successfully run in production. This is one of the two metrics with significant variance in the data. \n\n### Time to restore service\n\nThis represents a business' capacity. Time to restore service measures the time needed to restore services to the level they were previously, in case of an incident. Here too we see significant variance in the data.\n\n### Change failure rate\n\nAnd finally, we take a look at quality. Changes which cause a failure in the system – a deployment failure, an incident, a rollback or a remedy – all contribute to measuring the change failure rate. \n\n## Driving visibility into the DevOps lifecycle\n\nRecently, Zoopla used DORA metrics to boost deployments and increase automation. Understanding the root cause of their problems helped them make informed adjustments in their process workflows, automation, tools, and more. They recognized the value of using a single platform to overcome roadblocks in velocity and innovation. This brought added visibility into their system which helped improve measurement and analytics. \n\nOur [2021 Global DevSecOps Survey](/developer-survey/) shows engineers are happier when they can focus on innovation and adding value than when maintaining integrations. In fact they would rather focus on higher quality documentation which can further amplify results of investments in DevOps capabilities. Documentation and visibility together drives team performance and competitive advantage. \n\nVisibility driven through [DORA metrics](https://docs.gitlab.com/ee/user/analytics/#supported-dora-metrics-in-gitlab) can uncover bottlenecks such as a dysfunction in code review, allowing management to identify causes of slowdowns in the DevOps lifecycle, and enable engineering leaders to align with business priorities. This delivers continuous improvement and progress towards business goals, promoting a collaborative culture across the organization.\n\nThe team at Zoopla used the GitLab DevOps platform to obtain metrics for deploy frequency, lead time, change fail rate, and time to onboard. \n\nimage_title: ![VSA-DORA](https://about.gitlab.com/images/blogimages/VSA-DORA.png)\n\nThe metrics helped influenced decision making and prioritization at Zoopla. Teams were encouraged to learn from the metrics, and incorporate changes into their planning cycles to keep on the path of continuous improvement. They were successful in measuring improvements and building an efficient engineering team that was flexible in responding to business needs. \n\n[Read more on [how Zoopla used DORA metrics for continuous improvement](/blog/how-zoopla-uses-dora-metrics-and-your-team-can-too/) and the [DORA metrics API in GitLab](https://docs.gitlab.com/ee/api/dora/metrics.html#devops-research-and-assessment-dora-key-metrics-api)]\n",[695,737,9],{"slug":2775,"featured":6,"template":698},"how-the-dora-metrics-can-help-devops-team-performance","content:en-us:blog:how-the-dora-metrics-can-help-devops-team-performance.yml","How The Dora Metrics Can Help Devops Team Performance","en-us/blog/how-the-dora-metrics-can-help-devops-team-performance.yml","en-us/blog/how-the-dora-metrics-can-help-devops-team-performance",{"_path":2781,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2782,"content":2788,"config":2793,"_id":2795,"_type":13,"title":2796,"_source":15,"_file":2797,"_stem":2798,"_extension":18},"/en-us/blog/how-to-ask-smarter-devops-questions",{"title":2783,"description":2784,"ogTitle":2783,"ogDescription":2784,"noIndex":6,"ogImage":2785,"ogUrl":2786,"ogSiteName":685,"ogType":686,"canonicalUrls":2786,"schema":2787},"How to ask smarter DevOps questions","Take your DevOps practice to the next level by asking 10 critical questions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667845/Blog/Hero%20Images/gl15.jpg","https://about.gitlab.com/blog/how-to-ask-smarter-devops-questions","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to ask smarter DevOps questions\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-06-22\",\n }",{"title":2783,"description":2784,"authors":2789,"heroImage":2785,"date":2790,"body":2791,"category":757,"tags":2792},[846],"2022-06-22","\n\nGitLab has [surveyed DevOps practitioners](/developer-survey/) for more than five years now. In that time, we have come to know what questions to ask to understand how well teams are doing with DevOps. In sharing these 10 questions, we aim to help you assess your own team’s capabilities and achieve smarter, faster DevOps.\n\n### How fast is your team releasing code today vs. one year ago?\n\nTracking release speed is like taking the temperature of your DevOps team. You’d like to think everything is going well, but you might be surprised. Occasionally DevOps teams report to us they are actually releasing code more slowly than in the past. \n\n### What stage(s) in the process are causing the most release delays?\n\nThis question will shine a spotlight on the areas in your DevOps practice that simply don’t work. Spoiler alert: The answer [will certainly be testing](/blog/the-software-testing-life-cycle-in-2021-a-more-upbeat-outlook/), though other things, from planning to code development and code review, might pop up, too.\n\n### How automated is your DevOps process?\n\nAsk this, but don’t just focus on testing, tempting as that might be. Also think about what else in the software development lifecycle would [benefit from automation](/blog/cd-automated-integrated/). Consider what getting that time back would afford you. Could you assign your developers and ops pros to other business-critical projects?\n\n### What’s been added to your DevOps tech stack over the last year?\n\nIt’s good to look back and take inventory of the technology you have in play. This is also data that can help inform what your next steps might be, such as adopting [GitOps](/topics/gitops/), [observability](/blog/observability-vs-monitoring-in-devops/), or [AI](https://www.youtube.com/watch?v=C08QVI99JLo).\n\n### How are your DevOps roles changing?\n\nIf your team is like others we’ve heard from, (big) changes are happening. Devs are picking up tasks that have traditionally been owned by ops, ops is becoming anything from a DevOps coach to a [platform engineer](/topics/devops/what-is-a-devops-platform-engineer/) or a cloud expert, and security is likely now embedded in development teams.\n\n### How does security integrate with DevOps in your organization?\n\nThe most successful DevOps teams have figured out how to [bridge the dev and sec divide](/blog/developer-security-divide/). Whether your team has a [security champion](/blog/why-security-champions/) or actually embeds sec pros on the dev team, this is a critical piece in the process to release safer software faster.\n\n### What advanced technologies are you using (or considering) in your DevOps practice?\n\n“Bots” can test code, [AI can review code](/blog/ai-in-software-development/), and a [low code/no code tool](/blog/low-code-no-code/) will make [citizen developers](https://www.gartner.com/en/information-technology/glossary/citizen-developer) out of anyone in the organization. Now is definitely the time to make sure your DevOps team is future-proofing the tech stack.\n\n### Do you have a plan for governance and compliance of your software supply chain?\n\nTo keep the [software supply chain secure](/blog/elite-team-strategies-to-secure-software-supply-chains/), DevOps teams need visibility into and control over the entire development lifecycle. Can you easily deal with audits or attestations of compliance? Mature governance and compliance processes are essential in all industries today, not just those that are highly regulated.\n\n### What advanced practices are you using (or considering) in your DevOps environment?\n\nWhether it’s [Infrastructure as Code (IaC)](/topics/gitops/infrastructure-as-code/), GitOps, or [MLOps](/blog/introducing-modelops-to-solve-data-science-challenges/), cutting-edge practices can jumpstart your releases and bring new and interesting opportunities to DevOps teams.\n\n### Do you regularly assess DevOps careers and roles on your team?\n\nHappy team members [really are more productive](/blog/why-software-developer-job-satisfaction-matters-and-how-to-make-it-happen/), so consider this a PSA to keep career growth conversations a priority. \n\nIn considering these 10 questions, your team will gain a fuller picture of your DevOps capabilities and how to address the technology and talent gaps you have identified.\n\n",[695,829,9],{"slug":2794,"featured":6,"template":698},"how-to-ask-smarter-devops-questions","content:en-us:blog:how-to-ask-smarter-devops-questions.yml","How To Ask Smarter Devops Questions","en-us/blog/how-to-ask-smarter-devops-questions.yml","en-us/blog/how-to-ask-smarter-devops-questions",{"_path":2800,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2801,"content":2807,"config":2813,"_id":2815,"_type":13,"title":2816,"_source":15,"_file":2817,"_stem":2818,"_extension":18},"/en-us/blog/how-to-build-out-your-devops-team",{"title":2802,"description":2803,"ogTitle":2802,"ogDescription":2803,"noIndex":6,"ogImage":2804,"ogUrl":2805,"ogSiteName":685,"ogType":686,"canonicalUrls":2805,"schema":2806},"How to build out your DevOps team","Hiring the right DevOps roles put you on the path to success. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664007/Blog/Hero%20Images/devopsroles.jpg","https://about.gitlab.com/blog/how-to-build-out-your-devops-team","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to build out your DevOps team\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Johanna Ambrosio\"}],\n \"datePublished\": \"2022-01-25\",\n }",{"title":2802,"description":2803,"authors":2808,"heroImage":2804,"date":2810,"body":2811,"category":757,"tags":2812},[2809],"Johanna Ambrosio","2022-01-25","\nGetting started with modern software development can feel overwhelming, particularly if you're trying to build a DevOps team from scratch. Hiring the right DevOps roles may require a blend of art, science, and luck, but it is doable. Here's our best advice on key DevOps roles, and the skills each position needs to make your DevOps team function like a well-oiled machine.\n\n- **Developers:** DevOps is a team sport nowadays. Devs test code, act as [security champions](/blog/why-security-champions/), provision infrastructure, and write automation scripts… just to name a few of the job requirements. They use scrum, Kanban, or other Agile methods to work in short iterations with regular feedback from the business side or from other clients. The dev role has changed dramatically over the past few years and will likely continue to adopt elements of other roles from UX to business-side subject matter expert. They want to continue to stretch themselves, so keep that in mind. In our [2021 Global DevSecOps Survey](/developer-survey/), developers said understanding AI/ML is the most important skill for their future careers. \n\n- **Operations engineer/systems administrator:** In Olden Times, this is the person who ensured the software could and did run smoothly in production and sent out alarms if it didn't. But on a DevOps team, ops will manage the cloud, help create monitoring and analytics that are integrated into code, manage the tools, deal with the tools, and, of course, help resolve problems. Like the dev role, operations pros need new and emerging skills to stay relevant, including advanced programming languages, subject matter expertise, and a deeper understanding of security, according to our survey.\n\n- **Evangelist:** Someone needs to make sure the rest of the company knows what your team is up to, sing its praises, and communicate what the business's most pressing needs are. Ideally, this is a senior-level person who sits on the company's Executive Committee or board. More than just a cheerleader, an evangelist on a DevOps team should get everyone in the company involved in DevOps, committed to its success, and happy to spend budget on the endeavor. \n\n- **Project manager/release manager:** This DevOps role tracks the team's progress against business objectives, sets goals and timelines, and tries to keep everything running on time. Solving problems with cost, project scope, schedule, and client satisfaction are also squarely in this job description.\n\n\n- **QA tester/automation engineer:** A testing professional plays a critical role on a DevOps team, even with the advent of \"devs who test\" and test automation. Testing pros look at the big picture of the entire software pipeline and at snippets of code. From choosing or creating the right tests to driving test automation, this DevOps role needs out-of-the-box thinking, flexibility, and the ability to pivot at a moment's notice. \n\n\n- **Security engineer:** It's critical to build in security and compliance from the start, rather than trying to tack it on at the end when fixing problems becomes most expensive. A security engineer on a DevOps team must be strategic and hands-on. Security has a lingering tarnished reputation as a top-down problem that devs literally don't have the tools to solve, but are asked to. So for this DevOps role, it's critical to hire someone who can meet dev and ops where they are, explain the challenges and technologies, and work together collegially.\n\n- **User experience (UX) professional:** This DevOps role is the end-user advocate, the person who is totally focused on how the software looks and works from the client's perspective. Think of the UX pro as the person who brings the client and the client's needs right into the development process. In this era of modern software development, [a UX role](/blog/the-evolution-of-ux-at-gitlab/) is a must-have rather than a nice-to-have.\n\nThose are just the \"getting started\" DevOps roles. Other titles to consider include a site reliability engineer or a DevOps platform engineer, an infrastructure engineer, project and product managers, systems engineers and architects, and software architects. Keep in mind that, especially now with the Great Resignation, [hiring talent for any of these DevOps roles](/blog/have-devops-jobs-to-fill-try-these-3-strategies-to-hire-and-retain/), and pretty much anything IT-related in general, can take months.\n\nReskilling is an excellent option, though. The DevOps Institute [offers trainings](https://www.devopsinstitute.com/skilup-days/), which it calls SKILup Days, on topics such as site reliability engineering and how to create a CI/CD pipeline. And when thinking about reskilling, don't forget [the importance of soft skills to a DevOps team](/blog/soft-skills-are-the-key-to-your-devops-career-advancement/). If ever there's a place where collaboration and communication matter, it's in DevOps.\n\n_Johanna Ambrosio is a freelance technology writer._\n\nCover image by Hans-Peter Gauster on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[695,737,9],{"slug":2814,"featured":6,"template":698},"how-to-build-out-your-devops-team","content:en-us:blog:how-to-build-out-your-devops-team.yml","How To Build Out Your Devops Team","en-us/blog/how-to-build-out-your-devops-team.yml","en-us/blog/how-to-build-out-your-devops-team",{"_path":2820,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2821,"content":2827,"config":2832,"_id":2834,"_type":13,"title":2835,"_source":15,"_file":2836,"_stem":2837,"_extension":18},"/en-us/blog/how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod",{"title":2822,"description":2823,"ogTitle":2822,"ogDescription":2823,"noIndex":6,"ogImage":2824,"ogUrl":2825,"ogSiteName":685,"ogType":686,"canonicalUrls":2825,"schema":2826},"How to code, build, and deploy from an iPad using GitLab and Gitpod","Senior Developer Evangelist Brendan O'Leary tackles the challenge of doing DevOps from a tablet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670178/Blog/Hero%20Images/GitLab-Ops.png","https://about.gitlab.com/blog/how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to code, build, and deploy from an iPad using GitLab and Gitpod\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n \"datePublished\": \"2022-02-10\",\n }",{"title":2822,"description":2823,"authors":2828,"heroImage":2824,"date":2829,"body":2830,"category":1053,"tags":2831},[1733],"2022-02-10","As a software engineer, it can be tough to go all-in on just using an iPad\nfor your daily driver. So when Apple announced the M1 chip-based iPads, I,\nalong with many techies, got excited to see if we'd finally get things like\na proper terminal on the iPad. But that still isn't the use case that the\niPad solves. I remained determined to be able to *code* from mine. So I\nhooked up my magic keyboard and fired up Gitpod to code and GitLab to build\nand deploy an app from scratch... all from my iPad.\n\n\n## Getting started\n\n\nLike any of [my projects](/blog/introducing-auto-breakfast-from-gitlab/),\nthe first thing I needed was inspiration. I had promised my colleague\n[Pj](https://brendan.fyi/pj) for some time that I would review [his\nblog](https://brendan.fyi/pj-twitter-blog) on how to make a Twitter bot like\nall of the fantastic ones he built while breaking into tech. Combine the\nneed to learn the Twitter API to provide an excellent review with my love of\nElton John's music, and I had it: I'd make a Twitter bot that tweeted every\nmorning at 4:00 am (as an homage to the line in “Someone Saved My Life\nTonight”).\n\n\nArmed with my newfound inspiration, I ran to gitlab.com in Safari (on my\niPad, obviously) and created a new, blank GitLab project.\n\n\n![ipad on\ndesk](https://about.gitlab.com/images/blogimages/brendanipad1.png){:\n.shadow}\n\n\n## Coding on the iPad\n\n\nOnce I had the new project, getting started on Gitpod was as easy as\nclicking the \"Gitpod\" button on GitLab to open my repository in Gitpod.\n\n\nGitpod enables you to access an entire development environment from any\nbrowser. By default, you get a container with many development tools (Node,\nRuby, OpenJDK, etc.). But you can also choose [your own\ncontainer](https://www.gitpod.io/docs/config-docker) as a starting point\nwith a .gitpod.yml… but we'll talk about that later.\n\n\nThe environment is presented to you as a VS Code interface – where you can\nopen, edit, and add files just as you'd expect. You can also access the\nterminal just like you would in VS Code and install anything you might need\nto get your project running.\n\n\nIn this example, I decided to build the Twitter bot in Node.js, so I\ninitialized a new Node project and installed the packages I'd need with:\n\n\n```bash\n\nnpm init -y\n\nnpm install express twit node-schedule dotenv\n\n```\n\n\n## Running your app\n\n\nOnce I had some code running – just the [Express sample\napp](https://expressjs.com/en/starter/hello-world.html) that says Hello\nWorld – running the app was just as easy as if I was going to run it on my\nlaptop:\n\n\n```bash\n\nnpm dev\n\n```\n\nNot only did that run my code to connect to the Twitter API, wait until 4:00\na.m. (UTC), and then tweet to let everyone know it was 4:00 a.m., but it\nalso shows this relative to my Express app:\n\n\n![Express\napp](https://about.gitlab.com/images/blogimages/brendanipad3.png){: .shadow}\n\n\nThat allows me to preview my [website for the\napp](https://brendan.fyi/4oclock) while I'm coding it. This is a massive\nbenefit because it means I can have two tabs open on the iPad – one with\nGitpod and my code and another with the website as I change it. Or I can\neven use split-screen on the iPad to have them side-by-side like I might if\nI was at my desk at my \"normal\" setup. And there's even a button to make the\nsite available publically so I could share it with my team and show them\nwhat I'm working on (as long as my Gitpod workspace is running).\n\n\nNow, when it comes to coding the rest of the Twitter bot, I used the\npreviously mentioned [tutorial](https://brendan.fyi/pj-twitter-blog) from my\ncolleague [Pj](https://brendan.fyi/pj). So I won't go into detail on the\nactual coding of the app – you can find the\n[code](https://gitlab.com/brendan-demo/4oclock),\n[website](https://brendan.fyi/4oclock), and [Twitter\nbot](https://twitter.com/DammitOclock) if you want to learn more about the\napp itself. But to deploy the website and the bot, I needed something else:\n[GitLab CI/CD](https://docs.gitlab.com/ee/ci/).\n\n\n## Deploying the app\n\n\nCombining GitLab CI/CD and GitLab.com's SaaS offering with Gitpod meant that\nI could not only code and preview the app from my iPad, but I could also get\nit deployed to Heroku (or any provider) from the couch. \n\n\nI created a `.gitlab-ci.yml` file in my project to get started. For\ndeploying to Heroku:\n\n\n- I like to use a Ruby package called\n[dpl](https://github.com/travis-ci/dpl) from Travis CI because it makes it a\nsimple one-line command. Alternatively, I could install the [Heroku\nCLI](https://devcenter.heroku.com/articles/heroku-cli) and deploy with that\nif I wanted to. \n\n\n- I added the `HEROKU_API_KEY` variable to my [CI/CD\nvariables](https://docs.gitlab.com/ee/ci/variables/#add-a-cicd-variable-to-a-project)\nso that I could authenticate with Heroku for the deployment. \n\n\n- I then set the `rules:` section to only deploy when commits are impacting\nthe main (default) branch, and I was ready to go! \n\n\nNow, every time I push code from Gitpod to GitLab, GitLab will start the\nbuild and deploy it to Heroku:\n\n\n```yaml\n\nimage: starefossen/ruby-node:2-10\n\n\nvariables:\n APP_NAME: four-oclock-in-the-morning\n\ndeploy:\n stage: deploy\n script:\n - gem install dpl -v 1.10.6\n - dpl --provider=heroku --app=$APP_NAME --api-key=$HEROKU_API_KEY\n rules:\n - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n```\n\n\n## Enabling collaboration\n\n\nThere are two other concepts that this pattern introduces that are worth\ndiscussion: the idea of one environment per change and enabling new\ncollaborators to spin up a development environment in seconds.\n\n\nMost developers are used to having our setup just the way we like it –\nprecisely the correct number of monitors, keys on our keyboard, and all of\nour favorite tools installed. However, that can lead to issues. We already\nknow we should treat our servers like cattle, not pets, so why do we still\ntreat our laptops like pets? While I love my MacBook and the stickers on it\nas much as the next person, I can get frustrated when setting up a new one\nand getting it back to the way I like it.\n\n\nIn addition, on many projects I've been on in the past, onboarding a new\ndeveloper can take a lot of effort, including getting the correct libraries\ninstalled and ensuring they have access to all the right resources and\nenvironments. These things may seem trivial, but I've seen it take up to\nthree days from senior engineers just to get another engineer up and\nrunning. All of that time is time that could be much better spent on writing\ncode for the actual business.\n\n\nGitpod solves both of these issues with a simple YAML file: `.gitpod.yml`.\nThis file allows you to specify:\n\n\n- What image to use as the base for the environment\n\n- Which other tools to install\n\n- What commands to run at startup, and even things like which VSCode\nextensions you should have in the environment\n\n\nAnd [lots of different\nsettings](https://www.gitpod.io/docs/references/gitpod-yml) that you can\nfind in the [Gitpod docs](https://www.gitpod.io/docs).\n\n\nSpecifying all of the tools needed lets you have short-lived environments\nthat you can spin up for one task and then discard and get a fresh one for\nthe next task. And it also saves time when onboarding new engineers by\nguaranteeing they have a running system within just a few seconds of opening\nthe project. Best of all, it is all in a file that's in source control, so\nas things change or you make improvements to the development environment,\nall of your developers benefit from it immediately. \n\n\nI added a simple\n[`.gitpod.yml`](https://gitlab.com/brendan-demo/4oclock/-/blob/main/.gitpod.yml)\nto run `npm run dev` to get started when you create a new environment. That\nsimple example is great for a simple Node app or similar, but what about\nsomething more complex? Gitpod works for that, too. GitLab itself has a\n[`gitpod.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitpod.yml)\nthat lets you get an entire working GitLab development environment – and all\nthat entails – up and running quickly, without the need to install Postgres\nand Redis and all of the other dependencies GitLab has.\n\n\nThis makes contributing to GitLab easier than ever. Just go to the [GitLab\nrepository](https://brendan.fyi/gitlab-repo) and click on that Gitpod button\nto get started. I'd love to hear how it works for you!\n",[695,828,9],{"slug":2833,"featured":6,"template":698},"how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod","content:en-us:blog:how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod.yml","How To Code Build And Deploy From An Ipad Using Gitlab And Gitpod","en-us/blog/how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod.yml","en-us/blog/how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod",{"_path":2839,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2840,"content":2845,"config":2850,"_id":2852,"_type":13,"title":2853,"_source":15,"_file":2854,"_stem":2855,"_extension":18},"/en-us/blog/how-to-improve-communication-remote-designer",{"title":2841,"description":2842,"ogTitle":2841,"ogDescription":2842,"noIndex":6,"ogImage":2081,"ogUrl":2843,"ogSiteName":685,"ogType":686,"canonicalUrls":2843,"schema":2844},"How to improve your communication as a remote designer in 6 simple steps","When you're explaining designs or requesting feedback, it's easy to give too much information. Here are some tips on how you can communicate better as a designer, especially if you're working remotely.","https://about.gitlab.com/blog/how-to-improve-communication-remote-designer","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to improve your communication as a remote designer in 6 simple steps\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Moreira da Silva\"}],\n \"datePublished\": \"2021-01-06\",\n }",{"title":2841,"description":2842,"authors":2846,"heroImage":2081,"date":2847,"body":2848,"category":716,"tags":2849},[2086],"2021-01-06","\n{::options parse_block_html=\"true\" /}\n\n## Communication is hard\n\nAt GitLab, [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) is one of our core values. Being efficient in everything we do is important, but it's even more important when communicating and collaborating with others. We need this emphasis on efficiency, [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration), and [communication](https://handbook.gitlab.com/handbook/communication/) for GitLab to work as an all-remote company, with zero offices and team members distributed across the globe.\n\nIn the context of design, when you're explaining a design decision or requesting feedback, it's easy to fall into the trap of giving too much information. **You want people to understand it right away, so you give as much background and arguments as possible. The problem is that long messages and explanations can put up a collaboration-barrier.** When people have many things competing for their attention, it's hard for them to take the necessary time to read long messages and engage themselves in a constructive discussion. Also, often the most important points get diluted because of how long something is.\n\n**So how can you communicate better and more efficiently as a designer, especially if you're working remotely?** I'm a designer working remotely for over 4 years and I've learned a lot about communication. Let me share 6 practical tips that you can use when sharing information or requesting something from someone:\n\n1. Important things first\n1. Keep it short\n1. Balance context and conciseness\n1. Use multiple formats\n1. Clear calls-to-action\n1. Use simple language\n\nAt the end of this article, there's a [structure and example that puts all of these tips together](#example), so that you can improve your communication today.\n\n## ❗️ Important things first\n\n**Make sure you communicate the important things first.** Journalists do this very well by using the [inverted pyramid](https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)) method: information is prioritized so that the major details come before the minor details. So empathize with your audience and think how much little time they can afford to invest in your message. Prioritize and structure your communication so that the key aspects come first and it's as easy as possible to learn about them.\n\n## 📟 Keep it short\n\n[**Keeping written communication short**](https://handbook.gitlab.com/handbook/values/#keep-broadcasts-short) **and** [**giving short verbal answers**](https://handbook.gitlab.com/handbook/values/#short-verbal-answers) goes hand in hand with communicating the important things first. If you need to give a lot of information, maybe there's a communication or expectations problem.\n\nAlthough we default to [asynchronous communication](https://handbook.gitlab.com/handbook/communication/#asynchronous-communication) at GitLab, sometimes a short video call is enough to unblock and make sure everyone's aligned without having to invest too much time in writing and reading something. Our rule of thumb is: “if you have gone back and forth 3 times, it's time for a video call.” (also see [video calls guidelines](https://handbook.gitlab.com/handbook/communication/#video-calls)).\n\nOther times, it can also be that the topic at hand is just too large to discuss in one go. Think about how you can break it down into smaller, more “consumable” pieces. It will make life easier for you, the other participants, and anyone else that is following that topic. To help you break things down, read “[Iterate Like a GitLab Designer](https://about.gitlab.com/blog/iterate-like-a-gitlab-designer/)” or our handbook section on [iteration](https://handbook.gitlab.com/handbook/values/#iteration).\n\n## 🤹 Balance context and conciseness\n\n**Try to provide as much context as possible while balancing the conciseness of your message.** This may seem the opposite of keeping it short, but you do need to strike a balance. You don't want your message to be too short, as it can cause confusion and require clarification, which ultimately delays things. But you also don't want your message to be too long, for all of the reasons I've mentioned so far. Striking this balance sounds incredibly challenging, but fortunately, we have some methods to help us with that, like the inverted pyramid that I described before or multiformat communication.\n\n## 🎨 Use multiple formats\n\n**Communicating through multiple formats means thinking about your audience and applying your message to the formats that are most likely to attract that audience.** An example is requesting feedback on an idea: you can share an image, a brief paragraph explaining the idea, a list of bullet points with the pros and cons, and maybe even a short video where you walk people through it. This way, each person jumps to and consumes the format that resonates the most with them, how they want it.\n\nBut remember that you don't have to use every format, every time. It depends on who you're communicating with, what you're communicating, and when a certain action is needed. Think about these aspects and choose the communication format that best suits them (and also the time you can invest in crafting your message).\n\n## ☝️ Clear calls-to-action\n\n**If you have calls-to-action, make them clear, direct, and specific.**\n\nPerhaps the most important aspect of those three: try to direct your asks to specific people, instead of a group of people or no one at all. The work you put into selecting and targeting who you ask is proportional to the quality of their responses. Asking a group of people is sometimes necessary, but there's a risk of getting nothing but “radio silence,” so be extra careful in crafting your message if you're targeting a group.\n\nRegarding CCs, one of our [communication best practices](https://handbook.gitlab.com/handbook/communication/#top-tips-and-best-practices) says it best:\n\n> It is OK to bring an issue to someone's attention with a CC (\"cc @user\"), but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.\n\nBe clear and specific about the who, what, and why. If it's a vague or broad ask, it will be much more difficult for others to respond.\n\nFinally, place any asks you have at the beginning of your message. These asks fall into the “important things first” tip because, well, they are supposed to be important! If possible, consider repeating them at the end of the message as a reminder.\n\n## 👐 Use simple language\n\n**Finally, use** [**simple language**](https://handbook.gitlab.com/handbook/communication/#simple-language) **and terms that everyone understands** (see [ubiquitous language](https://handbook.gitlab.com/handbook/communication/#ubiquitous-language)). For example, instead of using the “IxD” acronym, say “interaction design.” Or explain what that means with simple language if you can, like saying “how a user might interact with the user interface and how it behaves.”\n\n## Example\n\nTo bring it all together, I'll first share with you a structure that you can use when requesting feedback or communicating your work, either in a written message, a video, or a presentation:\n\n1. **Summary**: A very short summary ([tl;dr](https://en.wiktionary.org/wiki/tl;dr)) of your message, with simple language and shared terms. If possible, consider bolding the whole summary so it sticks out from the rest.\n1. **Asks**: Be clear about what you want and until when. If possible, mention specific people and make sure to bold/highlight their names (if not automatically highlighted). When requesting feedback, specify the kind of feedback you're looking for, what they should comment on, and also what they should not comment on.\n1. **Walkthrough**: If you have a video or presentation that gives an overview of the topic, link to it. Better yet, embed it in your message to reduce clicks and friction, but always keep a link so it's accessible to everyone.\n1. **Visual**: Try to add a simple image/diagram that describes the core elements of what you're communicating.\n - If you have more visuals that you'd like to share, link to an external page with them. For example, at GitLab we use Figma to design user interfaces, so we link to Figma files where people can view all of the design work.\n1. **Details**: More information in the form of short paragraphs or lists. It could be links to any additional references, support documentation, or artifacts. Remember to keep them short!\n - Tip: Some writing tools support the `\u003Cdetails>` HTML tag, that allows you to easily hide information behind a toggle, like an accordion. See the [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details) for a simple example and copy-pastable markup.\n1. **Close**: Consider reiterating your asks and thank people for their time.\n\nAnd to see how this can work in practice, here's an example message, where I requested feedback from my team members on a few possible design options:\n\n![Example feedback request message showing an embedded video and collapsible information panels](https://about.gitlab.com/images/blogimages/how-to-improve-communication-remote-designer/example.gif){: .shadow.center}\n\n## Keep improving your communication skills\n\nThe act of improving one's communication skills doesn't stop, because the “why, what, how, and who” are always changing. The quality of communication can make or break an individual, a team, or an organization. As Anthony Robbins puts it:\n\n> The way we communicate with others and ourselves ultimately determines our quality of life.\n\nIn this article I focused on writing, speaking, and showing. But communication is also about how you read, listen, and watch. Maybe I'll write about that other side of communication in the future. In the meantime, I leave you with our [handbook page on communication](https://handbook.gitlab.com/handbook/communication/), which is a great place to learn more about what makes good communication in a remote company.\n\nCover image by [Stellan Johansson](https://unsplash.com/@stellanj) on [Unsplash](https://unsplash.com/photos/1PP0Fc-KSd4)\n{: .note}\n",[9,1096,1097,1099],{"slug":2851,"featured":6,"template":698},"how-to-improve-communication-remote-designer","content:en-us:blog:how-to-improve-communication-remote-designer.yml","How To Improve Communication Remote Designer","en-us/blog/how-to-improve-communication-remote-designer.yml","en-us/blog/how-to-improve-communication-remote-designer",{"_path":2857,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2858,"content":2864,"config":2870,"_id":2872,"_type":13,"title":2873,"_source":15,"_file":2874,"_stem":2875,"_extension":18},"/en-us/blog/how-to-learn-ci-cd-fast",{"title":2859,"description":2860,"ogTitle":2859,"ogDescription":2860,"noIndex":6,"ogImage":2861,"ogUrl":2862,"ogSiteName":685,"ogType":686,"canonicalUrls":2862,"schema":2863},"How to learn CI/CD fast","Continuous integration and continuous delivery (CI/CD) are critical to faster software releases and it's less complicated than it seems to get rolling. Here's how to start fast with CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668027/Blog/Hero%20Images/cicd.jpg","https://about.gitlab.com/blog/how-to-learn-ci-cd-fast","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to learn CI/CD fast\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Vanbuskirk\"}],\n \"datePublished\": \"2022-04-13\",\n }",{"title":2859,"description":2860,"authors":2865,"heroImage":2861,"date":2867,"body":2868,"category":757,"tags":2869},[2866],"Mike Vanbuskirk","2022-04-13","\nContinuous integration and continuous delivery (CI/CD) have become the keystone technical architecture of successful DevOps implementations. CI/CD has a reputation for being complex and hard to achieve, but that doesn’t have to be the case. Modern tools enable teams to get started with minimal configuration and infrastructure management. Here’s how you can “start fast” with CI/CD and get some quick, demonstrable performance wins for your DevOps team.\n\n## What does CI/CD mean?\n\n[CI/CD](/topics/ci-cd/) refers to a system or systems that enable software development to have continuous integration and continuous delivery capabilities. The architecture underpinning CI/CD is typically referred to as a pipeline, as software progresses through various stages akin to flowing through a pipe. What does [continuous integration and continuous delivery](/blog/basics-of-gitlab-ci-updated/) actually mean? Taking some time to explore the more granular details will help us set some goals for getting a fast start with CI/CD.\n\nStarting on the left side of the pipeline, continuous integration encompasses a variety of automation that occurs over the course of multiple stages, designed to test and provide quick feedback on different aspects of code quality, functionality, and security. CI testing can run the gamut from unit tests and linting run locally on a developer workstation, to full integration testing suites and static analysis. Anyone that's ever seen a small code change cause a significant outage or breakage upon reaching production knows the value of automated, repeatable testing, and the downsides of depending on manual testing.\n\nOnce a code change has passed testing, it's time to deploy. In legacy environments, system administrators and operations staff often had to manually transfer and install updates, and reboot servers to deploy new features. This type of manual work simply does not scale to the demands of the modern application ecosystem, and is error prone to boot. With continuous delivery, that code is automatically deployed to servers in a testable and deterministic way. Code [can be staged in environments](/blog/ci-deployment-and-environments/) with less strict SLAs, such as development, staging, and QA. Once it has been verified, the new features can be launched as production workloads. In some environments, \"continuous delivery\" becomes \"continuous deployment\", in which comprehensive testing automatically deploys new code through to production without human intervention.\n\nWhat's the ultimate goal of all this automation? It's what makes a successful software organization: faster deployment cadence.\n\n## Getting started with CI/CD\n\nWith a little background established, now it's time to focus on the key objective: getting up and running quickly. The primary goal here is to get a quick win with a CI/CD implementation to improve deployment velocity, and hopefully drive a larger effort towards standardizing on widespread and effective CI/CD usage.\n\nGetting started with CI/CD can appear daunting. There is a wealth of tools, services, and platforms available to provide specific functionality and end-to-end solutions for CI/CD. Some options like [Jenkins](https://www.jenkins.io) are self-managed; others, including GitLab, have a holistic CI/CD pipeline with integrated version control.\n\n## Build your pipeline\n\nRealistically, there is no magic bullet configuration for CI/CD. Each implementation will be highly dependent on a number of factors: the type of application being deployed, the size and skillset of the engineering team/s, the business requirements, and the scale of the application itself. The design and implementation considerations for an application that might see 100 users per day is vastly different from one that sees 1 million. The same holds true for CI/CD.\n\nBelow are 5 high-level strategies for tackling that first CI/CD pipeline:\n\n### 1. Start small\n\nDon't try to fix everything at once. Attempts to refactor an entire codebase or infrastructure will be a complex process, typically involving multiple layers of approval, discussion, planning, and possible pushback from dependent teams. It's much easier to choose a small subset of the application infrastructure to improve.\n\n### 2. Catch low-hanging fruit early\n\nSome of the simplest and easiest to detect (and fix) errors can end up causing the biggest problems if they make it into production workloads. However, it might not make sense to add unnecessary steps or complexity to the CI/CD pipeline. In this instance, it’s a good choice to configure some automatic testing to take place on developer machines before code is committed. Most Git DVCS providers, including GitLab, allow users to deploy pre-commit hooks. Pre-commit hooks are typically some type of script or automation that are triggered when specific actions occur. For example, when a developer initiates a new commit, a pre-commit hook might check that the code conforms to syntactical and structural standards, and is free from basic syntax errors. Other pre-commit hooks might ensure that unit tests are run successfully before a commit is allowed to proceed into the larger pipeline.\n\n### 3. Make security a part of CI/CD\n\nTests shouldn't just be limited to syntax and logic. Catching security issues early in the software development lifecycle (SDLC) means they are much easier, cheaper, and safer to fix. Adding some basic [static code analysis tools](https://docs.gitlab.com/user/application_security/sast/customize_rulesets/) and dependency checkers can vastly improve the security posture of an application by providing fast feedback and early detection of common security problems and potential vulnerabilities.\n\n### 4. Tailor tests to common issues\n\nMost engineering teams that rely on legacy deployment methodologies should be able to easily identify one or two common, recurring issues in deployments. Perhaps copying application code to servers via SCP always results in broken file permissions, or an [NGINX](https://www.nginx.com) frontend is never properly restarted. For the first iteration of [automated testing](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/), choose these specific issues to address with testing. This serves two purposes; it limits the scope of work and gives the team an achievable [\"definition of done,\"](https://www.leadingagile.com/2017/02/definition-of-done/) and it provides a highly visible success story by fixing the most problematic existing deployment problems. Once a working pipeline has been deployed and there is organizational buy-in, the testing suite can be expanded.\n\n### 5. Automate deployment to lower environments\n\nNew CI/CD implementations should [focus on continuous delivery](/blog/cd-solution-overview/), automatically deploying to a staging environment, and providing a manual decision interface for deploying to production. Continuous deployment is generally a step that should be taken further in the DevOps journey when there is more collective knowledge and technical maturity around automated deployments.\n\n## Get a fast start with CI/CD\n\nA good CI/CD implementation can measurably improve software deployment velocity and is a core pillar of a solid DevOps strategy. However, the first attempt at utilizing CI/CD should eschew heavy, complex deployments whenever possible, instead focusing on a \"batteries-included\" approach that provides teams with a short time-to-value cycle.\n\nOnce CI/CD provides that quick win, engineering teams can build on that momentum and buy-in to scale the solution across the entire organization, improving deployment speed and outcomes throughout.\n",[108,695,9],{"slug":2871,"featured":6,"template":698},"how-to-learn-ci-cd-fast","content:en-us:blog:how-to-learn-ci-cd-fast.yml","How To Learn Ci Cd Fast","en-us/blog/how-to-learn-ci-cd-fast.yml","en-us/blog/how-to-learn-ci-cd-fast",{"_path":2877,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2878,"content":2884,"config":2890,"_id":2892,"_type":13,"title":2893,"_source":15,"_file":2894,"_stem":2895,"_extension":18},"/en-us/blog/how-to-move-from-ic-to-devops-manager-and-succeed",{"title":2879,"description":2880,"ogTitle":2879,"ogDescription":2880,"noIndex":6,"ogImage":2881,"ogUrl":2882,"ogSiteName":685,"ogType":686,"canonicalUrls":2882,"schema":2883},"How to move from IC to DevOps manager and succeed","Transitioning from great DevOps engineer to great DevOps manager isn't always easy. Here are some tools to help you get a management role and keep it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663753/Blog/Hero%20Images/managers-more-optimistic-than-developers.jpg","https://about.gitlab.com/blog/how-to-move-from-ic-to-devops-manager-and-succeed","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to move from IC to DevOps manager and succeed\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lauren Gibbons Paul\"}],\n \"datePublished\": \"2022-03-01\",\n }",{"title":2879,"description":2880,"authors":2885,"heroImage":2881,"date":2887,"body":2888,"category":693,"tags":2889},[2886],"Lauren Gibbons Paul","2022-03-01","\nAs a seasoned [DevOps engineer](https://about.gitlab.com/topics/devops/what-is-a-devops-engineer/), an individual contributor (IC) role might eventually start to chafe. Here are 5 strategies to make the case that you're ready for a DevOps manager role, and 3 key things to keep in mind once you get there.\n\n## DevOps manager: More than just the title\n\nJust as many organizations don’t have dedicated DevOps teams – they just do DevOps – many will not have a title that sounds like “DevOps manager.” It is not uncommon for your current position to morph into a managerial role, so let your manager know you’re interested. Also, it never hurts to come into that conversation with a transition plan already in hand.\n\nUntil then, hone the skills that make for a good manager of any type – things like being a good communicator, mentoring others, and fostering collaboration. [Collaboration is a must-have](https://www.techrepublic.com/article/how-to-become-a-devops-manager-5-tips/#:~:text=A%20good%20DevOps%20manager%20encourages,learn%20and%20develop%2C%20Kromhout%20said) in a management role. \n\n## DevOps manager skills\n\nDevOps manager skills include deep technical expertise in at least one area, such as systems architecture, along with broad technical experience. Ideally, a manager will have the ability to program in multiple languages to give relevant feedback and better understand the tools and support team members need. You’ll also need to understand how to respond to security incidents. \n\n[Sharpening and adding to your technical skills](https://victorops.com/blog/being-a-devops-team-manager) – and learning new ones – are some of the best things you can do to make yourself more attractive as a potential DevOps manager. Not only will new skills help [advance your career](/blog/the-top-skills-you-need-to-get-your-devops-dream-job/), they’ll help your paycheck even if you decide to remain an individual contributor. And don’t forget the “impress your boss” benefits of being a [continuous learner](/blog/best-advice-for-your-devops-career-keep-on-learning/).\n\n## Understand the expectations (and implications) of management\n\nWhen examining DevOps manager roles and responsibilities, job number one is mediating the interpersonal skirmishes among team members and with other groups. Alone, that can be challenging enough, but it’s just the starting point. \n\nBefore you take on the role, make sure you understand what is involved. A DevOps manager will be expected to help set goals and timelines, oversee project management, obtain needed tools and skills, understand the work teams are doing, advocate for team interests within the wider organization, evangelize, and generally be a cheerleader for anyone who needs it. And don’t forget, [cheerleading is serious business](https://www.agileconnection.com/article/management-myth-11-team-needs-cheerleader) in many organizations. A DevOps manager also needs a good network, and to be able to bring people onboard to fill skills gaps. \n\n## Find a mentor\n\nMany companies offer mentorship programs, including [GitLab](/handbook/people-group/learning-and-development/mentor/), and they can be a tremendous resource for someone looking to grow into a management role. A mentor doesn't have to be a technology leader – learning management from someone in marketing, sales, or finance is useful as well.\n\n## Volunteer for an interim role\n\nWhether it's the \"great resignation\" or simply the usual tech churn, turnover can mean teams need \"interim\" leaders. Being an interim manager can be an opportunity to get your feet wet, help out in an area that might not be completely familiar, and show your willingness to stretch, learn new things, and be a true team player. Obviously, many interim roles don't turn into permanent ones, but they still offer experience that can help build a case for a promotion to management. \n\n## You're a manager now\n\nOnce you’ve stepped into a DevOps manager role, here are three ways to be successful:\n\n1. **Lead the change**. The concept of DevOps obviously means that development and operations are working together, but it also requires working closely with other functional areas with a culture of openness. Good managers break down organizational silos and help people assimilate and embrace the changes needed for successful DevOps. The best DevOps managers are able to bridge communication gaps, tearing down the walls between functions – especially developers, IT operations, and security – and strive to instill a sense of [shared purpose and empathy](https://www.toptal.com/devops/bridging-gaps-devops-communication#:~:text=What%20is%20DevOps%20in%20simple,using%20common%20processes%20and%20tools).\n\n2. **Focus on the processes and the metrics**. A successful DevOps manager is able to toggle quickly between personnel and process. Fine-tuning the [CI/CD pipelines](/topics/ci-cd/), test automation, multi-cloud options, and cutting-edge technology choices like Kubernetes and AI/ML will require a continuous improvement mentality and a serious reliance on metrics. If you can’t measure performance, it’s tough to improve it. Also, by focusing on incremental performance increases, a DevOps manager not only increases development velocity, but is in a good place [to plan for the future](https://www.techopedia.com/devops-managers-explain-what-they-do/2/33379). \n\n3. **Don’t overlook training for the team**. Technical skills are the lifeblood of the DevOps team, and they need constant updating. But most people feel they are too busy to take time for training [and some of it may not be particularly compelling](https://www.agileconnection.com/article/management-myth-9-we-have-no-time-training). Your challenge as a DevOps manager is to first convince your managers that the training is justified and then to persuade your team to make time for it. Find the right kind of training and offer it to the people who need it, when they need it. Delivering learning in chunks of five to 10 minutes, also known as microlearning, has been proven much more engaging for employees and drives retention. So, look for training employees can schedule and do on their own time and terms – and ideally [via mobile devices](https://elearningindustry.com/microlearning-vs-macrolearning-for-corporate-training#:~:text=According%20to%20research%2C%20microlearning%20is,bringing%20learning%20to%20the%20employees).\n",[695,737,9],{"slug":2891,"featured":6,"template":698},"how-to-move-from-ic-to-devops-manager-and-succeed","content:en-us:blog:how-to-move-from-ic-to-devops-manager-and-succeed.yml","How To Move From Ic To Devops Manager And Succeed","en-us/blog/how-to-move-from-ic-to-devops-manager-and-succeed.yml","en-us/blog/how-to-move-from-ic-to-devops-manager-and-succeed",{"_path":2897,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2898,"content":2904,"config":2909,"_id":2911,"_type":13,"title":2912,"_source":15,"_file":2913,"_stem":2914,"_extension":18},"/en-us/blog/how-to-shorten-conversation-cycle",{"title":2899,"description":2900,"ogTitle":2899,"ogDescription":2900,"noIndex":6,"ogImage":2901,"ogUrl":2902,"ogSiteName":685,"ogType":686,"canonicalUrls":2902,"schema":2903},"How to shorten the conversation cycle","Four simple steps to move faster from idea to production.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671350/Blog/Hero%20Images/shorten-conversation-cycle.jpg","https://about.gitlab.com/blog/how-to-shorten-conversation-cycle","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to shorten the conversation cycle\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n \"datePublished\": \"2017-06-19\",\n }",{"title":2899,"description":2900,"authors":2905,"heroImage":2901,"date":2906,"body":2907,"category":910,"tags":2908},[1158],"2017-06-19","\n\nIf your new features often get stalled in the initial discussion phase, read our four tips for shortening the conversation cycle and shipping faster.\n\n\u003C!-- more -->\n\n## 1. Measure your cycle time\n\nThe first step towards making a change is having the numbers to motivate it. If you measure the duration of time from the moment an idea is first discussed in chat, all the way through to its release in production, you can make a good case for changing your approach if others can see that something is causing delays. Try a feature like [cycle analytics](/solutions/value-stream-management/) to monitor each stage in your workflow.\n\n## 2. Start with minimum viable changes\n\nYou've identified the problem, now how do you fix it? Where ideas for new features and improvements often get stuck is on how to implement them. The idea may be too ambitious or too time consuming to ship easily, so it gets pushed back in favor of more manageable changes. Try breaking up new products or features into smaller pieces of functionality. [Iteration is one of our company values](https://handbook.gitlab.com/handbook/values/) and while it's often one of the more uncomfortable ones, it is effective. Do the smallest thing possible and release it quickly – you can keep iterating from there.\n\n## 3. Include gatekeepers early on\n\nWho needs to approve something before you ship? Don't leave them out until the last minute. Including stakeholders, security experts, product managers and UX team members in the conversation in the early phases prevents bottlenecks ahead of release, and ensures that most errors have been caught and addressed before you move into production. Read more about [shipping faster without sacrificing security or quality](/blog/speed-security-quality-with-hackerone/).\n\n## 4. Get everyone on board\n\nAcknowledging that a feature or product is not polished and needs more work, yet releasing it anyway, feels unnatural to most of us, so you may meet some resistance to the idea. Working in this way does offer benefits to both business owners and developers, which you can communicate to help persuade hesitant team members.\n\nFor example, you can respond more quickly to market needs and user feedback by shipping minimum viable changes often, which is good news for your business. For developers, it's easier to troubleshoot a small release and having faster, more frequent feedback on work gives more of a sense of progress and boosts motivation.\n\nMoving towards smaller releases to shorten the time between idea and production may feel strange at first, but you'll start seeing results quickly.\nShortening the conversation cycle is just one principle of Conversational Development. Visit [conversationaldevelopment.com](http://conversationaldevelopment.com/) to learn more.\n{: .alert .alert-gitlab-orange}\n\n[Cover image](https://unsplash.com/@djmalecki?photo=fw7lR3ibfpU) by [Dawid Malecki](https://unsplash.com/@djmalecki) is licensed under [CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/)\n{: .note}\n",[9,912],{"slug":2910,"featured":6,"template":698},"how-to-shorten-conversation-cycle","content:en-us:blog:how-to-shorten-conversation-cycle.yml","How To Shorten Conversation Cycle","en-us/blog/how-to-shorten-conversation-cycle.yml","en-us/blog/how-to-shorten-conversation-cycle",{"_path":2916,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2917,"content":2923,"config":2928,"_id":2930,"_type":13,"title":2931,"_source":15,"_file":2932,"_stem":2933,"_extension":18},"/en-us/blog/how-to-stand-up-gitlab-in-awsmp",{"title":2918,"description":2919,"ogTitle":2918,"ogDescription":2919,"noIndex":6,"ogImage":2920,"ogUrl":2921,"ogSiteName":685,"ogType":686,"canonicalUrls":2921,"schema":2922},"How to stand-up a GitLab instance in AWS Marketplace","This is a quick quide to help you provision a GitLab instance in the AWS Marketplace and setup a Runner.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682043/Blog/Hero%20Images/awsmp.png","https://about.gitlab.com/blog/how-to-stand-up-gitlab-in-awsmp","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to stand-up a GitLab instance in AWS Marketplace\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n \"datePublished\": \"2021-06-30\",\n }",{"title":2918,"description":2919,"authors":2924,"heroImage":2920,"date":2925,"body":2926,"category":1053,"tags":2927},[2398],"2021-06-30","\n\n## In this guide we will learn how to spin up GitLab in the AWS Marketplace:\n\n### Pre requisites for this lab are having an account in AWS and an accessible and working VPC.\n\n### We will learn the following steps:\n\n1. Stand up a self-managed instance of GitLab.\n2. Install Runner and Docker Engine.\n\n\n## Step-by-step Instructions\n\n\n### Step 1 - Stand up GitLab instance in AWS\n\n\n- Open [GitLab Ultimate](https://aws.amazon.com/marketplace/pp/B07SJ817DX) in AWS Marketplace.\n- Click on **Continue to Subscribe**\n\n![aws-1](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-1.png)\n\n- Sign in with your IAM user.\n\n![aws-2](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-2.png)\n\n- Click on **Continue to Configuration**.\n\n![aws-3](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-3.png)\n\n- Leave the default value for **Delivery Method**, select the latest version in **Software Version**, select your **Region**, click **Continue to Launch**.\n\n![aws-4](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-4.png)\n\n- In Launch this software page, scroll down.\n\n![aws-5](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-5.png)\n\n- Under **Security Group Settings** click **Create New Based On Seller Settings** .\n\n![aws-6](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-6.png)\n\n- Name your security group, add a description, and save it.\n\n![aws-7](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-7.png)\n\n- Select **Key Pair**. If you don't have key pair, create one. Leave other fields in this page with default values. Click **Launch**.\n\n![aws-8](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-8.png)\n\n- You will get Congratulations message confirming you launched the machine successfully. In this message click on **EC2 Console** link.\n\n![aws-9](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-9.png)\n\n- Click on your instance ID link.\n\n![aws-10](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-10.png)\n\nThe provisioning takes a few minutes. Please wait before you start the next step.\n\n- Click \"Open address\" in order to open GitLab UI.\n\n Copy the **private** or **public** IP to your browser , depending on your **VPC configuration**.\n\n\n![aws-10_5](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-10_5.png)\n\n- It takes a few minutes to start the server, you may see this error, this is ok, wait 1 minute and refresh the page.\n\n![aws-11](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-11.png)\n\n- You now should be able to access the GitLab login page; Username is **root**, password is your **instance ID**, click **Sign in**.\n\n![aws-13](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-13.png)\n\n## Congratulations! you managed to start a GitLab instance and sign in to it.\n\n![aws-14](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/aws-14.png)\n\n\n\n\n### Step 2 - Install Runner and Docker Engine\n\n\nRunner machines are the build agents that run the CI/CD jobs.\n\nRequirements:\n\n- Jobs run inside the Docker images, therefore the runner machine requires Docker engine on the runner machine.\n\n\n### Connect to the machine with the **AWS console - Connect**\n\nIn order to setup the Runners and Docker engine, we need to connect to the GitLab machine we are running. This can be done via **SSH** from any command line, or directly via the **AWS Console**, depending on how your **VPC** is set. In our example we will use the **AWS console - Connect** feature to SSH into the machines.\n\n**WARNING: It is not a recommended best practice to install Runners on the same machine where the server is installed for security and performance reasons, but only for the sake of simplicity, in this blog we will install it on the same machine.**\n\n - Go to your Instance summary, and click **Connect** in order to open the console.\n\n ![runner-1](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-1.png)\n\n - Click Connect again.\n\n ![runner-2](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-2.png)\n\n\n### Install Docker engine\n\n - Install Container by running this command `curl -fsSL https://get.docker.com -o get-docker.sh\n sudo sh get-docker.sh`\n\n\n### Setup Runners\n\n - Download the binaries for Linux x86 `sudo curl -L --output /usr/local/bin/gitlab-runner \"https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386\"`\n - Give it permissions to execute: `sudo chmod +x /usr/local/bin/gitlab-runner`\n - Create a GitLab CI user: `sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash`\n - Install and run as service: `sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner\nsudo gitlab-runner start`\n\n\n### Register the Runner\n\n\n - Run this command: `sudo gitlab-runner register`.\n - You will be prompt to enter URL.\n - Open your GitLab instance, under CI/CD settings:\n - Click Settings, CI/CD.\n\n ![runner-2](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-3.png)\n\n - Expand **Runners**.\n\n ![runner-4](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-4.png)\n\n - Copy the URL to the clipboard under specific runner.\n\n ![runner-5](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-5.png)\n\n - Paste the URL in the console.\n - Enter.\n - You will be prompt to enter registration token, copy it from the Runner settings.\n\n![runner-5](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-6.png)\n\n - Paste it in the console.\n - Enter Description for the runner: type **GitLab workshop**.\n - Add a tag to this runner, for example type **Linux**\n - Enter executor, type **docker**.\n - Enter the default Docker image, type **ruby:2.6**.\n - You will get a message starting with **Runner registered successfully. Feel free to start it...**\n - Refresh the Runner settings page in GitLab and you will see your runner under **Available specific runners**.\n - Click edit.\n\n ![runner-7.png](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-7.png)\n\n - Check the **Indicates whether this runner can pick jobs without tags** option, and click **Save changes**.\n\n ![runner-7.png](https://about.gitlab.com/images/blogimages/2021-aws-marketplace-blog/runner-8.png)\n\n\n## Well done!! You installed and registered successfully GitLab Runner. Now you are ready to create a project and run your first CI/CD pipeline.\n\nIn my next blog, I will show you how to create a project, configure the CI/CD, change your application code, and run a CI/CD pipeline.\n",[9,695],{"slug":2929,"featured":6,"template":698},"how-to-stand-up-gitlab-in-awsmp","content:en-us:blog:how-to-stand-up-gitlab-in-awsmp.yml","How To Stand Up Gitlab In Awsmp","en-us/blog/how-to-stand-up-gitlab-in-awsmp.yml","en-us/blog/how-to-stand-up-gitlab-in-awsmp",{"_path":2935,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2936,"content":2942,"config":2947,"_id":2949,"_type":13,"title":2950,"_source":15,"_file":2951,"_stem":2952,"_extension":18},"/en-us/blog/how-to-strengthen-agile-teams-with-tuckmans-model",{"title":2937,"description":2938,"ogTitle":2937,"ogDescription":2938,"noIndex":6,"ogImage":2939,"ogUrl":2940,"ogSiteName":685,"ogType":686,"canonicalUrls":2940,"schema":2941},"Strengthen your Agile teams with Tuckman's stages of group development","Learn how to build up your agile teams teams after breaking down silos for further group development","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680924/Blog/Hero%20Images/tuckmansstages.jpg","https://about.gitlab.com/blog/how-to-strengthen-agile-teams-with-tuckmans-model","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Strengthen your Agile teams with Tuckman's stages of group development\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-12-13\",\n }",{"title":2937,"description":2938,"authors":2943,"heroImage":2939,"date":2944,"body":2945,"category":300,"tags":2946},[951],"2019-12-13","\n\nThe silos between development and operations teams are a common source of friction and bottlenecks. When teams battle silos, cycle time increases and business value stalls. Recently, software leaders have learned how to break down silos through communication and collaboration, but learning how to rebuild teams is a greater challenge. How can teams come together when their traditional behaviors and relationships have changed?\n\n## The answer: Tuckman's stages of group development\n\nIn 1965, psychologist Bruce Tuckman [published a study on the developmental sequence in small groups](http://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Group_Dynamics/Tuckman_1965_Developmental_sequence_in_small_groups.pdf). His findings highlighted the importance of four stages of development - forming, storming, norming, and performing - in order for a group to ideate, collaborate, plan, and deliver. \n\n**In the forming stage**, groups identify challenges and goals. Team members orient themselves to acceptable interpersonal behaviors and test boundaries to guide their interactions. **In the storming stage**, team members build trust by sharing their thoughts, which oftentimes leads to conflict, and discover various working styles. **In the norming stage**, the group resolves their differences and begins building a stronger sense of community and closeness. Individuals understand that they have common goals and must work together to achieve them. **In the performing stage**, the team achieves goals, functions independently, and resolves conflicts. Team members support each other and are more flexible in their roles.\n\n## How to strengthen Agile teams\n\nWhen leaders break down silos, team members often feel adrift due to the sudden cultural shift. To prevent a dysfunctional culture in which individuals don’t trust and support each other, leaders must make group development a priority. Applying Tuckman’s four stages to [Agile team development](/solutions/agile-delivery/) can result in a stronger dynamic. \n\n### Forming\n\nWhen management forms an Agile team, considering strengths and skills is a necessary aspect of purposefully curating a team. Team members should complement each other but not mirror each other, since the goal of an Agile team is to have a cross-functional team in which various members bring their strengths to work together. \n\nAfter eliminating silos, leaders must model and identify the behavior they want the team to adopt. Team members will look to a leader, such as a Scrum Master, for guidance. It’s typical for individuals to focus solely on their work rather than view the team as a collective entity working towards a goal. When this happens, it’s up to the Scrum Master to help individuals develop a shared mentality. After each ideation or sprint, the Scrum Master should gather the team to conduct a retrospective to understand what went well, what went wrong, and how to improve during the next ideation. Team members can work together to identify goals, assisting in the development of a sense of community. \n\n### Storming\n\nOnce individuals begin to see each other as teammates, conflict can arise, since people feel more comfortable sharing their opinions. When rebuilding teams after eliminating silos, it’s natural for individuals to shift blame onto others, so the goal in this stage is to cultivate trust, communication, and collaboration. \n\nThe Scrum Master is responsible for helping teammates resolve conflict, manage tension, and coach behaviors. As a calming influence on the team, the Scrum Master can quickly resolve conflicts and help the team remain productive. By documenting decisions, committing to transparency and visibility, and collaborating to determine solutions, teams can create an open culture in which experimentation is embraced and shortcomings are viewed as learning opportunities. Team members should continue to feel safe dissenting and sharing thoughts, but the focus should be on continuous improvement and identifying solutions rather than placing blame. \n\n### Norming \n\nTransitioning from Storming to Norming can be a difficult endeavor for many Agile teams, but once the shift is made, the focus becomes empowerment and implementation. After learning how to resolve conflict in the previous stage, the team is now able to embrace differences and view challenges from multiple perspectives. \n\nRetrospectives should become a ritual that occurs after each sprint. When the team moves to Norming, the next retro should set aside time to plan for sustainable delivery. The Scrum Master and other leaders should provide feedback to team members, while teammates provide feedback on processes and workflows. At this point in the group’s development, the individuals see themselves as part of a team working towards shared goals. There is mutual trust and open communication, and the team works together as a cohesive unit.\n\n### Performing\n\nAt this stage, the team is highly motivated and interested in expanding their efforts. Leadership should assume a supporting role, since the team now functions autonomously with an emphasis on continuous learning. Because teams seek to improve, they’re able to identify bottlenecks, the potential for silos, and impediments to innovation. \n\nThe team is now fully formed and productive. Individuals collaborate and communicate well, and they have a strong sense of identity and vision. The Agile team consistently delivers and embraces change. \n\nAny time groups evolve or new leadership walks through the door, teams can feel insecure and relive one or more of these stages. By implementing these techniques with your team, you can support your team’s growth and development, helping them maintain a strong Agile methodology and culture.\n\nCover image by [Markus Spiske](https://unsplash.com/@markusspiske?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/vrbZVyX2k4I)\n{: .note}\n",[891,9,912],{"slug":2948,"featured":6,"template":698},"how-to-strengthen-agile-teams-with-tuckmans-model","content:en-us:blog:how-to-strengthen-agile-teams-with-tuckmans-model.yml","How To Strengthen Agile Teams With Tuckmans Model","en-us/blog/how-to-strengthen-agile-teams-with-tuckmans-model.yml","en-us/blog/how-to-strengthen-agile-teams-with-tuckmans-model",{"_path":2954,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2955,"content":2961,"config":2966,"_id":2968,"_type":13,"title":2969,"_source":15,"_file":2970,"_stem":2971,"_extension":18},"/en-us/blog/how-tomorrows-tech-affects-sw-dev",{"title":2956,"description":2957,"ogTitle":2956,"ogDescription":2957,"noIndex":6,"ogImage":2958,"ogUrl":2959,"ogSiteName":685,"ogType":686,"canonicalUrls":2959,"schema":2960},"What devs need to know about tomorrow’s tech today","From 5G to edge computing, microservices and more, cutting-edge technologies will be mainstream soon. We asked more than a dozen DevOps practitioners and analysts which technologies developers need to start to understand today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681675/Blog/Hero%20Images/future-of-software-what-developers-need-to-know.png","https://about.gitlab.com/blog/how-tomorrows-tech-affects-sw-dev","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What devs need to know about tomorrow’s tech today\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2020-10-21\",\n }",{"title":2956,"description":2957,"authors":2962,"heroImage":2958,"date":2963,"body":2964,"category":693,"tags":2965},[846],"2020-10-21","\n\n_This is part two of our four-part series on the future of software development. [Part one](/blog/software-developer-changing-role/) examines how the software developer role is changing. Part three looks at [the role artificial intelligence (AI) will play in software development](/blog/ai-in-software-development/), and part four tackles [how to future-proof your developer career](/blog/future-proof-your-developer-career/)._\n\nIf it feels like we’ve been talking about future tech like 5G and edge computing forever, we have. But they’re getting closer to reality which means they should be on a developer’s radar. We asked 14 DevOps practitioners, analysts and GitLab experts which technologies are most likely to have an impact on software development in the next three to five years. Here’s what they said.\n\n## Edge computing comes of age\n\nThe fast-growing Internet of Things (IoT) market – worth $212 billion in 2019 and projected to hit 1.6 trillion in 2025 [according to market research firm Statista](https://www.statista.com/statistics/976313/global-iot-market-size/) – means edge computing may be coming to your DevOps team sooner than you think. Edge computing will challenge developers to literally put processing power within the application (on the “edge,” in other words) rather than having to reach out to the cloud for computations.\n\nToday’s edge computing is largely confined to telecom companies, says [Carlos Eduardo Arango Gutierrez](https://www.linkedin.com/in/eduardo-arango/?originalSubdomain=co), a software engineer at Red Hat (and a [GitLab Hero](/community/heroes/)), but in three to five years he sees front end developers needing to get a handle on this. “Part of my work at RedHat now is a lot of IoT and edge computing and I think every Kubernetes developer today is going to need to be thinking about it,” he says. “Developers are going to need to be thinking about networking but also about new types of routers and hardware architectures to support this.”\n\n## 5G is happening\n\nDespite the immense hype, a 5G wireless network rollout is underway around the world (here’s [an interactive map](https://www.speedtest.net/ookla-5g-map)). Statista predicts between [20 and 50 million 5G connections](https://hackernoon.com/top-10-software-development-trends-for-2020-you-need-to-know-as293690) as soon as the end of next year. Even if that forecast is optimistic, 5G will shortly upend mobile application use as we know it, and thus mobile application development. Dramatically faster download and upload times will give developers the chance to create more-feature-rich applications with better user experiences including potentially both [augmented](https://www.fi.edu/what-is-augmented-reality) and [virtual reality](https://www.wired.com/story/wired-guide-to-virtual-reality/).\n\n## Really, it’s about networking\n\nThat’s all a long way of saying that these cutting edge technologies are going to require developers to understand how to tie them neatly together. “In the future it doesn’t matter if you’re going to be good at the front end and know languages like Go or Java,” Carlos says. “You’re going to need to understand everything about networking. That’s critical to the future.”\n\n## Hardware becomes a factor\n\nSoftware developers tend to take hardware for granted, and why not? Today one phone or laptop is very much like the other but in a few years that will no longer be true. “As the speed of connectivity continues to evolve and as we hit certain thresholds we need to think about how we design solutions to take advantage of that,” says [Rafael Garcia](https://www.linkedin.com/in/jrafaelgarcia/), director of digital services at insurance conglomerate Aflac. “When storage became cheap it changed how you designed solutions and now with connectivity and broadband you don’t have to be worried about size anymore,” he says.\n\nSize is one consideration but there are many others, Carlos adds. Developers must move past the “if it works on a laptop it works everywhere” model and realize the production clusters and the distributed systems will have entirely different requirements for everything from design to security. “In the future, software developers need to understand the world is not your laptop,” he says.\n\n## Code (or secrets), heal thyself\n\nThe idea of self-healing code is something every DevOps team can embrace and it’s something GitLab CEO [Sid Sijbrandij](/company/team/#sytses) sees as a viable possibility. As an early example of this Sid points to [Kubernetes custom resource definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) because they automatically know the state they should be in. “Viewed through a different lens it’s the same thing in technologies like [Vault](https://www.vaultproject.io),” he explains. “Instead of secrets in a company system lasting for years or months it has dynamic secrets that continually refresh. It’s self-healing for secrets.”\n\n## Microservices go mainstream\n\nYour DevOps team may not have jumped on the [microservices](/topics/microservices/) bandwagon yet – in our 2020 survey only 26% of respondents fully use them – but Sid says they’re key to the future. It will also be important to know how to manage them, he says. “The interactions between services are going to be important particularly when it comes to distributed systems. We’re going to need technology for tracing and troubleshooting services.”\n\n_Why isn’t AI on this list? It’s so critical to the future it will be covered in part three of this series._\n",[695,2382,9],{"slug":2967,"featured":6,"template":698},"how-tomorrows-tech-affects-sw-dev","content:en-us:blog:how-tomorrows-tech-affects-sw-dev.yml","How Tomorrows Tech Affects Sw Dev","en-us/blog/how-tomorrows-tech-affects-sw-dev.yml","en-us/blog/how-tomorrows-tech-affects-sw-dev",{"_path":2973,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2974,"content":2980,"config":2986,"_id":2988,"_type":13,"title":2989,"_source":15,"_file":2990,"_stem":2991,"_extension":18},"/en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"title":2975,"description":2976,"ogTitle":2975,"ogDescription":2976,"noIndex":6,"ogImage":2977,"ogUrl":2978,"ogSiteName":685,"ogType":686,"canonicalUrls":2978,"schema":2979},"How we are closing the gap on replicating *everything* in GitLab Geo","Developing an internal framework to enable other teams to add Geo support for their features","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669673/Blog/Hero%20Images/engineering.png","https://about.gitlab.com/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we are closing the gap on replicating *everything* in GitLab Geo\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Kozono\"}],\n \"datePublished\": \"2021-04-29\",\n }",{"title":2975,"description":2976,"authors":2981,"heroImage":2977,"date":2983,"body":2984,"category":716,"tags":2985},[2982],"Michael Kozono","2021-04-29","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn early 2020, it took 3.5 months of solid work to implement replication of a new data type in Geo. One year later, support can be added within a month -- including development and all required reviews. How did we do it? First, let me introduce you to Geo.\n\n## What is Geo?\n\n[GitLab Geo](https://about.gitlab.comhttps://docs.gitlab.com/ee/administration/geo/index.html) is the solution for widely distributed development teams and for providing a warm-standby as part of a disaster recovery strategy. Geo replicates your GitLab instance to one or more local, read-only instances.\n\n## What are data types?\n\n[GitLab Geo was released in June 2016 with GitLab 8.9](https://about.gitlab.com/releases/2016/06/22/gitlab-8-9-released/#gitlab-geo-new-product) with the ability to replicate project repositories to a read-only secondary GitLab site. Developers located near secondary sites could fetch project repositories as quickly as if they were near the primary.\n\nBut what about wiki repositories? What about LFS objects or CI job artifacts? In GitLab, each of these things is represented by different Ruby classes, database tables, and storage configurations. In Geo, we call these data types.\n\n## Is it really that hard to copy data?\n\nWhen we say a new data type is supported by Geo, this is what we mean:\n\n* Backfill existing data to Geo secondary sites\n* As fast as possible, replicate new or updated data to Geo secondary sites\n* As fast as possible, replicate deletions to Geo secondary sites\n* Retry replication if it fails, for example due to a transient network failure\n* Eventually recover missing or inconsistent data, for example if Sidekiq jobs are lost, or if infrastructure fails\n* Exclude data according to [selective sync settings](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) on each Geo secondary site\n* Exclude remote stored data unless [Allow this secondary node to replicate content on Object Storage](https://docs.gitlab.com/ee/administration/geo/replication/object_storage.html#enabling-gitlab-managed-object-storage-replication) is enabled on a Geo secondary site\n* Verify data integrity against the primary data, after replication\n* Re-verify data integrity at regular intervals\n* Report metrics to Prometheus\n* Report metrics in the Admin UI\n* View replication and verification status of any individual record in the Admin UI\n* Replication and verification job concurrency is configurable in Admin UI\n* Retry replication if data mismatch is detected ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/301244))\n* Allow manual re-replication and re-verification in the Admin UI ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/216100))\n* And more\n\n## How to iterate yourself into a problem\n\n[Iteration is a core value](https://handbook.gitlab.com/handbook/values/#iteration) at GitLab. In the case of Geo, by [GitLab 12.3](https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#geo-natively-supports-docker-registry-replication) we had added replication support for the most important data types, for example:\n\n* Project Git repositories\n* Project wiki Git repositories\n* Issue/MR/Epic attachments\n* LFS objects\n* CI job artifacts\n* Container/Docker registry\n\nAnd we had added a slew of features around these data types. But suddenly it was clear we had a problem. **We were falling behind in the race to replicate and verify all of GitLab's data.**\n\n* A new data type was being added by other teams, every few months. It was painful to prioritize 3 months of development time only to add replication to one data type. And even if we caught up, the latest features would always be unsupported by Geo for 3 months.\n* Automatic verification of Project and Wiki repositories was implemented, but adding it to a single data type was going to take 3 months.\n* Maintenance and other new features were increasing in effort due to the amount of code duplication.\n* Our event architecture needed too much boilerplate and overhead to add new events\n\n## How to iterate yourself out of a problem\n\nJust because it's possible to iterate yourself into a problem doesn't mean iteration failed you. Yes, ideally we would have seen this coming earlier. But consider that fast and small iteration has likely saved many hours of upfront work on features that have been quickly validated, and have since been changed or removed. It's also possible to [DRY up](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) code too soon into bad abstractions, which can be painful to tear apart.\n\nBut we reached a point where everyone agreed that the most efficient way forward required consolidating existing code.\n\n### Do the design work\n\n[Fabian](https://gitlab.com/fzimmer), our esteemed product manager, [proposed an epic](https://gitlab.com/groups/gitlab-org/-/epics/2161):\n\n> to build a new geo replication and verification framework with the explicit goal of enabling teams across GitLab to add new data types in a way that supports geo replication out of the box\n\nMost of the logic listed above in [Is it really that hard to copy data?](#is-it-really-that-hard-to-copy-data) is exactly the same for all data types. An internal framework could be used to significantly reduce duplication, which could deliver huge benefits:\n\n* Bugs in the framework only have to be fixed once, increasing reliability and maintainability.\n* New features could be added to the framework for all data types at once, increasing velocity and consistency.\n* Implementation details would be better hidden. Changes outside the framework become safer and easier.\n\nThe proposal went further than making it easy for *ourselves* to add Geo support to new data types. The goal was to make it easy for *non-Geo engineers* to do so. To achieve this goal, the framework must be easy to use, easy to understand, and well-documented. Besides the usual benefits of reducing duplication, this higher standard would help:\n\n* Minimize the effort to implement Geo support of new features, whether it's done by a Geo engineer or not.\n* Minimize lag time to add Geo support. If it's easy to do, and anyone can do it, then it's easy to prioritize.\n* Increase awareness in other teams that new features may require Geo support.\n* Influence the planning of new features. There are ways to make it more difficult to add Geo support. This is much easier to avoid during initial planning.\n\nAs a first step, Fabian [proposed creating a proof of concept of a framework](https://gitlab.com/gitlab-org/gitlab/-/issues/35540) leveraging lessons learned and incorporating improvements we already wanted to make to the existing architecture. The issue stimulated lots of design discussion in the team, as well as multiple POCs riffing off one another.\n\nThe biggest change was the introduction of a `Replicator` class which could be subclassed for every data type. The subclasses would contain the vast majority of the specifics to each data type.\n\nIn order to further reduce duplication, we also introduced the concept of a `Replicator strategy`. Most data types in GitLab could be categorized as blobs (simple files) or Git repositories. Within these categories, there was relatively little logic that needed to be specific to each data type. So we could encapsulate the logic specific to these categories in strategies.\n\nAnother significant decision was to make the event system more flexible and lightweight. We wanted to be able to quickly implement new kinds of events for a `Replicator`. We decided to do this without rewriting the entire event processing layer, by packaging and transmitting `Replicator` events within a single, generic event leveraging the existing heavyweight event system. We could then leave the old system behind, and after migrating all data types to the framework, we could easily replace it.\n\nOnce a vision is chosen, it can be difficult to see how to get there with small iterations. But there are often many ways to go about it.\n\n### Code\n\n#### High-level approach\n\nAt a high-level, we could have achieved our goal by taking two data types that were already supported, DRYing up their code, and refactoring toward the desired architecture. This is a proven, safe, and effective method.\n\nBut to me it felt more palatable overall to deliver customer value along the way, by adding support for a brand-new data type while developing the reusable framework. We already had practice implementing many data types, so there was little risk that we would, for example, take too long or use suboptimal abstractions. So we decided to do this with [Package registry](https://docs.gitlab.com/ee/user/packages/).\n\n#### Lay the foundation\n\nOur POCs already answered the biggest open questions about the shape of the architecture. The next step was to get enough of a skeleton merged, as quickly as possible, so that we could unlock further parallel work. To ensure correctness, we aimed to get something working end-to-end. We decided to implement \"replication of newly created Package files\". Much was left out, for example:\n\n* Replication of changes. (Most Blob types, including Package files, are immutable anyway)\n* Replication of deletes\n* Backfill of existing files\n* Verification was left out entirely from the scope of the first epic, since we already knew replication alone provides most of the value to users.\n\nSince the work still required many specific design decisions, we decided to [pair program](https://en.wikipedia.org/wiki/Pair_programming). [Gabriel Mazetto](https://gitlab.com/brodock) and I used [Zoom](https://zoom.us/) and [Visual Studio Live Share](https://visualstudio.microsoft.com/services/live-share/), which worked well for us, though there are many options available. [See a recording of our first call](https://www.youtube.com/watch?v=2XedCiU634s).\n\n[The spike](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23447) was merged and we thought ourselves safe under the feature flag. Looking back on this particular merge request, we did make a couple mistakes:\n\n1. An [autoloading bug was discovered](https://gitlab.com/gitlab-org/gitlab/-/issues/202044). The merge request was reverted, fixed, and remerged. Thanks to [CI](https://docs.gitlab.com/ee/ci/) and end-to-end QA tests using actual builds, the impact was limited.\n1. The size of the spike was unnecessarily large and difficult to review for a single merge request. As it grew, we should have used it as a \"reference\" merge request from which we could break out smaller merge requests. Since then, GitLab policies have further emphasized [smaller iterations](https://handbook.gitlab.com/handbook/product/product-principles/#iteration).\n\n#### Build on the foundation\n\nWith the skeleton of the framework in the main branch, we could implement multiple features without excessive conflicts or coordination. The feature flag was enabled on [GitLab's staging environment](https://about.gitlab.com/handbook/engineering/development/enablement/systems/geo/staging.html), and each additional slice of functionality was tested as it was merged. And new issues for bugs and missing features were opened.\n\nWe built up the [developer documentation](https://docs.gitlab.com/ee/development/geo/framework.html) as we went along. In particular, we documented specific instructions to implement a new data type, aimed at developers with no prior knowledge of Geo. These instructions have since been moved to issue templates. For example, [this is the template for adding support to a new Git repository type](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Geo%20Replicate%20a%20new%20Git%20repository%20type.md). This caught a lot of would-be pain points for users of the framework.\n\nFinally, we released [Geo supports replicating GitLab Package Registries in GitLab 13.2](https://about.gitlab.com/releases/2020/07/22/gitlab-13-2-released/#geo-supports-replicating-gitlab-package-registries)!\n\n## Reaping the benefits\n\nFollowing the release of Geo support for Package Registries, we added support for many new data types in quick succession. Automatic verification was added to the framework. This recently culminated in a non-Geo engineer implementing replication *and verification* for a new data type, within one month!\n\n* In GitLab 13.5, [Geo replicates external merge request diffs and Terraform state files](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#geo-replicates-external-merge-request-diffs-and-terraform-state-files). These were added by Geo engineers who had been less involved in building the framework. Many refinements to the framework, and especially to the documentation, came out of this.\n* In GitLab 13.7, [Geo supports replicating Versioned Snippets](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#geo-supports-replicating-versioned-snippets). This was also added by a Geo engineer, and it was the first Git repository type in the framework, so it required more work than adding new Blob types.\n* In GitLab 13.10:\n * [Geo supports replicating Group wikis](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-supports-replicating-group-wikis) was implemented by a non-Geo engineer.\n * [Geo verifies replicated package files](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-verifies-replicated-package-files). This was a big new feature in the framework, adding automatic verification to any data type that can be checksummed.\n* GitLab 13.11:\n * [Geo supports Pipeline Artifacts](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-supports-pipeline-artifacts) was implemented by a non-Geo engineer.\n * [Geo verifies replicated Versioned Snippets](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-verifies-replicated-versioned-snippets).\n* GitLab 13.12:\n * [An already supported data type, LFS objects, is migrated to the framework under feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/276696). Following this will be the migration of \"Uploads\" and \"CI Job artifacts\", and then **deleting thousands of lines of code**. This should improve both reliability and velocity, for example, verification will be added to these data types.\n\nIn aggregate:\n\n* In GitLab 12.9, we replicated ~56% of all data types (13 out of 23 in total) and verified ~22%.\n* In GitLab 13.11, we replicate ~86% of all data types (25 out of 29 in total) and verify ~45%.\n* **In the last year, GitLab released six new features that needed Geo support. We replicate 100% of those new features and verify ~57%.**\n\n## What did it cost?\n\nFor comparison, it took around 3.5 months to [implement replication of Design repositories](https://gitlab.com/groups/gitlab-org/-/epics/1633). It took around 6 months to [implement the framework for replication of Package files](https://gitlab.com/groups/gitlab-org/-/epics/2346). So the cost to produce the framework for replication was roughly 2.5 months of work.\n\nWe don't really have a comparable for [implementation of verification](https://gitlab.com/groups/gitlab-org/-/epics/1817), but it looked like it would take about 3 months to implement for a single data type, while it took about 4 months total to implement for Package files and simultaneously add to the framework, for a cost of about 1 month.\n\nGiven that new data types now take about 1 month to implement replication *and verification*, the work to produce the framework **paid for itself with the implementation of a single data type**. All the rest of the benefits and time saved are more icing on the cake.\n\nMy only regret is that we should have done it sooner. I intend to be more cognizant of this kind of opportunity in the future.\n\n## What to expect in the future\n\n* [Already supported data types will be migrated into the framework](https://gitlab.com/groups/gitlab-org/-/epics/3588)\n* New features will be added more quickly, for example, verification will be rolled out for all [Blob](https://gitlab.com/groups/gitlab-org/-/epics/5285) and [Git repository](https://gitlab.com/groups/gitlab-org/-/epics/5286) data types\n* Duplication will be further reduced, for example, by [leveraging Rails generators](https://gitlab.com/gitlab-org/gitlab/-/issues/326842)\n\nHuge thanks to everyone who contributed to closing the gap on replicating *everything* in Geo!\n",[891,9,1096,829,934,1097,912],{"slug":2987,"featured":6,"template":698},"how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","content:en-us:blog:how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","How We Are Closing The Gap On Replicating Everything In Gitlab Geo","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"_path":2993,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":2994,"content":3000,"config":3006,"_id":3008,"_type":13,"title":3009,"_source":15,"_file":3010,"_stem":3011,"_extension":18},"/en-us/blog/how-we-increased-our-release-velocity-with-gitlab",{"title":2995,"description":2996,"ogTitle":2995,"ogDescription":2996,"noIndex":6,"ogImage":2997,"ogUrl":2998,"ogSiteName":685,"ogType":686,"canonicalUrls":2998,"schema":2999},"How we increased our release velocity with GitLab","Learn Evolphin's challenges, reasons for choosing the DevSecOps platform, and our end state following the transition.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668437/Blog/Hero%20Images/faster-cycle-times.jpg","https://about.gitlab.com/blog/how-we-increased-our-release-velocity-with-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we increased our release velocity with GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rahul Bhargava, CTO, Evolphin\"}],\n \"datePublished\": \"2022-12-05\",\n }",{"title":2995,"description":2996,"authors":3001,"heroImage":2997,"date":3003,"body":3004,"category":1304,"tags":3005},[3002],"Rahul Bhargava, CTO, Evolphin","2022-12-05","\nAt Evolphin, we have a remotely-distributed software development team creating the [Evolphin Zoom Media Asset Management system](https://evolphin.com/media-asset-management/). Our core R&D team is split across multiple geographies, with staff in India, the U.S., and the Philippines, as well as freelancers around the world. We needed to find new ways to address our team challenges and increase the pace of delivery of our product updates to Evolphin Zoom suite, in response to our customer needs. This blog outlines our challenges, reasons for choosing GitLab, and our end state, including a 30% to 40% increase in our release velocity, following the transition.\n\n## What is a media asset management system? \n\nWith the increased demand for video content for entertainment, marketing, customer engagement, etc., media asset management systems have become increasingly popular for collaborating, organizing, and archiving rich media assets. \n\nThe assorted camera card types, encoding formats, and publishing demands of social media and other video-on-demand services create a heterogenous content creation and publishing industry desperate for order. Media asset management systems are a timely answer to the problem of managing and unifying the diverse media assets characteristic of the industry.\n\nAt Evolphin, we’re at the heart of this solution with the Evolphin Zoom Media Asset Management system, an enterprise offering that runs on approximately 4.7 million lines of source code. To address the root of the problem, media asset management products like Evolphin Zoom must rapidly evolve - add new or enhance existing features - to meet customers’ ever-changing needs.\n\n## The problem: Slow updates\n\nBefore adopting GitLab, we used Subversion (Tortoise as the UI) as our source code repository and software version management system. We chose Subversion at the time because we needed an on-premises solution, as cloud-based branch management was not widely adopted in 2012 when we started working on the Evolphin Zoom. \n\nOur branching and merging workflow with Subversion was tedious, slow, and complicated. It took us around four to five weeks to manually manage and merge software changes across branches within this system. This meant that releasing each product update took five weeks at the very minimum. \n\n## Our requirement: Better collaboration for branch management\n\nWe needed a more agile solution to remain responsive to our customers' needs in this fast-paced software development environment. \n\nAs we transitioned to a remotely distributed workforce model, we identified a need for a software version management system designed with decentralized teams in mind. We wanted to be able to create a user story for a new feature in one week, test it with beta users the next week, and release it in production the week after. \n\nFor this level of agility, an affordable, open-source software repository with a platform like GitLab seemed the perfect solution.\n\n## Why GitLab?\n\nWith all the necessary tools for software review management and collaboration, GitLab appeared to fit our needs. \n\nThe ability to remotely check changes into a feature branch meant that users could check in a version and trigger a merge request for approval before merging changes from the remote user’s branch into the main software development branch. \n\nAll these features were available under GitLab’s free community version, with a user-friendly, visually-appealing UI that eased our transition from on-premises to cloud-based development. \n\n## End-state with GitLab\n\nHere is our workflow in numbers:\n\n| Total GitLab projects managed | 44 \t \t\t\t\t\t\t|\t\n| Total branches \t\t\t\t| 514\t \t\t\t\t\t\t|\n| Total repo size\t\t\t\t| 10.03 GB \t\t\t\t\t\t|\n| Total users\t\t\t\t\t| 33\t \t\t\t\t\t\t|\n| Total groups\t\t\t\t\t| 15 \t \t\t\t\t\t\t|\n| MFA-enabled\t\t\t\t\t| Yes \t \t\t\t\t\t\t|\n| Number of files\t\t\t\t| 26125 text files \t\t\t|\n| Number of unique files\t\t| 25090 unique files\t\t\t|\n| Code\t\t\t\t\t\t\t| 4,738,187 lines of code \t \t|\n| GitLab product plan\t\t\t| Community plan on the cloud\t|\n\n\nOur new workflow depends on GitLab as the single source of truth for all our source code, binary dependencies, and DevOps projects. We currently have GitLab integrations with our CI/CD pipeline using Jenkins and our issue-tracking system - JetBrains YouTrack. Besides source code management (SCM), we use code review features frequently. In addition, all our internal docs, requirements gathering, tips and tricks between developers, DevOps, and QA are shared in Wiki. All our collaboration happens over GitLab Wikis and SCM. Our developers and DevOps engineers use the same GitLab repo to make it easy to manage source code and build artifacts for deployment.\n\nSince the pandemic started, we have executed several Amazon Web Services (AWS) cloud-based deployments. Some of our DevOps projects in GitLab are integrated with the AWS cloud formation stacks/scripts to enable consistent tenant deployments for our cloud customers.\n\n## Impact on Evolphin’s customers\n\nThe biggest transformation we noticed from adopting GitLab was a more seamless, collaborative, and efficient workflow for our R&D teams. \n\nFor example, a bug fix could be implemented in branches by developers working in parallel, which could then be merged into a pre-production branch for QA. Following the QA review, changes can be pushed to the main production branch for release. \n\nBeing open source, we can easily integrate with CI/CD platforms and the new workflow significantly improved our productivity regarding feature releases, especially taking into consideration our high volume of product updates. With GitLab, we can execute feature releases two to three weeks faster than previously. This includes twice-monthly feature changes, and monthly security updates, with annual major product changes. Overall, our release velocity increased by 30% to 40% just by switching from Subversion to a GitLab-based workflow.\n\n_Rahul Bhargava is the CTO and founder of Evolphin Software._\n",[2402,9,108],{"slug":3007,"featured":6,"template":698},"how-we-increased-our-release-velocity-with-gitlab","content:en-us:blog:how-we-increased-our-release-velocity-with-gitlab.yml","How We Increased Our Release Velocity With Gitlab","en-us/blog/how-we-increased-our-release-velocity-with-gitlab.yml","en-us/blog/how-we-increased-our-release-velocity-with-gitlab",{"_path":3013,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3014,"content":3020,"config":3025,"_id":3027,"_type":13,"title":3028,"_source":15,"_file":3029,"_stem":3030,"_extension":18},"/en-us/blog/how-we-migrated-our-markdown-processing-to-commonmark",{"title":3015,"description":3016,"ogTitle":3015,"ogDescription":3016,"noIndex":6,"ogImage":3017,"ogUrl":3018,"ogSiteName":685,"ogType":686,"canonicalUrls":3018,"schema":3019},"How we migrated to CommonMark","A senior backend engineer shares how (and why) we migrated our Markdown processing from RedCarpet to CommonMark.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671172/Blog/Hero%20Images/markdown-tutorial-cover.png","https://about.gitlab.com/blog/how-we-migrated-our-markdown-processing-to-commonmark","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we migrated to CommonMark\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Brett Walker\"}],\n \"datePublished\": \"2019-06-13\",\n }",{"title":3015,"description":3016,"authors":3021,"heroImage":3017,"date":990,"body":3023,"category":1053,"tags":3024},[3022],"Brett Walker","\n[Markdown](https://daringfireball.net/projects/markdown/) was originally created by John Gruber as a way of writing readable plain text that can be easily converted into HTML or XHTML. Over the years it has become widely adopted for writing online content, whether it's a blog post, discussion threads, documentation, and even books.\n\n### Why we moved to CommonMark\n\nVarious \"flavors\" of Markdown have been created, each with their own extensions and idiosyncrasies. [GitHub Flavored Markdown](https://github.github.com/gfm/) is one of the most widely used and adopted set of extensions (such as task lists). With all the flavors behaving a little differently, it has become increasingly difficult to write Markdown content and have it [properly rendered everywhere](https://babelmark.github.io).\n\n[GitLab uses Markdown extensively](https://docs.gitlab.com/ee/user/markdown.html) – almost all user-generated content is written in it, from issue and merge request descriptions, to comments and discussions, wiki pages, etc.\n\nThe goal of [CommonMark](https://commonmark.org) is to create \"a strongly defined, highly compatible specification of Markdown\":\n\n> We propose a **standard, unambiguous syntax specification for Markdown**, along with a **suite of comprehensive tests** to validate Markdown implementations against this specification. We believe this is necessary, even essential, for the future of Markdown.\n\nBy adopting CommonMark as standard, we move closer to having Markdown files that are consistently rendered across applications. Ideally, Markdown content should be able to be rendered the same on GitHub, GitLab, or any other Markdown-aware application.\n\nUsers have also opened numerous issues about our Markdown not working as they expected. CommonMark solves most of these problems, and therefore gives our users a more consistent and usable experience.\n\nMany platforms have also migrated to CommonMark, including [GitHub](https://github.com) and [Discourse](https://discourse.org).\n\n### Phases of migration\n\nWe rolled out the migration in phases, wanting to make it as painless as possible. We achieved this with the gracious help of [@blackst0ne](https://gitlab.com/blackst0ne) who started the effort.\n\n#### Phase 1: Only new content\n\nIn the first phase ([GitLab 11.1](/releases/2018/07/22/gitlab-11-1-released/)), we only allowed CommonMark to be used in newly created content, such as issue and merge request descriptions, comments, etc. Any older content, even if edited, would continue to be rendered using RedCarpet.\n\nSince we cache rendered Markdown for performance, we keep a `cached_markdown_version` value in our database. Using this, we were able to determine whether the content should be rendered with CommonMark or not. As the largest version number at the time was 3, we designated version 10 as being the start of any CommonMark cached content. Anything less would be considered RedCarpet markdown.\n\nAdditionally we did not use CommonMark for repository and wiki files. We wanted a [minimal viable change](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) to not only test the waters but minimize any initial problems.\n\n#### Phase 2: Repository and wiki files\n\nThe next step ([GitLab 11.3](/releases/2018/09/22/gitlab-11-3-released/)) was to allow repository and wiki files to be rendered with CommonMark. This was a bigger change in the sense that existing content could potentially look different.\n\nIn practice, RedCarpet and CommonMark are very similar, as would be expected, and are in general compatible. There are a few instances where the syntax is different, such as the indentation needed for bulleted lists inside a numbered list, or the use of superscripts, which CommonMark does not support. For most documents, no change is needed.\n\nHowever we also knew that we couldn't touch user files or do any sort of migration. Instead, we created a [small tool](https://gitlab.com/digitalmoksha/diff_redcarpet_cmark) that can generate the changes necessary for files to be converted. This is done by rendering into HTML using RedCarpet, and then generating CommonMark from it using [Pandoc](https://pandoc.org).\n\n#### Phase 3: CommonMark throughout\n\nThe final phase was to remove RedCarpet completely. By this time, CommonMark had been in use for several months – only older content was still being rendered with RedCarpet. However, we were accumulating technical debt by supporting both methods – new functionality or security fixes had to consider both renderers.\n\nWith RedCarpet removed, we now display older content with CommonMark. Differences are small and only affect a small percentage of the overall content, and the possibility of looking at older issues or merge requests decreases with time.\n\n#### Improvements upstream\n\nThere were a couple of issues we ran into during the implementation where we were able to drive some changes to the upstream libraries.\n\nThe first is that RedCarpet supports using `~~` to indicate using strikethrough. We use [cmark-gfm](https://github.com/github/cmark-gfm) for rendering, giving us both CommonMark and common GitHub Flavored Markdown extensions. And although it supports using any number of tildes for strikethrough, we wanted to make the transition a little easier by [only supporting double tildes](https://github.com/github/cmark-gfm/issues/71). A new option, `CMARK_OPT_STRIKETHROUGH_DOUBLE_TILDE`, was added to [ gjtorikian/commonmarker](https://github.com/gjtorikian/commonmarker/commit/1a973ba872e50b22ee53652ffa12cdfe2fe90155), allowing us to turn on support for double-tilde strikethroughs.\n\nSecond, we found a bug in [gjtorikian/commonmarker](https://github.com/gjtorikian/commonmarker/issues/56), where a `\u003Ctbody>` wasn't getting rendered. This was quickly fixed.\n\nMany thanks to [@kivikakk](https://github.com/kivikakk) and [@gjtorikian](https://github.com/gjtorikian) for their help with these issues.\n\n### Conclusion\n\nThe transition took several months, but we're happy to have moved our Markdown processing to the next level. And should you run into the few problematic edge cases, [diff_redcarpet_cmark](https://gitlab.com/digitalmoksha/diff_redcarpet_cmark) should be able to help.\n",[9],{"slug":3026,"featured":6,"template":698},"how-we-migrated-our-markdown-processing-to-commonmark","content:en-us:blog:how-we-migrated-our-markdown-processing-to-commonmark.yml","How We Migrated Our Markdown Processing To Commonmark","en-us/blog/how-we-migrated-our-markdown-processing-to-commonmark.yml","en-us/blog/how-we-migrated-our-markdown-processing-to-commonmark",{"_path":3032,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3033,"content":3039,"config":3046,"_id":3048,"_type":13,"title":3049,"_source":15,"_file":3050,"_stem":3051,"_extension":18},"/en-us/blog/how-we-optimized-our-infrastructure-spend-at-gitlab",{"title":3034,"description":3035,"ogTitle":3034,"ogDescription":3035,"noIndex":6,"ogImage":3036,"ogUrl":3037,"ogSiteName":685,"ogType":686,"canonicalUrls":3037,"schema":3038},"How we optimized infrastructure spend at GitLab","We keep our cloud spend under control with a spend optimization framework – now we're sharing it with you.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681701/Blog/Hero%20Images/piggy_bank.jpg","https://about.gitlab.com/blog/how-we-optimized-our-infrastructure-spend-at-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we optimized infrastructure spend at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Davis Townsend\"}],\n \"datePublished\": \"2020-10-27\",\n }",{"title":3034,"description":3035,"authors":3040,"heroImage":3036,"date":3042,"body":3043,"category":1053,"tags":3044},[3041],"Davis Townsend","2020-10-27","\n\nInfrastructure spend optimization is a hot topic these days as many established companies are migrating workloads to the cloud. Similarly, fast-growing startups are struggling to control their operating costs as they expand their cloud footprint to meet user demand. \n\nAt GitLab we have taken a methodical and data-driven approach to the problem so we can reduce our cloud spend and control our operating costs, while still creating great features for our customers. We designed a five-stage framework which emphasizes building awareness of our infrastructure spend to the point where any change in costs is well understood and no longer a surprise.\n\nOur framework is very similar to a normal data maturity framework (shown below) that would progress through descriptive, predictive, and finally prescriptive analytics, but we tailor it specifically for this domain. I'll explain each stage and what it looks like at GitLab so you can see how you might apply it to your own organization.\n\n![Normal Data Maturity Framework](https://about.gitlab.com/images/blogimages/2020-10-28-How-We-Optimized-Infra-spend/DMM.jpeg \"Normal Data Maturity Framework\"){: .medium.center}\nA normal data maturity framework \n{: .note.text-center}\n\n## Spend optimization framework\n\n## 1. Basic cost visibility\n This stage can be thought of as data exploration. You just want to understand as much as you can about where you are spending money at a high level. What vendors and services are you spending the most money on? This data is generally provided by cloud vendors through a billing console, as well as through billing exports. I've found the way to get the best use out of both options is to use the provided billing console for answering simple questions about specific costs quickly, and the exports for integrating this data into your own analytics architecture for more granular reporting, [multicloud](/topics/multicloud/) reporting, or for specific recurring reports you need over a longer time horizon.\n \n### GitLab example\nWhen starting out, we looked at Google Cloud Platform (GCP) and their [Default Billing Export](https://cloud.google.com/billing/docs/how-to/export-data-bigquery) to get an overview of which products/projects/SKUs were responsible for the majority of our spend.\n\n## 2. Cost allocation\nThis stage is all about going from high-level areas of spend to more granular dimensions that tie back to relevant business metrics in your company. At GitLab we may want to look at what we spend on particular services like CI runners, or what we spend to support employees using GitLab.com as part of their job vs. customer spend. This data may not be readily available to you so there could be a lot of work involved to tie these sorts of relevant business dimensions back to the cost reports provided by your vendor.\n\n### GitLab example\nFor our production architecture we had some [GCP labels](https://cloud.google.com/compute/docs/labeling-resources) that indicated the internal service applied to the majority of our instances, so we started with those to see which services we spent most of our money on. More recently, we have created a [handbook page for Infrastructure Standards](/handbook/infrastructure-standards/) around project creation and label naming so that we can get even more insight out of our bill.\n\n\n\n## 3. Optimize usage efficiency\nOnce you can allocate costs to their relevant business metrics, then can you start to ask interesting questions such as, “Why is our storage spend so high on feature x?” By asking these questions and then talking with the subject matter experts about these potential areas of optimization you can start to come up with ideas to reduce some of this cost.\n\n### GitLab example\nWhen we reached this stage we began to identify many areas of opportunity, including:\n\n- [CI runners](https://gitlab.com/gitlab-org/gitlab/-/issues/35777): One of the areas discovered from stage 2 happened to be our CI runners, for which we created more granular reporting to see the cost by specific repos, pipelines, and jobs, which allowed us to find some ways to optimize our own internal use of CI.\n- [Object storage](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10087): We discovered high storage costs for outdated Postgres backups. We resolved this by enabling bucket lifecycle policies and reduced our object storage for that bucket by 900TB.\n- [Network usage](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10222): By correlating a recent change in our spend profile to a network architecture change, we were able to highlight the need for additional changes. We ultimately implemented a change to directly download runner artifacts from GCS instead of having the traffic be proxied. This significantly reduced our overall networking cost.\n\n## 4. Measure business outcomes vs spend\n\nWhen you get to a point for a particular area where you feel like you have done all the basic optimizations and aren't sure where else you could reduce cost without seriously impacting your employees or customers, you have reached stage 4. This stage is all about analyzing the value of more complex changes that could reduce spend at the expense of something else, as well as considering the value and cost impact of major feature or architectural changes in the future.\n\n### GitLab example\nOur best example of this was our recent rollout of [advanced global search](https://docs.gitlab.com/ee/user/search/advanced_search.html) to all paid users on GitLab.com. In the first iterations of testing for this feature our costs were exceptionally high. Through a lot of hard work by the team responsible for the feature, they were able to significantly bring down the costs while improving functionality. Through those efforts, GitLab was able to bring this great feature to the platform in a way that also made sense from a business perspective.\n\n## 5. Predict future spend and problem areas\nOnce your company has matured the practices above, you can start to become proactive about observing cost. You can also begin to detect and alert when spend is outside expected thresholds. Once you get to this point, infrastructure optimization should become a boring topic, and when you no longer have any cases of huge unexpected cost increases that were not due to unexpected increases in customer demand, you know you are doing a great job.\n\n### GitLab example\n\nWe’re still working on this stage ourselves. While we’ve had some success in detecting unexpected spend, and even tying it to anomalous behavior in our platform, we recognize we have much more to do here. We are still working to get most of our usage to Stages 3-4, while spending parallel effort to reach Stage 5 for some more mature workloads.\n\n## Current state and next steps\nToday at GitLab, depending on the workload, we are anywhere between stages 1-4. The bulk of the work is going into getting everything to at least stage 2, and from there we can work on getting everything to stages 3-4. Current efforts include applying our newly created [infrastructure standards](/handbook/infrastructure-standards/) across all of our infrastructure, bringing in relevant product usage data from our various services, and giving PMs the tools they need to better manage the cost of their services through a single source of truth of base level cost metrics.\n\n## Workflow and planning\nCost optimization is a difficult topic to tackle effectively as it involves many different stakeholders across the business who all have their own priorities. The way we are taking this problem on at GitLab is we have an [issue board](https://gitlab.com/groups/gitlab-com/-/boards/1502173?label_name[]=infrafin) where we plan and track progress on issues related to infrastructure spend. For all the major initiatives we assign priority to these based on four factors:\n\n1. Cost savings\n2. Customer impact \n3. Future potential cost impact\n4. Effort required\n \nThese factors are discussed and reviewed by our analyst, our SaaS offering product manager, and the relevant subject matter expert for the area. Once the priority is agreed upon, the product manager works with various product teams to get these scheduled into milestones or backlog queues for the teams that need to implement the changes. Progress is tracked on the issue board, and reviewed for priority to ensure the solution moves forward at an appropriate velocity.\n\n## More to read\n\nAll of this info and more can be found in our [Cost Management Handbook](/handbook/engineering/infrastructure/cost-management/). We continue to improve this page to provide our own employees with the resources they need to understand this topic better, as well as providing external viewers some idea of how they could think about infrastructure optimization in their own company.\n\nYou might also enjoy:\n* [What we learned after a year of GitLab.com on Kubernetes](/blog/year-of-kubernetes/)\n* [How we migrated application servers from Unicorn to Puma](/blog/migrating-to-puma-on-gitlab/)\n* [How we upgraded PostgreSQL at GitLab.com](/blog/gitlab-pg-upgrade/)\n\nCover image by [Fabian Blank](https://unsplash.com/@blankerwahnsinn?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[786,934,9,3045],"cloud native",{"slug":3047,"featured":6,"template":698},"how-we-optimized-our-infrastructure-spend-at-gitlab","content:en-us:blog:how-we-optimized-our-infrastructure-spend-at-gitlab.yml","How We Optimized Our Infrastructure Spend At Gitlab","en-us/blog/how-we-optimized-our-infrastructure-spend-at-gitlab.yml","en-us/blog/how-we-optimized-our-infrastructure-spend-at-gitlab",{"_path":3053,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3054,"content":3060,"config":3065,"_id":3067,"_type":13,"title":3068,"_source":15,"_file":3069,"_stem":3070,"_extension":18},"/en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"title":3055,"description":3056,"ogTitle":3055,"ogDescription":3056,"noIndex":6,"ogImage":3057,"ogUrl":3058,"ogSiteName":685,"ogType":686,"canonicalUrls":3058,"schema":3059},"How we turned a dull weekly all-hands into a podcast","We love asynchronous communication so much that we turned a uninspiring department-wide meeting into an engaging podcast – here's why and how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671055/Blog/Hero%20Images/headphones-colorful-background.jpg","https://about.gitlab.com/blog/how-we-turned-40-person-meeting-into-a-podcast","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we turned a dull weekly all-hands into a podcast\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lyle Kozloff\"}],\n \"datePublished\": \"2019-06-03\",\n }",{"title":3055,"description":3056,"authors":3061,"heroImage":3057,"date":3062,"body":3063,"category":910,"tags":3064},[1867],"2019-06-03","\nWe’ve all been there: A department all-hands. At GitLab, we’ve got them too. They’re important: There’s information you need to know, and there’s really only one way to handle it. While it’s true that we’re [all-remote](/company/culture/all-remote/), and everyone joins from their location of choice, they’re still:\n\n - Slow\n - Synchronous\n - Soul-sucking\n\nA few months ago, one of our Support Engineering Managers ([Lee](/company/team/#leematos)) proposed that we try and embrace our value of [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) and [transition this agenda-driven meeting into a pure agenda](https://gitlab.com/gitlab-com/support/support-team-meta/issues/1394), and remove the need for face-to-face communication.\n\nMaking a big transition like this did leave us with some concerns:\n\n### Synchronous meetings can be a chance for people to connect\n\nAt GitLab we recognize the value of getting to know one’s teammates. Employees are encouraged to schedule [coffee chats](/company/culture/all-remote/tips/#coffee-chats) throughout their time at GitLab to get to know one another. (In fact, we think it’s so important that it’s one of the key tasks in [new employee onboarding](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/onboarding.md#all-gitlabbers) ) We even have a consistent small group of people many of us meet up with (on video) four days a week [to connect on a purely personal level](https://handbook.gitlab.com/handbook/communication/#breakout-call) built into the company calendar. These calls aren’t forced, but attendance is organic and inviting, because you will start to build connections. This is especially important in an all-remote organization.\n\nTeam-level meetings can also be an important time to sync up and have time to banter and share personalities. However, we noticed that as the room grew these interactions became less natural. Within the structure of the meeting we tried to correct this with process: Rotating meeting chairs, asking people to post a “Friday Song,” and including a specific meeting section called “Cheerful Banter.” It didn’t work.\n\nUltimately it was a subset of voices who felt comfortable participating in these ways. Meetings beyond a certain size appear to lose their value as a chance for connection. They were less a conversation and more an address. As a result, we felt that we’d have more results concentrating on other avenues for the support team to express themselves and get to know one another.\n\n>We tried rotating meeting chairs, asking people to post a “Friday Song,” and including a specific meeting section called “Cheerful Banter.” It didn’t work.\n\n### Synchronous meetings are a scheduled touchpoint\n\nWhile all of our meetings are recorded and can be watched after the fact, there’s still something about having a cadence to the week. If there’s a meeting every Friday, I know that my brain will be getting new information on Fridays.\n\nTransitioning to a meeting where there is no actual meeting left us with the challenge of making sure people read the document regularly.\n\nTo solve this, we have two touch points during the week: On Wednesdays we have an automated Slack reminder to put things in the document. On Fridays, we have an automated cut-off message that starts a Slack thread for discussion of the week's items. This structure gives a little bit of “rails” that really help package up the meeting.\n\n### Synchronous meetings (at GitLab) can be a chance to absorb while working on something else\n\nThere’s something about having the ability to turn off your camera (or watch the video after the fact). I, personally, enjoy having the space that being an inactive participant in a conversation allows. I’ll often chop vegetables, fold laundry, or go for a run while listening along.\n\nIn fact, this type of passive listening while working on something else is not discouraged at GitLab, in fact it’s [actively encouraged in our handbook](https://handbook.gitlab.com/handbook/communication/#video-calls).\n\nAs we discussed the idea of changing this meeting, we thought it would work best if there was a format that would be efficient and multi-channel. As a big fan of podcasts myself, I thought that the format might work well.\n\n### Putting it together\n\nIf you’re interested in the nitty gritty details, we’ve made a [workflow about how the podcast is actually put together](/handbook/support/workflows/how-to-WIR-podcast.html) in the Handbook.\n\n![Slackbot reminder](https://about.gitlab.com/images/blogimages/slackbot-week-in-review.png){: .shadow.medium.center}\nSlackbot reminds us to add content to the document every Wednesday\n{: .note.text-center}\n\nBriefly, one or more team members will first take a look at each of the links in a the \"Week in Review\" document and the surrounding narrative to build out a script. They'll next pull metrics from our dashboards surrounding our [performance indicators](https://about.gitlab.com/company/kpis/#engineering-kpis) and other numbers we're tracking, like the [number of pairing sessions](https://gitlab.com/gitlab-com/support/support-training/milestones/7). Finally, all together the final recording, mixing and exporting happens – all before 12:00pm PST when a Slackbot announces the release.\n\nAll said, in many ways the ‘new’ format mirrors the old. We still move issues forward, make announcements, thank one another, review our metrics, and tell personal stories. Managers still wax poetic about the things that managers wax poetic about. Team members (probably) still roll their eyes. The biggest difference is that we’ve compressed an hour of “chair time” for 40 people into 10-15 minutes of anything time. And the data is still shareable, and readable too. I call that a win/win/win.\n\nWant to hear what it actually sounds like? Check out our [Support Week in Review from May 31, 2019](https://drive.google.com/open?id=1irQgehSpD2lxxYHQoQh4gBsHnZQLLMj9).\n\nIn what ways can you more efficiently organize and disseminate information in your organization? Do you think a podcast would help? Let us know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\nPhoto by Matthieu A on Unsplash\n{: .note}\n",[9,829,934,1097],{"slug":3066,"featured":6,"template":698},"how-we-turned-40-person-meeting-into-a-podcast","content:en-us:blog:how-we-turned-40-person-meeting-into-a-podcast.yml","How We Turned 40 Person Meeting Into A Podcast","en-us/blog/how-we-turned-40-person-meeting-into-a-podcast.yml","en-us/blog/how-we-turned-40-person-meeting-into-a-podcast",{"_path":3072,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3073,"content":3079,"config":3085,"_id":3087,"_type":13,"title":3088,"_source":15,"_file":3089,"_stem":3090,"_extension":18},"/en-us/blog/how-we-used-gitlab-to-automate-our-monthly-retrospectives",{"title":3074,"description":3075,"ogTitle":3074,"ogDescription":3075,"noIndex":6,"ogImage":3076,"ogUrl":3077,"ogSiteName":685,"ogType":686,"canonicalUrls":3077,"schema":3078},"How we use GitLab to automate our monthly retrospectives","How one engineering team is using GitLab CI to automate asynchronous retrospectives, making collaboration across four continents a breeze.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670529/Blog/Hero%20Images/automate-retrospectives.jpg","https://about.gitlab.com/blog/how-we-used-gitlab-to-automate-our-monthly-retrospectives","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we use GitLab to automate our monthly retrospectives\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sean McGivern\"}],\n \"datePublished\": \"2019-03-07\",\n }",{"title":3074,"description":3075,"authors":3080,"heroImage":3076,"date":3082,"body":3083,"category":1053,"tags":3084},[3081],"Sean McGivern","2019-03-07","\n\nAs an [Engineering\nManager] at GitLab I spend most of\nmy working day using GitLab for a variety of tasks – from using [issue boards](/stages-devops-lifecycle/issueboard/) for team assignments, [epics](https://docs.gitlab.com/ee/user/group/epics/) for tracking longer-term initiatives, and [todos](https://docs.gitlab.com/ee/user/todos.html) and notifications to manage my own workflow.\n\nWe also use GitLab in a number of unconventional ways, so I wanted to share with you one interesting use case we've been experimenting with.\n\n[Engineering Manager]: /handbook/engineering/management/\n\n## GitLab stage group retrospectives\n\nEach [stage group](/stages-devops-lifecycle/) at GitLab has its [own retrospective], which then feeds into the\n[GitLab-wide retrospective] we have for each monthly release.\n\n[own retrospective]: /handbook/engineering/management/group-retrospectives/\n[GitLab-wide retrospective]: /handbook/engineering/workflow/#retrospective\n\nThe [Plan team](/handbook/engineering/development/dev/plan/) is fairly widely\ndistributed: we have people on four continents, and only two members of the team\nare even in the same country as each other. We wanted to try [asynchronous\ncommunication] wherever possible, so we used GitLab issues for [our\nretrospectives], too.\n\nA quick note on terminology: we say [team] to refer to a manager – like me – and\ntheir reports. We say [stage group] to refer to the people who work on a\nparticular [DevOps stage], even across multiple teams. The Plan stage group is\neven more widely distributed.\n{: .note}\n\n[team]: /company/team/structure/#team-and-team-members\n[stage group]: /company/team/structure/#stage-groups\n[DevOps stage]: /handbook/product/categories/#devops-stages\n[asynchronous communication]: /handbook/communication#internal-communication\n[our retrospectives]: https://gitlab.com/gl-retrospectives/plan/issues?label_name[]=retrospective\n\n## Automating retrospective issue creation\n\nCreating the retrospective issue was fast, but adding links to notable\nissues that we shipped or that slipped was time consuming and\ntedious. In the spirit of [xkcd 1319], I decided to automate it, so I\ncreated the [async-retrospectives] project. This project makes\nretrospective issue creation a hands-off process:\n\n[xkcd 1319]: https://xkcd.com/1319/\n[async-retrospectives]: https://gitlab.com/gitlab-org/async-retrospectives\n\n1. It uses [scheduled pipelines] to create an issue on the 1st of each\n month. As our [development month] runs from the 8th to the 7th, this\n is a little early, but it allows the team to jot down any thoughts\n they have while they are still working on the release.\n\n ![](https://about.gitlab.com/images/blogimages/how-we-used-gitlab-to-automate-our-monthly-retrospectives/scheduled-pipelines.png){: .shadow}\n2. The issue is created using the standard [GitLab API], using a [protected\n variable] to hold the credentials.\n3. When we create the issue, we use [quick actions] to add the correct\n labels and due date in a convenient way. (This is also possible\n without quick actions, but quick actions are more convenient for me\n personally.)\n4. Another scheduled pipeline runs on the 9th of each month to update\n the existing issue's description with the lists of issues (slipped,\n shipped) I mentioned above.\n\n We make our retrospectives public after we conclude them, so you can see this\n in action on the [11.8 Plan retrospective]:\n\n [![](https://about.gitlab.com/images/blogimages/how-we-used-gitlab-to-automate-our-monthly-retrospectives/11-8-plan-retrospective.png){: .shadow}][11.8 Plan retrospective]\n\n[scheduled pipelines]: https://docs.gitlab.com/ee/ci/pipelines/schedules.html\n[development month]: /handbook/engineering/workflow/#product-development-timeline\n[GitLab API]: https://docs.gitlab.com/ee/api/\n[protected variable]: https://docs.gitlab.com/ee/ci/variables/#protected-variables\n[quick actions]: https://docs.gitlab.com/ee/user/project/quick_actions.html\n[11.8 Plan retrospective]: https://gitlab.com/gl-retrospectives/plan/issues/22\n\nI only intended this for use in Plan, but a nice thing about a company where we\n[give agency] to people to solve their problems is that people like me are able\nto try out things that might not work globally, like this.\n\nAs it happened, it's also been [picked up by other teams and groups]. We\nconfigure the creation in a [YAML file], just like GitLab CI is configured, to\ntry to make it as easy as possible for other managers to contribute and set this\nup for their team.\n\n[give agency]: https://handbook.gitlab.com/handbook/values/#give-agency\n[picked up by other teams and groups]: https://gitlab.com/gitlab-org/async-retrospectives/merge_requests?state=merged\n[YAML file]: https://gitlab.com/gitlab-org/async-retrospectives/blob/master/teams.yml\n\n## Our experience running asynchronous retrospectives\n\n### What works\n\nWe've had a lot of positive experiences from these asynchronous\nretrospectives. In particular:\n\n1. No one is disadvantaged because of their time zone. If we had a video call\n with our time zone spread, we'd have some people on that call in the middle of\n their night, or missing out completely.\n2. Because they are written down from the start, and because comments in GitLab\n are linkable, we can very easily refer to specific points in the future.\n3. Also, because they are written down, the comments can include links to\n specific issues and merge requests to help other people get the same context.\n\n### What needs improvement\n\nAsynchronous retrospectives aren't perfect, of course. Some of the downsides\nwe've noticed are:\n\n1. Video calls are simply better for some things. In particular, the discussion\n does not flow as smoothly in text as it can in a verbal conversation.\n\n We also conduct our [engineering-wide retrospective] in a [public video\n call], so we retain some opportunity for synchronous discussion.\n2. Similarly, team bonding is slower in text than in video calls.\n3. Participation can be lower if it's something you don't have to do right now,\n but can always defer to a later date. We are continually [looking for ways to improve\n this].\n\nOver all, we don't intend to go back to video calls for retrospectives,\nand we're really happy with the results. You can see all public\nretrospectives from the teams and groups at GitLab in the [GitLab\nretrospectives group on GitLab.com].\n\n[engineering-wide retrospective]: https://docs.google.com/document/d/1nEkM_7Dj4bT21GJy0Ut3By76FZqCfLBmFQNVThmW2TY/edit\n[public video call]: /2017/02/14/our-retrospective-and-kickoff-are-public/\n[looking for ways to improve this]: https://gitlab.com/gitlab-org/async-retrospectives/issues/12\n[GitLab retrospectives group on GitLab.com]: https://gitlab.com/gl-retrospectives\n\nPhoto by [Daniele Levis Pelusi](https://unsplash.com/photos/Pp9qkEV_xPk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/automation?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[108,9,934,912],{"slug":3086,"featured":6,"template":698},"how-we-used-gitlab-to-automate-our-monthly-retrospectives","content:en-us:blog:how-we-used-gitlab-to-automate-our-monthly-retrospectives.yml","How We Used Gitlab To Automate Our Monthly Retrospectives","en-us/blog/how-we-used-gitlab-to-automate-our-monthly-retrospectives.yml","en-us/blog/how-we-used-gitlab-to-automate-our-monthly-retrospectives",{"_path":3092,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3093,"content":3099,"config":3104,"_id":3106,"_type":13,"title":3107,"_source":15,"_file":3108,"_stem":3109,"_extension":18},"/en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool",{"title":3094,"description":3095,"ogTitle":3094,"ogDescription":3095,"noIndex":6,"ogImage":3096,"ogUrl":3097,"ogSiteName":685,"ogType":686,"canonicalUrls":3097,"schema":3098},"Improving iteration and collaboration with user stories","From problem validation to implementation, here's the Release Management team workflow for building user-centered features at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681193/Blog/Hero%20Images/blog-user-stories.jpg","https://about.gitlab.com/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Improving iteration and collaboration with user stories\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rayana Verissimo\"}],\n \"datePublished\": \"2020-03-27\",\n }",{"title":3094,"description":3095,"authors":3100,"heroImage":3096,"date":1093,"body":3102,"category":716,"tags":3103},[3101],"Rayana Verissimo","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIncorporating UX into Agile practices is a known challenge on software projects. One of the most common rants from design teams is how Agile does not embrace UX.\n\nGitLab's focus on [results](https://handbook.gitlab.com/handbook/values/#results) empowers us to create processes that work best for us, our organization, constraints, and opportunities. That includes applying Agile principles to efficiently approach how we design our product.\n\nOn GitLab's Release Management team, we rely on [User stories](https://en.wikipedia.org/wiki/User_story) to help Product Designers, Product Managers, and Engineers understand how the features we prioritize affect our end users.\n\nBy expressing one very specific need that a persona has in the format of a user story, our team has seen the following benefits:\n\n1. Keep the scope of feature proposals minimal, while focusing on users instead of solutions.\n1. Engage in a conversation with our engineering team and stakeholders, so they can help raise technical constraints and more easily estimate implementation effort.\n1. Provide an essential foundation for the next phases of design.\n1. Proactively identify follow-up stories to iterate on.\n\n## We base our user stories on real data\n\nTo ensure we're building GitLab features that are relevant to our target market, as a design practitioner, I partner up with [Jackie](https://gitlab.com/jmeshell) (Product Manager) and [Lorie](https://gitlab.com/loriewhitaker) (UX Researcher) to talk to our users, identify patterns, determine priorities, and translate research into actionable insights.\n\nUser stories are just another way to articulate the user insights into the features we prioritize. [Problem validation](https://about.gitlab.com/handbook/product-development-flow/#validation-track) is also key to building strong user stories that will deliver a great user experience.\n\nRemember: great user stories are informed by real user insights! There is no other way to achieve [user-centered design](https://en.wikipedia.org/wiki/User-centered_design).\n\n## How a user story was turned into an MVC for Deploy Freezes\n\nWhen we started talking about the value of being able to restrict deployment time frames and declare accepted windows of code releases in enterprise and regulated industries, our Product Manager turned to customer interviews to [validate our assumptions](https://gitlab.com/gitlab-org/gitlab/issues/39108). We surveyed more than 200 participants and interviewed five customers about what we call [Deploy Freezes](https://gitlab.com/gitlab-org/gitlab/issues/39108). As a result, we were able to understand the interplay of Deploy Freezes with Release Runbooks, as well as how this problem impacts the GitLab stages of Secure and Plan.\n\n### What we learned from problem validation\n\nWe learned that for teams that are not global, the ability to halt [CI/CD deployments](/topics/ci-cd/) in off hours or suspend CI/CD pipelines on weekends when there is limited team availability can be critical. These users were usually configuring Deploy Freeze policies manually or outside of the GitLab system. Interlocking these policies within CI/CD and automation is a must have to support our users.\n\nAdditionally, when looking at [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) Deploy Freezes, our internal customers (Production and Delivery teams at GitLab) may need to support users freezing code deploys as they relate to special events like big company announcements, live streamed content, and holidays.\n\nThe main difference between this and a pipeline implementer for a `.gitlab-ci.yml` file is that the authors of these kinds of pipelines are much less technical, and even editing yaml might be a challenge — though they will still need to understand markdown. The personas responsible for enforcing those policies include: [Release managers (Rachel)](https://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager), [DevOps Engineers (Devon)](https://handbook.gitlab.com/handbook/product/personas/#devon-devops-engineer), [Software Developers (Sasha)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer), and [Development Team Leads (Delaney)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead).\n\nThrough research, we identified that our next focus areas should be setting Deploy Freezes in the UI on a project instance level (and eventually on a group level), having a dashboard to report across environments, and logging failed attempts for deployments during a freeze window.\n\n## From user insights to user stories\n\nAs I start working on the design phase of the [MVC](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc), I'll break my tasks into the following steps:\n\n1. Work with my Product Manager to identify the main user story.\n1. Identify possible scenarios and edge cases with the entire team.\n1. Write acceptance criteria for user stories and create a low-fidelity prototype.\n1. Discuss and iterate with the team, and move the prototype to high fidelity.\n\nThe typical format of a user story is a single sentence: “_As a [type of user], I want to [goal], so that [benefit]_”. Toward the beginning of the design phase, I documented this user story:\n\n> As a DevOps Engineer/Release Manager, I want to specify windows of time when deployments are not allowed for an environment with my GitLab project, so that I can interlock it within CI/CD and automation.\n\nLooking back at the extensive research our Product Manager conducted, as a designer, I am confident that my user story focuses on the right persona and that the scope covers one specific use case (specifying Deploy Freezes on a project level). All other scenarios, such as dashboard, reporting, group level configuration, and auditing are too large for the MVC. This user story also talks about what we are going to build, not how we are going to do it.\n\nIt is important to highlight that for some organizations, the DevOps Engineer and Release Manager personas [merge into one](https://gitlab.com/gitlab-org/ux-research/issues/346), where parties responsible for releases also need to keep a hand in development, creating code and contributing to applications, outside of automation. This is one of the reasons why when designing for Release Management, I need to remember our users might have different levels of familiarity and expectations with developer-centered flows.\n\n## Thinking big as a team\n\nI carefully consider the development proposal and team conversations to understand the goals and constraints that can inform my initial user story. Every single member of the Release Management team is design minded, so collaborating to improve my design proposals is usually a no brainer!\n\nInstead of collecting user stories in our backlog, we groom and refine them on the fly during the planning phase. Being an all-remote company requires some adjustments to my design process, and our team tries to work as asynchronously as possible.\n\nWe tackle collaboration in many different ways: by using issue threads, during Think Big sessions, PM/UX sync calls, 1:1s, and via Slack messages. The most important thing is that every design and technical decision we make is incorporated back into a single source of truth ([SSOT](https://docs.gitlab.com/ee/development/documentation/styleguide/#documentation-is-the-single-source-of-truth-ssot)) -- in our case, the MVC issue.\n\nUpdating the scope and acceptance criteria of issues is a shared responsibility between my Product Manager, the Engineers, and me. We do our best to collect all relevant information, so that our customers and counterparts can have a clear understanding of what we are delivering in the next milestone.\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/SU9mqOUSl1k\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\nOur team (UX, FE, BE, PM) met to discuss the latest decisions made and discoveries about deploy freezes. Watch on [GitLab Unfiltered](https://youtu.be/SU9mqOUSl1k).\n{: .note.text-center}\n\n## Defining the acceptance criteria\n\nDuring our refinement process, I learned from engineering that we could specify timeboxes for the freezes using cron syntax, and that we could reuse this from the existing [Pipeline schedules](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) capability. Hooray! Engineers also proposed that the `gitlab-ci.yml` file would instruct the pipeline to not run per the cron syntax. They also thought that it would be great to automatically retry the job and continue the deployment process when the freeze period was over.\n\nOn the design side, my additional proposal focused on [notifying users on the interface](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_278661935) when a freeze period would be enabled for specific environments. This was especially important to inform users that are consuming the deployments, and not necessarily the people involved in setting up Deploy Freezes.\n\nThis is how one of the first versions of the MVC looked like:\n\n![Initial take on depoy freeze acceptance criteria](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-iteration.jpg){: .large.center}\n\nHigh-level acceptance criteria including some interaction and requirements for frontend. No high-fidelity prototyping at this point.\n{: .note.text-center}\n\n![Initial take on depoy freeze prototype](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-prototype.jpg){: .large.center}\n\nA _quick-and-dirty_ mockup produced by manipulating the source and styles of the Environments page on the browser.\n{: .note.text-center}\n\nAlthough engineering wanted to support the ability to configure everything related to a Deploy Freeze using the `gitlab-ci.yml` file at some point, while being able to retry a pipeline or even bypass a freeze period, we had significant data showing that it would be more valuable to users to instead have the ability to easily configure their policies using the UI. Our user insights told us that users configuring these kinds of pipelines are much less familiar with the terminal, and even editing yaml might be a challenge.\n\n## Iterate, iterate, iterate\n\nBack to the drawing board (or, in my case, the GitLab issue). My focus shifted from simply notifying users to allowing them to enter data in the UI. We worked asynchronously on [different proposals](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_298796163), until the point the scope could fit an MVC that satisfies the user goals we identified through research.\n\nUsing the same user story, the acceptance criteria shifted to:\n\n![Deploy freeze mvc user story](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-user-story-iteration.jpg){: .large.center}\n\nWhile working on the new acceptance criteria, I started raising a couple of questions and [thinking of edge cases](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_308692974). For example, \"can we use a date picker UI component to select the deploy freeze period?\", \"will the end freeze field always be mandatory when setting a new period?\", \"can we support the user's default browser timezone when showing a dropdown on the UI?\", and \"how do we validate the cron syntax on the frontend?\".\n\nOnce again, Engineers to the rescue! [Nathan](https://gitlab.com/nfriend), our Super-Frontend Engineer, and I had a quick call where I walked him through my low-fidelity prototypes and we aligned our goals. Our decisions were documented as a [comment on the MVC](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_308765612) to ensure everyone involved could access the information.\n\n## Break the user story down into something even smaller\n\nMy conversation with Nathan also made it clear that editing and deleting a deployment freeze using the UI, as well as showing human-readable cron syntax descriptions, would increase the MVC scope. Because of that, I proactively broke the user story down into four new user stories that were logged as new feature proposals:\n\n> As a user, I want to see human-readable cron syntax descriptions for deploy freezes in GitLab's UI, so that I can easily understand the information about a freeze. [gitlab#212458](https://gitlab.com/gitlab-org/gitlab/-/issues/212458)\n\n> As a DevOps Engineer/Release Manager, I want to edit Deploy Freezes I specify, so that I can keep my information up to date. [gitlab#212449](https://gitlab.com/gitlab-org/gitlab/-/issues/212449)\n\n> As a DevOps Engineer/Release Manager, I want to delete deployment freezes I specified, so that I can keep my information up to date. [gitlab#212451](https://gitlab.com/gitlab-org/gitlab/-/issues/212451)\n\n> As a user, I want to be informed when a Deploy Freeze is active for my project in GitLab, so that I can stay up to date with the status of production deployments. [gitlab#212460](https://gitlab.com/gitlab-org/gitlab/-/issues/212460)\n\nBy reducing the scope of the MVC, the Product Manager and Engineers could start a new conversation about delivery efforts:\n\n![Async discussion and frontend estimation of the MVC](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-breakdown.jpg){: .large.center}\n\nAsync discussion and frontend estimation of the MVC. Read more on [gitlab#24295](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_311365886)\n{: .note.text-center}\n\nI then placed the descoped stories in the “backlog” for short-term assignment and long-term reference. By having our Product Manager serve as gatekeeper to the backlog, our team can focus on working on high-value features that have already been vetted and are supported by user insights.\n\n## Prototyping with a focus\n\nWith everyone on board, I can finally spend proper time prototyping the MVC solution! 🎉\n\nI personally am a fan of spending more time writing down design specifications than pushing pixels. Because [the GitLab train is always moving](https://about.gitlab.com/releases), prototyping is costly and prone to becoming obsolete in the blink of an eye. I also try to be mindful when I need to provide a prototype to my team. Will it help them understand my proposal? Can the prototype unlock hidden edge cases I didn't account for? Do I work with people that need visual cues to better understand the design goals?\n\n![Final depoy freeze prototypes](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-prototype-iteration.jpg){: .large.center}\n\nFinal high-fidelity prototypes used by the engineering team to estimate the MVC. Adjustments of UI copy are aligned on the fly with Technical writers after this phase.\n{: .note.text-center}\n\nPreviously, [Pedro](https://gitlab.com/pedroms) shared how one of the designer’s responsibilities is [handing off the design to developers](https://about.gitlab.com/blog/how-gitlab-pages-made-our-sketch-design-handoffs-easier-and-faster/), so that it gets implemented as intended. I trust that my frontend team will follow the acceptance criteria, for example, by reusing the Pajamas components I specified. And if by any chance they need to make changes/improvements to the design proposal on the fly: so be it!\n\nThe prototypes I build facilitate the design/development conversation, and they are meant to be used as assets to help our engineers have a starting point to build features. Prototypes are not the end product! Because I am also added as a UX reviewer to frontend merge requests, I can spot inconsistencies under development and discuss the proposed changes on the fly with the team. Once we agree on a direction, and if the change is big enough to be noted on the scope of our MVC, I make sure the information is updated in the SSOT.\n\n## Five keys takeaways from our workflow\n\n1. **You don't need to do Agile to be agile (lower case _a_).** Work around implementing best practices that work for you and your team.\n1. **Communicate with your team early and often.** As a tool, user stories help facilitate the conversation between UX, Research, Engineering, and Product. Look at the user stories to estimate design and development effort.\n1. **Identify user stories before jumping into designing a \"solution.\"** Make an effort to use research insights to guide your decisions. Deliver on real user needs. If user data is not available, try looking into different [research methods](https://about.gitlab.com/handbook/product/ux/ux-research/#research-methods).\n1. **Play around with the acceptance criteria.** For each user story, see if it can be broken down into smaller, more specific stories.\n1. **Document, iterate, and validate your decisions.**\n\n## Where do we go from here?\n\nAs with everything we do, this process is in constant change. User stories have been a great ally to promote a shared vision of the end user, while shifting the way we ship solutions. We went from having a list of functionalities with dubious origins that simply focused on solutions to having user-centered proposals that clearly let us communicate _why_ we are building things and _how_ we want to help our users achieve their goals.\n\nI am beyond excited about the relationship the Release Management team built around design and research. We are confident with the solution proposed for Deploy Freezes, but further developments may require [solution validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation) to test the usability of our prototypes and implemented features. Personally, I would still like to uncover more opportunities to contribute to [gitlab-ui](https://gitlab.com/gitlab-org/gitlab-ui) components and the [Pajamas Design System](https://design.gitlab.com/) through our user stories, so that we can come up with additional improvements to patterns that are used globally across GitLab.\n\nIf any of these topics interest you or if you have some feedback on our ideas, please get in touch and let us know what you think. We are planning great things for Release Management, in particular [Release Orchestration](https://about.gitlab.com/direction/release/release_orchestration/) with GitLab.\n\nYou can get to know more about the [Release UX Team Strategy](https://about.gitlab.com/handbook/product/ux/stage-group-ux-strategy/release/) in our handbook! We would love to hear from you!\n\nCover image by [Christina @ wocintechchat.com](https://unsplash.com/@wocintechchat?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[1099,1096,9,934,1096],{"slug":3105,"featured":6,"template":698},"how-we-utilize-user-stories-as-a-collaborative-design-tool","content:en-us:blog:how-we-utilize-user-stories-as-a-collaborative-design-tool.yml","How We Utilize User Stories As A Collaborative Design Tool","en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool.yml","en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool",{"_path":3111,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3112,"content":3117,"config":3124,"_id":3126,"_type":13,"title":3127,"_source":15,"_file":3128,"_stem":3129,"_extension":18},"/en-us/blog/how-we-uxd-our-secure-ux-team",{"title":3113,"description":3114,"ogTitle":3113,"ogDescription":3114,"noIndex":6,"ogImage":1174,"ogUrl":3115,"ogSiteName":685,"ogType":686,"canonicalUrls":3115,"schema":3116},"How we UX'd our Secure UX team structure","The Secure UX team's approach toward collaboration, authorship, information discovery and team structure.","https://about.gitlab.com/blog/how-we-uxd-our-secure-ux-team","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we UX'd our Secure UX team structure\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Kyle Mann\"},{\"@type\":\"Person\",\"name\":\"Andy Volpe\"}],\n \"datePublished\": \"2019-10-11\",\n }",{"title":3113,"description":3114,"authors":3118,"heroImage":1174,"date":3121,"body":3122,"category":300,"tags":3123},[3119,3120],"Kyle Mann","Andy Volpe","2019-10-11","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAt GitLab, change is part of our DNA. We embrace constant iteration and evolution in our product and our company.\n\nThis year, much of the change we’ve experienced has been due to company growth. We’ve literally doubled in size, increasing from around 400 to over 800 team members in a very short period of time. Naturally, that growth brought changes to how we organize our product teams. What were once small, interdisciplinary stage groups quickly grew to become multiple, dedicated teams within each Stage. For example, in Secure, we saw the creation of three separate teams, all with dedicated Engineering resources and Product Managers.\n\nOn the UX team structure side of things, we knew we needed to support our Stage by creating a similar division of responsibilities. But questions kept coming up: How would we divide our efforts while still creating an integrated experience? And how could we address some gaps that were already becoming more evident as we scaled?\n\nWe decided to treat this problem like we do any other UX challenge. First, we clearly identified the problem:\n\n```\nHow might we maintain our effectiveness as a design team within an evolving company structure?\n```\n\nWith the problem identified, we began iterating through solutions and identifying subtasks and processes that helped to solve it.\n\nSomething we learned early on is that what we create today will likely be outdated next week... and we’re okay with that! Problem solving for scale and unknown change is difficult. Something that works with a team of 3 might not work with a team of 6. We were going to have to be flexible. We didn’t come out with exact answers or a silver bullet, but we did discover some best practices that helped along the way.\n\n## Taking the guess work out of UX\n\nUXers are a curious bunch. We’re always asking questions: who are our users, what problems are we solving, and why are we solving them? (And then we ask why again.) The purpose of these questions is to help remove guesswork from our proposed solutions. We wanted to approach solving this problem in the same way.\n\nSo, we started by putting together a [foundations document](https://gitlab.com/gitlab-org/gitlab-design/issues/333) that asked all of the usual questions. Then, we shared it cross-functionally, so anyone could contribute to the answers and add more questions.\n\nWe learned that we knew some things, but there was also a lot that we didn't know. That’s OK, because what you don't know can sometimes be more important than what you do know. Open questions can serve as a checklist of information to uncover.\n\nAsking (and answering some of) the questions in our foundations document resulted in the first iteration of our [Secure UX page](https://about.gitlab.com/handbook/product/ux/stage-group-ux-strategy/secure/). This page will grow over the next year, as we get to know our users and problem space through [research](https://gitlab.com/groups/gitlab-org/-/epics/1611), [UX Scorecards](https://about.gitlab.com/handbook/product/ux/ux-scorecards/), cross-stage collaboration, and talking with users. The key insights we gain will continue to inform our handbook page for shared team awareness.\n\nAndy:\n_\"Having this document in place helped us take inventory across the entire Stage of where the knowledge gaps exist and focus our efforts toward uncovering critical information.\"_\n\nKyle:\n_“When I joined the team, the foundations document project was a great way to peel the different layers of our product, drive conversation, and better understand cross-functional motivations. I’m elated that other stage groups have adopted the process and found it helpful!“_\n\n## Getting to know your team\n\nEarly on, we realized that we needed to have more face-to-face time than we were accustomed to. We met this challenge by having weekly 1:1s with each other and maintaining a consistent cycle of coffee chats with our Stage group counterparts. (It’s a little like doing user research to understand pain points and possible areas of confusion.)\n\nWhen a team is rapidly growing, it's crucial to embrace collaboration and transparency. Surfacing challenges early allows for opportunities to emerge before a problem does.\n\nFor us, there was no shortage of hard conversations and growing pains, but that was when real growth and progress happened.\n\nMaintaining and cultivating relationships with the team and the Stage has enabled us to have more productive conversations. As an unexpected result, we work more effectively asynchronously now more than ever and rely less on ad-hoc chats and meetings. But we still have our coffee chats and 1:1s. We aren't giving those up!\n\nKyle:\n_\"Sharing your vulnerabilities with each other is a powerful way to bring you closer together and evolve your team’s relationships. Establishing mutual trust compounds the effects of collaborative efforts and can be the difference between success and failure of a project.\"_\n\nAndy:\n_\"It's refreshing to be able to know and understand teammates’ thought processes, decision tendencies, and the way they like to communicate. It was a challenge, at first, adjusting to more synchronous communication and collaboration, but the results speak for themselves.\"_\n\n## Sharing work and splitting work\n\nSomething we realized after becoming a two-designer Secure UX team was that we were both trying to become experts on a diverse range of security topics. It’s an intrinsic trait of designers that we want to \"know all the things,\" so we can be informed when making design decisions.\n\nUnexpectedly, though, we were overlapping each other's work, which meant we weren't finding success or collaborating well.\n\nBy not having a dedicated area of focus within the Secure Stage, we each had conflicting views and approaches to the same features. We were continually \"rebasing\" our design and exploration work because of UX conflicts that manifested.\n\nSo we hired a UX manager.\n\nJust kidding!!! But when our new manager, [Valerie](https://about.gitlab.com/company/team/?department=ux-department#vkarnes), joined our team, she was able to guide us toward creating areas where we would have ownership.\n\nCoincidentally, the engineering team also split within the stage groups at this same time, giving us the opportunity to create dedicated areas of focus and align better with our counterparts.\n\nWe started the task of creating separate UX areas by running a quick brainstorming session with the Secure UX team (just like we do at the beginning of a new project). From there, we looked at the areas our Stage categories were meant to cover, and we began aggregating that information into this [mural board](https://app.mural.co/invitation/mural/gitlab2474/1560787085910?sender=avolpe0924&key=3738c3db-031c-44ba-b542-d7da00aa4bca). It was the same affinity mapping process we use to look for commonalities in research findings or stakeholder requirements..\n\nWhat the affinity map helped us quickly see was: while there were areas of clear ownership where we could split work, there were areas where we needed to share work, too. This [issue](https://gitlab.com/gitlab-org/gitlab-design/issues/458) summarizes what we learned.\n\n### Shared work\n\nHere’s the work that we decided to share:\n\n- Interacting with vulnerabilities\n- Status, reporting, and metrics for vulnerabilities\n- Information architecture and inter-stage experiences\n\nThese areas are core to the Secure experience, and they benefit from collaborative design work and exploration. But the benefits don’t end with our product UX—they help our team work better together, too:\n\n- We gain an established common purpose.\n- Our trust grows as we get to know each other better.\n- We fail and succeed together.\n- We have more opportunities to create new and unique solutions.\n- We gain visibility into how another designer may have solved a similar problem in the past.\n\nBy sharing work, we’re also able to improve our onboarding experience for new product designers. When new teammates join, we work together to find a shared issue that will help them better understand the product and that they can contribute to without much domain knowledge.\n\nFor example, when [Becka](https://about.gitlab.com/company/team/?department=protect-ux-team#beckalippert) and [Camellia](https://about.gitlab.com/company/team/?department=secure-ux-team#cam.x) recently joined the team, we purposely chose [shared issues](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Secure%20UX%3A%3AShared) as excellent shadow opportunities. These serve as great introductions into the Stage and the security field and will help build their foundational knowledge in both.\n\nThese shared issues help everyone obtain a richer contextual understanding of the design problems we are solving for as a team. In the end, our product and experience will benefit as a result.\n\n### Split work\n\nWhile shared work has its advantages, so does splitting our efforts to focus on specific domains and features. The benefits we've seen:\n\n- We can work closely and consistently with engineers.\n- We’re able to grow our domain knowledge about a particular area.\n- We experience less of the friction caused by context switching.\n- We’re better able to envision and create an end-to-end experiences for our users.\n\nSplit work doesn't mean solo work, necessarily. The GitLab UX team hosts weekly group design feedback sessions where designers share their work and the UX team offers feedback. Our UX Director often says, \"I learn the most about our product in these sessions!\" We definitely agree.\n\nThat’s why we also do our best to share work during cross-functional meetings and asynchronously on our [Secure UX](https://www.youtube.com/playlist?list=PL05JrBw4t0KrFCe5BgUkzFrZifjforQOz) playlist on the [GitLab unfiltered YouTube](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) channel. For us, a divide-and-conquer approach doesn't mean that other teammates aren’t involved.\n\nAn excellent example of collaborating on split work is the [UX Scorecard initiative](https://about.gitlab.com/handbook/product/ux/ux-scorecards/) in Q3 to collaborate on the new Security gates feature. This is a software composition feature (Kyle's split focus), though the MR aspect is closely related to vulnerabilities detected in the MR (Andy's split focus). In this case, Andy will conduct [#534](https://gitlab.com/gitlab-org/gitlab-design/issues/534), and Kyle will do [#533](https://gitlab.com/gitlab-org/gitlab-design/issues/533); then we'll work together on next steps and design improvement recommendations. Since each of the issues is tied to different personas, we see this is an opportunity for us to be an advocate for each unique user and focus strictly on their experience—all while working together on a cross-stage solution that benefits the feature.\n\nAndy:\n_“Having both a dedicated area of focus and shared areas of focus has given me an opportunity to dive deep into the specific niche areas of AppSec and uncover valuable insights about our users, their goals, and the technical challenges they face while still being able to see the bigger picture.”_\n\nKyle:\n_“Merging our efforts is a crucial aspect to our design process. This helps ensure our split work results in a cohesive experience for our users.”_\n\n## Putting it all together\n\nIn the next few months, we have two new designers joining Secure and another for Protect. We’re thrilled to continue evolving our team and partnering with our new teammates on a path forward. Our mission and commitment are clear: To create a best in-class security and compliance experience for our customers.\n\nThanks for reading! Any thoughts to share? Do you have stories about scaling your UX team? Tell us in the comments below!\n\n_Interested in joining the team? [We’re hiring!](https://about.gitlab.com/jobs/)_\n\n",[1099,9],{"slug":3125,"featured":6,"template":698},"how-we-uxd-our-secure-ux-team","content:en-us:blog:how-we-uxd-our-secure-ux-team.yml","How We Uxd Our Secure Ux Team","en-us/blog/how-we-uxd-our-secure-ux-team.yml","en-us/blog/how-we-uxd-our-secure-ux-team",{"_path":3131,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3132,"content":3138,"config":3143,"_id":3145,"_type":13,"title":3146,"_source":15,"_file":3147,"_stem":3148,"_extension":18},"/en-us/blog/if-its-time-to-learn-devops-heres-where-to-begin",{"title":3133,"description":3134,"ogTitle":3133,"ogDescription":3134,"noIndex":6,"ogImage":3135,"ogUrl":3136,"ogSiteName":685,"ogType":686,"canonicalUrls":3136,"schema":3137},"It's time to learn DevOps and here's where to begin","DevOps is a unique blend of tech, tools and culture. Take it step-by-step and it's easy to learn. This simple guide shows you how to get started. Learn more here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663743/Blog/Hero%20Images/three-things-i-learned-in-my-first-month-at-gitlab.jpg","https://about.gitlab.com/blog/if-its-time-to-learn-devops-heres-where-to-begin","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"It's time to learn DevOps and here's where to begin\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-03-10\",\n }",{"title":3133,"description":3134,"authors":3139,"heroImage":3135,"date":3140,"body":3141,"category":757,"tags":3142},[734],"2022-03-10","\n\nIf you’re fairly new – or really new – to a DevOps team, you’ve made a great career move, but you probably [have a lot to learn](/topics/devops/devops-beginner-resources/). To truly learn DevOps, there are technologies and processes to figure out, phases to understand, and a [whole new mindset to adopt](/blog/soft-skills-are-the-key-to-your-devops-career-advancement/). \n\n## Learn DevOps, where to start?\n\nLearn DevOps? Why? Where?... Since the demand for DevOps professionals is hot and salaries for this [dynamic job sector](/blog/four-tips-to-increase-your-devops-salary/) are on the rise, there are a lot of DevOps beginners trying to figure out what to learn first. But don’t worry: We can help. \n\nWith a lot on [your learn DevOps to-do list](https://learn.gitlab.com/beginners-guide-devops/guide-to-devops), we’ll walk you through where you should start, including figuring out what DevOps is all about, the stages of the DevOps lifecycle, and the uniquely [collaborative culture](/blog/engineering-teams-collaborating-remotely/). \n\n## What DevOps is really all about\n\nIn the past, software development was done using a complicated and confusing jumble of tools and workflows. Both projects and teams often were siloed, which meant they weren’t coordinating efforts or sharing best practices. It was a frustrating and inefficient process that led to deployment traffic jams, costing teams time and money. There were a lot of headaches.\n\nThink of DevOps as a way to simplify development and deployment, while making the entire process more efficient. With DevOps, once-siloed teams, tools, and workflows are combined in a software development ecosystem. That ecosystem enables teams to plan, create and deliver more efficiently, securely, and collaboratively. \n\n## What to learn for DevOps\n\nDevOps also puts a focus on automation, shifting security left, and making practices not only repeatable but measurable. That speeds development cycles and slashes the time between designing new features and rolling them out into production.\n\nBecause of this efficiency and the enablement of teamwork, DevOps makes not only your software delivery more agile, it makes your entire company more agile. DevOps enables the business to pivot quickly, answering new and critical customer needs, responding to changes in the market and adjusting to stay ahead of the competition. \n\n## To learn DevOps, collaborate\n\nDevOps is built around a culture of collaboration that encourages teammates to share ideas and help each other. It’s not simply something that’s suggested and it’s not something that’s done in a meeting or two. Collaboration is a [core principle](/blog/4-must-know-devops-principles/) of DevOps. \n\nIt's easy to think that to learn DevOps means focusing on programming languages, security, and CI/CD. Those skills and technologies are critical but don’t dismiss the idea of collaboration. It’s about communication, and working together to create something new and to fix problems. However, DevOps professionals also collaborate with other departments, like security, marketing, and the C-suite. You’re all pulling in the same direction.\n\nIn the [2021 Global DevSecOps Survey](/developer-survey/), survey respondents consistently said communication and collaboration skills were key to their future careers. \n\n## The key stages of the DevOps lifecycle\n\nThere’s a definite flow to DevOps, with the process moving from planning and developing all the way through to deployment, monitoring, and feedback. There are three basic stages, or phases – build, test, and deploy. Within these are nine other stages that will help you produce software efficiently, reliably, and with speed and agility.\n\n- Planning focuses on everything that happens before a single line of code is written.\n- Creating is about designing and developing.\n- Verifying checks the quality of the code.\n- Packaging applications and dependencies, managing containers, and building artifacts maintains a consistent software supply chain. \n- Release, or deployment, is all about moving code updates into production as iterations are ready.\n- Configuring is focused on creating, managing, and maintaining application environments.\n- Monitoring is about checking the status of software and networks.\n- Protecting is all about securing your applications and their environment.\n- Managing runs end-to-end through your software development lifecycle, controlling permissions and processes. \n\n## What it means to shift security left\n\nDid you notice that security wasn’t one of the lifecycle stages for DevOps? Well, it’s not a single stage because it’s woven into EVERY stage. Shift left means you don’t wait to incorporate security into software at the end of a build. You consider security beginning with the initial planning stage and continue to focus on it all the way through, giving you more opportunity to avoid or find and address any issues. Shifting left enables you to make sure the code you are developing functions as intended, and that any vulnerabilities and compliance issues are caught and fixed.\n\n## Understand CI/CD\n\nFirst off, CI/CD means continuous integration and continuous delivery. Combined continuous development methodologies and practices focus on catching vulnerabilities and errors early in the development lifecycle, ensuring that all the code deployed into production complies with standards the DevOps team has established for the software being created. This helps connect development and operations teams, as well as projects, by using automation for building, testing, and deployment. \n\nCI/CD is all about incremental code changes being made frequently and reliably – a critical part of how a DevOps platform enables an organization to automatically deliver software multiple times a day. This is key for DevOps teams and the overall business because CI/CD helps to quickly and efficiently move software updates into production, making the organization able to respond faster to customer needs. \n\n## How to get started with DevOps: dig deeper\n\nWant to learn more? Our [Beginner's guide to DevOps](https://page.gitlab.com/resources-ebook-beginners-guide-devops.html) has everything you need to get started.\n",[695,108,9],{"slug":3144,"featured":6,"template":698},"if-its-time-to-learn-devops-heres-where-to-begin","content:en-us:blog:if-its-time-to-learn-devops-heres-where-to-begin.yml","If Its Time To Learn Devops Heres Where To Begin","en-us/blog/if-its-time-to-learn-devops-heres-where-to-begin.yml","en-us/blog/if-its-time-to-learn-devops-heres-where-to-begin",{"_path":3150,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3151,"content":3157,"config":3162,"_id":3164,"_type":13,"title":3165,"_source":15,"_file":3166,"_stem":3167,"_extension":18},"/en-us/blog/improve-your-gitlab-productivity-with-these-10-tips",{"title":3152,"description":3153,"ogTitle":3152,"ogDescription":3153,"noIndex":6,"ogImage":3154,"ogUrl":3155,"ogSiteName":685,"ogType":686,"canonicalUrls":3155,"schema":3156},"10 tips to make you a productive GitLab user","Learn how quick actions can make you a more efficient GitLab user.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666717/Blog/Hero%20Images/cover-image.jpg","https://about.gitlab.com/blog/improve-your-gitlab-productivity-with-these-10-tips","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"10 tips to make you a productive GitLab user\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"},{\"@type\":\"Person\",\"name\":\"Roman Kuba\"}],\n \"datePublished\": \"2021-02-18\",\n }",{"title":3152,"description":3153,"authors":3158,"heroImage":3154,"date":1694,"body":3160,"category":1053,"tags":3161},[2005,3159],"Roman Kuba","Most people know GitLab is a solid tool in today's DevOps workflows, with\ncode reviews, CI/CD, and project management all available for users in a\nsingle application. But there are always ways to be more efficient. Since we\nuse GitLab to develop GitLab, everyone has their own habits and hidden gems\nto speed things up.\n\n\nWe chatted about GitLab efficiency tips after seeing new [quick actions\nreleases in GitLab\n13.8](/releases/2021/01/22/gitlab-13-8-released/#display-all-available-quick-actions-in-autocomplete),\nand decided to share some of our favorite tips with GitLab users. We share\nour typical day-to-day workflows as an engineering manager (Roman) and a\ndeveloper (Michael) to show how quick actions make teams more productive and\nefficient.\n\n\n### Roman: Engineering manager starts planning\n\n\nI am an engineering manager on the [Create: Editor\nteam](https://handbook.gitlab.com/handbook/product/categories/features/#createeditor-group) at GitLab.\nOne of my responsibilities is capacity planning with product managers.\nPlanning happens every month for the next [GitLab release](/releases/).\nGitLab uses the [milestone\nfeature](https://docs.gitlab.com/ee/user/project/milestones/) to keep\neverything organized for the release. As planning goes on, I need to create\na new issue for a new feature in the Web IDE. The issue description uses a\n[description\ntemplate](https://docs.gitlab.com/ee/user/project/description_templates.html)\nwhich gets filled with the right context.\n\n\nBut instead of searching for the assignee in the dropdown, I just add a new\nline:\n\n\n```\n\n/assign @dnsmichi\n\n```\n\n\nAll quick actions start with a `/` character and will be interpreted by\nGitLab when the issue gets created. In addition to an assignee, issue labels\nneed to be applied as well.\n\n\n```\n\n/label ~\"type::feature\"\n\n```\n\n\nYou can also assign multiple labels at once:\n\n\n```\n\n/label ~devops::create ~group::editor ~\"Category::Web IDE\"\n\n```\n\n\n![GitLab Quick Actions: Multiple\nlabels](https://about.gitlab.com/images/blogimages/improve-your-gitlab-productivity-10-tips/quick_action_label_multiple.png)\n\nHow to apply multiple labels using GitLab quick actions.\n\n\nThe issue needs to be assigned to the next milestone. This can be done with\nanother quick action:\n\n\n```\n\n/milestone %13.10\n\n```\n\n\nNote that 13.9 release planning already happened last month. The [product\nkickoff](/direction/kickoff/) highlights the planned features.\n\n\nThe keyboard shortcut `cmd + enter` now creates the issue without clicking a\nbutton.\n\n\nSo far, we were able to complete a lot of the necessary workflows around\nissues in one go, and without ever leaving the text box.\n\n\nAfter reviewing the issue I created, I remembered that this issue should be\nassigned to the `FY22Q1 Performance OKRs` epic. Again, we can use a quick\naction. It’s important to note here that referencing an epic works with the\n`&` character. When we type this character, we can start to search for the\nepic by typing its name.\n\n\n```\n\n/epic & \u003Csearch>\n\n```\n\n\nThis will turn into something like this:\n\n\n```\n\n/epic &123\n\n```\n\n\nAll quick actions can be used in a new comment and again using `cmd + enter`\nto save it.\n\n\nThe `FY22Q1 Performance OKRs` epic still needs to be added to a parent\nengineering OKR epic. So I'll navigate to the now-linked epic and use\nanother quick action to set the parent epic.\n\n\n```\n\n/parent_epic & \u003Csearch>\n\n```\n\n\nWhen working with multiple levels of epics, remember to keep practicing\nquick actions to create visual epic trees quickly. That’s all for now from\nmy manager's side.\n\n\n### Michael: A developer starts with code\n\n\nI work on the [Developer Evangelism\nteam](/handbook/marketing/developer-relations/developer-evangelism/) at\nGitLab, and although I'm not technically a developer in the typical sense I\nstill work with code on a daily basis. The average day starts with a new\nto-do. Today's to-do points me to the new issue that Roman created. After\nreviewing the issue requirements and defining the changes to be implemented,\nI start work: I'll clean up the work environment, pull the latest changes\nfrom the default branch (main/master), and create a new Git branch in my\nlocal terminal.\n\n\nAfter a few commits, my work day nears its end. I decide to publish the\nlocal Git branch and create a new Merge Request (MR). After creating the MR,\nthe triage workflow kicks off. I mark the [MR as\ndraft](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html)\nto prevent the workflow from starting before the MR is ready:\n\n\n```\n\n/draft\n\n```\n\n\nThe next day, I continue working on the MR and finish everything that was\nplanned, so I need to remove the draft designation. The `draft` quick action\nis a toggle, so I can use it to assign and remove the `Draft` marker.\n\n\n```\n\n/draft\n\n```\n\n\nThe next step is to assign a reviewer for the MR. GitLab 13.7 added [merge\nrequest reviewers](/blog/merge-request-reviewers/), which means\nwe can leave the MR assignee untouched. I'll use the livesearch to assign\nthe right reviewer with a leading `@` character.\n\n\n```\n\n/assign_reviewer @ \u003Csearch>\n\n```\n\n\n![GitLab Quick Actions: Remove draft and assign\nreviewer](https://about.gitlab.com/images/blogimages/improve-your-gitlab-productivity-10-tips/quick_action_toggle_draft_assign_reviewer.png)\n\nHow to remove the draft and add a reviewer using GitLab quick actions.\n\n\nAfter the first round of review, I get feedback and items for follow-up.\nSince I am in the middle of a different tasks, I create a new to-do to\nremind myself of an open task to follow up on when I'm ready.\n\n\n```\n\n/todo\n\n```\n\n\nSince my work as a developer evanglist includes many topics and areas, I get\ndistracted with other high priority tasks throughout the day. Later in the\nweek, I'll come back to the MR. The review items have been addressed by team\nmember suggestions and all threads are resolved now. The reviewer approves\nthe MR with the quick action:\n\n\n```\n\n/approve\n\n```\n\n\nThe review process took a little while to complete, and because GitLab is a\nfast-changing project, the Git branch is outdated. I need to rebase against\nthe default branch.\n\n\nBut since I am already working on something else, I do not want to stop what\nI am doing currently to rebase. Then I remember: GitLab 13.8 added the\n`/rebase` quick action. This schedules a new background job that attempts to\nrebase the branch, and stops operations if it fails.\n\n\nI open the MR and create a new comment. I start typing the rebase quick\naction, followed by `cmd+enter` to send it:\n\n\n```\n\n/rebase\n\n```\n\n\n![GitLab Quick Actions:\nRebase](https://about.gitlab.com/images/blogimages/improve-your-gitlab-productivity-10-tips/quick_action_rebase.png){:\n.shadow.center}\n\nHow to rebase with GitLab quick actions.\n\n{: .note.text-center}\n\n\nPhew. It worked. The CI/CD pipeline is running, and I believe that the\nrebase did not break anything. I go to click the \"Merge after pipeline\nsucceeds\" button, and remember there's a quick action for that.\n\n\n```\n\n/merge\n\n```\n\n\nThe quick action takes into account what is configured for the project:\nEither merge when the pipeline succeeds or add it to the [Merge\nTrain](/blog/merge-trains-explained/).\n\n\nEverything happens automatically and I can continue working on other tasks.\nThe manager (in this case, Roman) sees the issue being closed automatically\nusing the `Closes` keyword. That's all from my developer's side.\n\n\nTip: [Automatically closing\nissues](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)\nafter the MR has been merged is an amazing workflow for everyone, assuming\nthe manager has set the milestone accordingly.\n\n\nAt GitLab, we have documented our [engineering\nworkflows](/handbook/engineering/workflow/) which can be followed more\nefficiently with the quick actions shown in this blog post.\n\n\n### Quick actions + description templates = ❤️\n\n\nWe demonstrated different ways quick actions can be used to complete common\ntasks more efficiently. But they do not always have to be applied manually.\nOne shortcut is to just add them to [description\ntemplates](https://docs.gitlab.com/ee/user/project/description_templates.html)\nso you do not have to worry about remembering them all. This way, you can\nalso automatically assign users, add labels, and much more based on the\ntemplate you apply. Using description templates helps with project\ncontributions and allows everyone to focus on the feature proposal or bug\nreport.\n\n\nLet’s try it! Create a new project, navigate into \"Issues > Labels\" and\ngenerate a default set of labels. Next, open the Web IDE and add a new file\nin `.gitlab/issue_templates/bug.md`. Add the following content:\n\n\n```\n\n# Summary\n\n\n# Steps to reproduce\n\n\n1.\n\n1.\n\n1.\n\n\n\u003C!-- Do not edit the section below -->\n\n/label ~\"type::bug\"\n\n/assign @YOURUSER\n\n```\n\n\nFirst, replace YOURUSER with your username (make sure you're logged in).\nCommit the new file to the default branch, and navigate into the issue list.\nNext, create a new issue and select `bug` from the dropdown. Add some\ncontent, and submit the issue. Finally, verify that the label and assignee\nare both set.\n\n\nTip: This is not limited to issue templates, it also works with MRs and\nepics. At GitLab we also often use this function to dynamically assign\npeople based on reports created automatically. There are many opportunities\nto use description templates.\n\n\n### More tips and insights\n\n\nWe have not yet tried the following quick actions - can you help us out? :-)\n\n\n```\n\n/shrug\n\n/tableflip\n\n```\n\n\nThere are more [quick\nactions](https://docs.gitlab.com/ee/user/project/quick_actions.html) and\n[keyboard shortcuts](https://docs.gitlab.com/ee/user/shortcuts.html)\navailable. In fact, GitLab user [Gary Bell](https://gitlab.com/garybell)\nshared great insights on quick actions in his \"Tanuki Tuesday\" blog series:\n\n\n- [Quick Actions](https://www.garybell.co.uk/quick-actions-in-gitlab/)\n\n- [Keyboard\nShortcuts](https://www.garybell.co.uk/using-keyboard-shortcuts-in-gitlab/)\n\n\nLet us know in the comments below which quick actions most helped your\nproductivity and if you have other creative ways of using quick actions.\n\n\nPS: We also support shortcuts at GitLab, and the most loved shortcut is `cmd\n+ k` for inserting a Markdown URL.\n\n\nCover image by [Juan Gomez](https://unsplash.com/@nosoylasonia) on\n[Unsplash](https://unsplash.com/photos/kt-wA0GDFq8)\n\n{: .note}\n",[912,9,934],{"slug":3163,"featured":6,"template":698},"improve-your-gitlab-productivity-with-these-10-tips","content:en-us:blog:improve-your-gitlab-productivity-with-these-10-tips.yml","Improve Your Gitlab Productivity With These 10 Tips","en-us/blog/improve-your-gitlab-productivity-with-these-10-tips.yml","en-us/blog/improve-your-gitlab-productivity-with-these-10-tips",{"_path":3169,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3170,"content":3176,"config":3181,"_id":3183,"_type":13,"title":3184,"_source":15,"_file":3185,"_stem":3186,"_extension":18},"/en-us/blog/incident-management-design-facilitation",{"title":3171,"description":3172,"ogTitle":3171,"ogDescription":3172,"noIndex":6,"ogImage":3173,"ogUrl":3174,"ogSiteName":685,"ogType":686,"canonicalUrls":3174,"schema":3175},"How we used design facilitation to understand incident management","The group responsible for the Monitor stage at GitLab recently got together to decide on new product features with a facilitated design session.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678649/Blog/Hero%20Images/incident_management-blog-image.jpg","https://about.gitlab.com/blog/incident-management-design-facilitation","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we used design facilitation to understand incident management\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n \"datePublished\": \"2019-03-15\",\n }",{"title":3171,"description":3172,"authors":3177,"heroImage":3173,"date":3178,"body":3179,"category":910,"tags":3180},[1406],"2019-03-15","\nBefore starting to design a new product feature, it’s useful to get everyone on the same page by asking a few important questions: What is the problem we are trying to solve?\nWho are we solving this problem for?\nWhat are the steps we should take in trying to solve this problem?\n\nAs we work remotely, collaborating on these questions synchronously isn’t generally an option.\n\nRecently, the [Monitor group](/handbook/engineering/development/ops/monitor/) was given the opportunity to gather in Berlin for a Fast Boot.\nWe took advantage of everyone being in the same place and time zone to host a [facilitated design session](https://gitlab.com/gitlab-org/gitlab-ce/issues/55663) on incident management, where we could answer these questions together.\n\n## How the facilitated design session works\n\nThe session involved walking the group through three exercises, each focusing on one of the core questions we needed to solve.\n\n### We tackled problem definition through running a boundary critique exercise\n\nUsing the [1-2-4-All](http://www.liberatingstructures.com/1-1-2-4-all/) technique, we came up with a list of things incident management is and is not.\nSince we had engineers, designers, and product managers all working together, we were able to benefit from diverse perspectives and experience levels.\nWe finished the exercise by agreeing on a definition of the space we wanted to work on together.\n\n### Next, we did an exercise to build empathy with our users\n\nWe took our four [ops personas](https://handbook.gitlab.com/handbook/product/personas/), broke into groups, and compiled [empathy map canvases](https://gamestorming.com/wp-content/uploads/2017/07/Empathy-Map-Canvas-006.pdf) for each.\nWe then took our deepened understanding of our assigned users and applied it to an imagined incident.\nWe shared our users’ pain points, concerns, and goals with the group.\n\n### Finally, brainstorming product features\n\nHaving established a scope for our work and a sense of our users’ needs, our final exercise involved brainstorming product features that would fit the requirements we had established.\nWe finished the session with everyone dot-voting on features, which left us with a prioritized list of features to work on as we move forward with this project.\n\nThough working this way isn’t a part of our normal flow, the facilitation was a great chance for us all to engage with a product discovery process together.\nBy tackling these questions as a group, we could all come to alignment on what was needed going forward.\nParticipating in these early stages of planning also generates an extra level of commitment to seeing these features through the development process, since we had all agreed on the necessity for them.\n\nWe will continue to explore how to inject the energy and enthusiasm generated by this process into our normal, asynchronous workflow.\n",[9,829,934],{"slug":3182,"featured":6,"template":698},"incident-management-design-facilitation","content:en-us:blog:incident-management-design-facilitation.yml","Incident Management Design Facilitation","en-us/blog/incident-management-design-facilitation.yml","en-us/blog/incident-management-design-facilitation",{"_path":3188,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3189,"content":3194,"config":3200,"_id":3202,"_type":13,"title":3203,"_source":15,"_file":3204,"_stem":3205,"_extension":18},"/en-us/blog/iterate-like-a-gitlab-designer",{"title":3190,"description":3191,"ogTitle":3190,"ogDescription":3191,"noIndex":6,"ogImage":1131,"ogUrl":3192,"ogSiteName":685,"ogType":686,"canonicalUrls":3192,"schema":3193},"Iterate Like a GitLab Designer","Think big, ship small, learn fast","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":3190,"description":3191,"authors":3195,"heroImage":1131,"date":3197,"body":3198,"category":716,"tags":3199},[3196],"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",[1096,1099,1098,2069,9],{"slug":3201,"featured":6,"template":698},"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":3207,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3208,"content":3213,"config":3218,"_id":3220,"_type":13,"title":3221,"_source":15,"_file":3222,"_stem":3223,"_extension":18},"/en-us/blog/join-the-gitlab-community",{"title":3209,"description":3210,"ogTitle":3209,"ogDescription":3210,"noIndex":6,"ogImage":1131,"ogUrl":3211,"ogSiteName":685,"ogType":686,"canonicalUrls":3211,"schema":3212},"Join the GitLab Code Contributor Community!","How we're working to make contributions easier and more rewarding for the GitLab community.","https://about.gitlab.com/blog/join-the-gitlab-community","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Join the GitLab Code Contributor Community!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-08-13\",\n }",{"title":3209,"description":3210,"authors":3214,"heroImage":1131,"date":3215,"body":3216,"category":784,"tags":3217},[1281],"2018-08-13","\nThere are [over 2,000 code contributors to GitLab](http://contributors.gitlab.com/) today and we want to welcome more contributors to the growing community.\n\nHaving been involved in other open source projects, I know how exciting it is to collaborate in an open community and work with passionate people from different parts of the world. I recently joined GitLab to work with our community of contributors, and I wanted to share a list of activities that I’m planning to help grow the community:\n\n## 1. Streamline onboarding documentations\n\nSo that it’d be easier for people to get started. There are already some initiatives on the way, such as this [merge request from a community member](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20682).\n\n## 2. Proactively reach out to first-time contributors\n\nI want to start congratulating new contributors who successfully complete their first merge request. Stay tuned for new swag and opportunities to be paired with mentors who are experienced GitLab community members.\n\n## 3. Launch new blog post series\n\nSpeaking of experienced contributors, I’d like to highlight some of them with a new blog post series, since their experience working in the GitLab community will be helpful for new contributors. The first post features Core Team member [Vitaliy Klachkov](/blog/contributor-post-vitaliy/).\n\n## 4. Kick off Core Team meeting\n\nWe just kicked off a regular meeting with the [Core Team](/community/core-team/) to discuss topics of interest for the GitLab community. This recorded meeting will be open to anyone. The Core Team will also use [Service Desk](https://gitlab.com/gitlab-core-team/general/issues/service_desk) so that anyone in the community can view and participate in discussions.\n\nThanks for reading my blog post. Your feedback/questions are always welcome and you can reach me at rpaik@gitlab.com.\n\n## Interested in learning how you can contribute?\n\nA good place to start would be the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, and translation.\n",[268,9,787],{"slug":3219,"featured":6,"template":698},"join-the-gitlab-community","content:en-us:blog:join-the-gitlab-community.yml","Join The Gitlab Community","en-us/blog/join-the-gitlab-community.yml","en-us/blog/join-the-gitlab-community",{"_path":3225,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3226,"content":3232,"config":3238,"_id":3240,"_type":13,"title":3241,"_source":15,"_file":3242,"_stem":3243,"_extension":18},"/en-us/blog/join-the-new-gitlab-collective-on-stack-overflow",{"title":3227,"description":3228,"ogTitle":3227,"ogDescription":3228,"noIndex":6,"ogImage":3229,"ogUrl":3230,"ogSiteName":685,"ogType":686,"canonicalUrls":3230,"schema":3231},"Join the new GitLab Collective on Stack Overflow!","Now you can learn and share your best tips and tricks about version control, CI/CD, all-remote, DevOps platforms and more on the new GitLab Collective on Stack Overflow. Here's how to get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668402/Blog/Hero%20Images/code-gitlab-tanuki.png","https://about.gitlab.com/blog/join-the-new-gitlab-collective-on-stack-overflow","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Join the new GitLab Collective on Stack Overflow!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Nguyen\"}],\n \"datePublished\": \"2021-11-08\",\n }",{"title":3227,"description":3228,"authors":3233,"heroImage":3229,"date":3235,"body":3236,"category":1203,"tags":3237},[3234],"Matt Nguyen","2021-11-08","\nWe’re very excited to announce the GitLab community has a new home on Stack Overflow: the GitLab Collective.\n \nWe know we already have a great relationship with our contributors and the open source community but [the GitLab Collective](https://stackoverflow.com/collectives/gitlab) on Stack Overflow will take that to the next level. Our collective will be a place contributors and developers can learn and share about version control, CI/CD, DevSecOps, all-remote, DevOps platforms and more.\n \n“Community is at the core of GitLab’s mission,” says [Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab. “With a contributor community of more than 2,600 people, we have a strong community aligned with our mission – to create a world where everyone can contribute. We believe the GitLab Collective will be a place where we can discover feedback and create opportunities for the GitLab community to contribute to Stack Overflow’s community.”\n\nFinding your way around the GitLab Collective is easy: look for the “gitlab” tag, or add “gitlab” to a more specific product search, like “gitlab-ci.” Ask questions, dive into in-depth technical data, or browse through how-to guides and articles. Contributions to the GitLab Collective will be tracked on a leaderboard, and if you’re a top contributor, we might tap you as a “Recognized Member” (basically a GitLab-approved guide who can help with questions and make recommendations).\n\n![GitLab on Stack Overflow](https://about.gitlab.com/images/blogimages/gitlabonstackoverflow.png){: .shadow}\n\n## What comes next\n\nIf you’re already a Stack Overflow user, please head to the GitLab Collective and start answering questions (you can ask questions too!). If you’re not a Stack Overflow user, we’d highly recommend you [join the community](https://stackoverflow.com). And remember you’ll earn reputation points on Stack Overflow by participating. \n\nRight now we’re in the process of creating the documentation that will outline how to become a “Recognized Member” on the GitLab Collective on Stack Overflow. As a Recognized Member, people can recommend answers and write articles on the GitLab Collective to help the community and show off their expertise. Recognized Members will also get a special badge on Stack Overflow that denotes them as a Recognized Members. More to come on this program so watch this space!\n",[268,9,1285],{"slug":3239,"featured":6,"template":698},"join-the-new-gitlab-collective-on-stack-overflow","content:en-us:blog:join-the-new-gitlab-collective-on-stack-overflow.yml","Join The New Gitlab Collective On Stack Overflow","en-us/blog/join-the-new-gitlab-collective-on-stack-overflow.yml","en-us/blog/join-the-new-gitlab-collective-on-stack-overflow",{"_path":3245,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3246,"content":3252,"config":3258,"_id":3260,"_type":13,"title":3261,"_source":15,"_file":3262,"_stem":3263,"_extension":18},"/en-us/blog/key-organizational-models-for-devops-teams",{"title":3247,"description":3248,"ogTitle":3247,"ogDescription":3248,"noIndex":6,"ogImage":3249,"ogUrl":3250,"ogSiteName":685,"ogType":686,"canonicalUrls":3250,"schema":3251},"5 key organizational models for DevOps teams","DevOps teams can be organized in multiple ways. Identify the one that fits your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667194/Blog/Hero%20Images/2020-11-19-integration-management-header.jpg","https://about.gitlab.com/blog/key-organizational-models-for-devops-teams","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 key organizational models for DevOps teams\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Johanna Ambrosio\"}],\n \"datePublished\": \"2022-03-08\",\n }",{"title":3247,"description":3248,"authors":3253,"heroImage":3249,"date":3254,"body":3255,"category":693,"tags":3256},[2809],"2022-03-08","\nIf you’re just getting started with DevOps, there are several team organizational models to consider.\n\nA few key points to keep in mind as you design your team structure:\n\n- The organizational model you start with should change as you add more people, [different DevOps roles](/blog/how-to-build-out-your-devops-team/), and more projects. Expect to keep iterating as you go.\n\n- The ultimate goal of DevOps is to spread the message, tools, and processes throughout the company so that, eventually, everyone is working “the DevOps way.” At some point, if your approach is successful, DevOps as a separate group will disappear.\n\n- The model you begin with should depend on how many projects or products you’re working on, the size of your teams, and the size of your company. \n\n- Keep your team size small, with three to eight people max. Some experts say up to 12 is OK, but that’s a bit large for the [“two-pizza” rule](https://landing.directorpoint.com/blog/amazon-two-pizza-rule/). \n\n## Why building a DevOps team is important\n\nEven though DevOps is arguably the most efficient way to get software out the door, no one actually ever said it’s easy. So building the right DevOps team is a critical step in the process. \n\nThe right DevOps team will serve as the backbone of the entire effort and will model what success looks like to the rest of the organization. There is no “one size fits all” however – each team will be different depending on needs and resources.\n\n## 5 examples of DevOps team models\n\nHere are five DevOps organizational models to consider as you get going, according to Matthew Skelton and Manuel Pais, experts who wrote a book called Team Topologies about this topic and then updated the book with a [related microsite](https://web.devopstopologies.com). Their work is a must-read for anyone who’s trying to figure out which DevOps structure is best for their company.\n\n### **1. Dev and ops co-exist, with a “DevOps” group in between**\n\nThis can be a good interim strategy until you can build out a full DevOps program. The DevOps team translates between the two groups, which pretty much stay in place as they currently are, and DevOps facilitates all work on a project. \n\nJust don’t keep this structure in place too long. You don’t want to reinforce the separate silos as they currently exist for any longer than absolutely necessary.\n\n### **2. Dev and ops groups remain separate organizationally but on equal footing**\n \nThis is also a reasonable place to start: Everyone collaborates but can specialize where needed. Common tools will go a long way to helping facilitate good communication. In this model, several dev teams can be working on different products or services. \n\nMake sure teams communicate regularly. Invite a rep from each camp to the other’s meetings, for instance. And appoint a liaison to the rest of the company to make sure executives and line-of-business leaders know how DevOps is going, and so dev and ops can be part of conversations about the top corporate priorities.\n\n### **3. Create one team, maybe “no ops”?**\n\nIn this model, a single team has shared goals with no separate functions. The reason it’s called [“no ops”](https://searchitoperations.techtarget.com/definition/NoOps) is because ops is so automated it’s like it doesn’t actually exist. \n\nThis level of automation is so “aspirational” that many experts express caution about this approach. To eliminate any hands-on tasks, teams would need extensive machine learning and artificial intelligence solutions, and a flat, streamlined organization that prioritizes communication and workflow. TL;DR: [NoOps may not ever be a reality](https://www.cio.com/article/220351/what-is-noops-the-quest-for-fully-automated-it-operations.html).\n\nHowever, don’t use this as an excuse to do away with the ops team. You are going to need those folks. Devs can’t do it all.\n\n### **4. Ops as infrastructure consultants**\n\nThis model works best for companies with a traditional IT group that has multiple projects and includes ops pros. It’s also good for those using a lot of cloud services or expecting to do so. \n\nHere, ops acts as an internal consultant to create scalable web services and cloud compute capacity, a sort of mini-web services provider. In our [2021 Global DevSecOps Survey](/developer-survey/), a plurality of ops pros told us this is _exactly_ how their jobs are evolving — out of wrestling toolchains and into ownership of the team’s cloud computing efforts. Dev teams continue to do their work, with DevOps specialists within the dev group responsible for metrics, monitoring, and communicating with the ops team.\n\n### **5. DevOps-as-a-service**\n\nYou may decide your organization just doesn’t have the internal expertise or resources to create your own DevOps initiative, so you should hire an outside firm or consultancy to get started. This [DevOps-as-a-service (DaaS) model](https://medium.com/swlh/pros-and-cons-of-devops-as-a-service-a40b8796533c) is especially helpful for small companies with limited in-house IT skills.\n\nUsing DaaS in the short term offers another advantage: the opportunity to learn from your outsourcer how to eventually create your own internal DevOps team.\n\nMake sure you understand the outsourcer’s security landscape and your own responsibilities in this area, as you would with any outside firm. The difference here is that the team, processes, and software the outsourcer plans to use will be deeply embedded in your company’s infrastructure — it’s not something you can easily switch from. Also ensure that the outsourcer’s tools will work with what you already have in-house.\n\nFinally, keep a keen eye on costs and understand how the outsourcer will charge for its services.\n\n## Other organizational DevOps schemes include:\n\nA two-tier model, with a business systems team responsible for the end-to-end product cycle and platform teams that manage the underlying hardware, software, and other infrastructure. \nDevOps and SRE groups are separate, with DevOps part of the dev team and Site Reliability Engineers part of ops. This model requires a mature operations and development culture. \n\nWhichever organization model you choose, remember the idea of DevOps is to break down silos, not create new ones. Constantly reevaluate what’s working, what’s not, and how to deliver most effectively what your customers need.\n\n## Key characteristics of a successful DevOps team\n\nHere are some key charecteristics that you can expect to find in a well running DevOps team:\n\n* **Collaboration.** A DevOps team may have as few as 2 members to as many as 12 or more. \n* **Communication.** Nothing creates more bottlenecks on a team than members who don’t talk to each other, and DevOps projects always have a million moving parts. Document progress in a project thread, have regular meeting syncs or check in via Slack to keep team members up to speed and discuss any hurdles to avoid burnout or major delays. \n* **Team autonomy.** Work together, but also be able to work alone.\n* **Willingness to iterate.** Nothing will be perfect the first time, or even the second. In fact, a lot of DevOps work is just about making continuous, as-needed improvements to existing work, or replacing something that is no longer working for the original purpose. Keep on iterating!\n* **Fast feedback, high empathy and trust.** DevOps can feel like a whirlwind. Be mindful and respectful of the difficulties your teammates may be dealing with, be ready to give and receive feedback quickly, and trust each other for an optimal outcome and pleasant work environment.\n\n## Getting started with DevOps\n\nThere are a few steps to follow in order to get started on the planning and development of your DevOps team. Here are some pointers:\n\n**1. Create a roadmap.** Start with the basic goals, add in wish list items, and write it all out attaching a timeframe as needed. The map should include a list of action items broken down by priority and who is responsible for completing each step.\n\n**2. Ensure buy-in, and maybe add a champion.** Evangelize DevOps to the entire organization. Some teams find having a dedicated DevOps champion can help. \n\n**3. Select the solution.** Consider the budget, needs, and knowledge levels to make the best technology choices for the team.\n\n**4. Automate processes where appropriate.** DevOps doesn’t work without automation and for many teams, automation is the top priority. Look at areas where you can reduce manual work.\n\n**5. Set up monitoring.** Have a process for monitoring security, metrics, and everything in between.\nTrack progress. Always be able to give stakeholders a status update.\n\n_Johanna Ambrosio is a technology writer in the greater Boston area._\n",[695,9,3257],"growth",{"slug":3259,"featured":6,"template":698},"key-organizational-models-for-devops-teams","content:en-us:blog:key-organizational-models-for-devops-teams.yml","Key Organizational Models For Devops Teams","en-us/blog/key-organizational-models-for-devops-teams.yml","en-us/blog/key-organizational-models-for-devops-teams",{"_path":3265,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3266,"content":3272,"config":3278,"_id":3280,"_type":13,"title":3281,"_source":15,"_file":3282,"_stem":3283,"_extension":18},"/en-us/blog/keys-to-success-for-product-operations",{"title":3267,"description":3268,"ogTitle":3267,"ogDescription":3268,"noIndex":6,"ogImage":3269,"ogUrl":3270,"ogSiteName":685,"ogType":686,"canonicalUrls":3270,"schema":3271},"3 keys to success for product operations","Learn how to set a foundation for product operations at your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682313/Blog/Hero%20Images/prodops-keys-elena-mozhvilo-Lp9uH9s9fss-unsplash.jpg","https://about.gitlab.com/blog/keys-to-success-for-product-operations","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"3 keys to success for product operations\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Farnoosh Seifoddini\"}],\n \"datePublished\": \"2022-05-24\",\n }",{"title":3267,"description":3268,"authors":3273,"heroImage":3269,"date":3275,"body":3276,"category":910,"tags":3277},[3274],"Farnoosh Seifoddini","2022-05-24","\n\nIt is official. Product operations is a thing. A quick Google search will pull up a long list of articles singing the praises of everything product operations has to offer, from making product managers more efficient to data collection and synthesis. \n\nWhen I first took on [product operations at GitLab](/direction/product-operations/), there wasn’t a lot of definition or guidance on the topic. I understood what product operations meant because I’d been “doing it” as an inseparable part of my product management and product leadership roles for some years. But I’d never had the opportunity to focus solely on product operations.\n\nAs excited as I was, I was also nervous. GitLab was [accelerating toward an IPO](/blog/gitlab-inc-takes-the-devops-platform-public/) and both the product management team and the product were in hyper growth mode. And, to boot, the all-remote, cross-functional teams were in motion, sync and async, day and night, all around the globe. So, I reached out to peers who had already started their product operations journey and leveraged the perspective, progress, and learnings they generously shared. And, in doing so, I realized everyone was doing it a bit differently. \n\nNow, two and a half years later, product operations is a thing at GitLab. And the most common question I get from peers reaching out to me is: How can I set up product operations for success at my organization? \n\nTo answer this question, I will assume we all want to be product-led and customer-centered, and “success” would be product operations helping us get there. I’ll also assume we agree with the sentiment that’s evolved [defining product operations responsibility](https://www.pendo.io/glossary/product-operations/) to fall into these core areas: tools, data, experimentation, strategy, and trusted advisor. \n\nWhile there is no one formula, I will share three keys that opened doors for product operations to make an impact and grow with GitLab.\n\n### 1. Empower product operations as its own function, with an equal seat alongside other value-driving functions\n\nAt GitLab, we run product operations as an independent function under the product umbrella. The direct line of responsibility to the head of all product ensures product operations has awareness, alignment, and accountability to the macro needs of the product and the business. This also allows product operations to maintain a broad and unbiased view, as well as the right level of influence, to develop strategies/tactics serving the product and the business without favor toward any particular group. This [Silicon Valley Product Group article](https://www.svpg.com/product-ops-overview/) by Marty Cagan provides more helpful context on the why of this approach. \n\n### 2. Make product operations a people-first operation\n\nBefore product operations can deliver on efficiencies and tools that are useful for the product and the business, product operations must understand all of its internal customers. The first year product operations took shape at GitLab, much of my energy was focused on building relationships, not only with product team members but across the whole organization. Becoming a trusted advisor runs deeper than just delivering data, it’s about sensing pain and building bridges. A product operations team that leads with empathy will elevate the organization rather than just serve the organization. \n\n### 3. Drive adoption of product operations strategies by providing opportunities for team ownership\n\nAt GitLab, [everyone can contribute](/company/mission/#everyone-can-contribute). Leveraging this mindset for product operations led to [more impactful and better-designed iterations](https://handbook.gitlab.com/handbook/values/#iteration) to the problems we were trying to solve. By collaborating with various team members across the organization to improve and implement the shared frameworks in the product system, we not only ensure better multi-dimensional solutions but also boost alignment and acceptance of the solutions as well. This approach also inspires team ownership of flexible workflows rather than a perception that product operations is the “enforcer” of rigid processes. \n\nThese three keys become more challenging to forge if they aren’t introduced to an organization early on. Even if not immediately feasible, it’s helpful to carve space for the philosophy upfront and start small to demonstrate the value of the approach as you build the foundation for product operations. In future posts, I will share strategies and tactics for each of these keys as well as answer the second most common question I get: What is a “product system”? \n\nIn the meantime, feel free to learn more about [what product operations drives](/direction/product-operations/) at GitLab and the product management resources we maintain in our [Product Handbook](/handbook/product/).\n\n\n\nCover image by [Elena Mozhvilo](https://unsplash.com/@miracleday?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n",[9,934,912,1097],{"slug":3279,"featured":6,"template":698},"keys-to-success-for-product-operations","content:en-us:blog:keys-to-success-for-product-operations.yml","Keys To Success For Product Operations","en-us/blog/keys-to-success-for-product-operations.yml","en-us/blog/keys-to-success-for-product-operations",{"_path":3285,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3286,"content":3292,"config":3298,"_id":3300,"_type":13,"title":3301,"_source":15,"_file":3302,"_stem":3303,"_extension":18},"/en-us/blog/leah-petersen-user-spotlight",{"title":3287,"description":3288,"ogTitle":3287,"ogDescription":3288,"noIndex":6,"ogImage":3289,"ogUrl":3290,"ogSiteName":685,"ogType":686,"canonicalUrls":3290,"schema":3291},"From motorcycle stunter to DevOps: Finding love for CI/CD","Switching to GitLab helped a newly minted DevOps engineer grasp the concept of CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663760/Blog/Hero%20Images/image-for-leah-post.jpg","https://about.gitlab.com/blog/leah-petersen-user-spotlight","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Motorcycle stunter turned DevOps engineer says GitLab helped her learn to \"love\" CI/CD\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n \"datePublished\": \"2018-06-21\",\n }",{"title":3293,"description":3288,"authors":3294,"heroImage":3289,"date":3295,"body":3296,"category":693,"tags":3297},"Motorcycle stunter turned DevOps engineer says GitLab helped her learn to \"love\" CI/CD",[2125],"2018-06-21","\nWhen professional motorcycle stuntwoman turned developer Leah Petersen switched from Jenkins to GitLab, she was a bit nervous to say the least. Having only worked in tech for nine months, the [Samsung SDS](https://www.samsungsds.com/us/en/index.html) engineer was not enthused about the prospect of having to learn a new application after feeling like she had “just started to get competent” with Jenkins.\n\nAfter a self-described mini pity party, she dove into GitLab head first, jumping into a few big ticket projects to get a handle on the landscape. Within a few short months, Petersen was so impressed by her GitLab CI/CD experience that she felt the need to shout her newfound “love” for continuous integration and continuous delivery from the virtual mountaintop of [her blog](https://leahnp.github.io/2018/moving-from-jenkins-to-gitlab-CI/).\n\nWe recently met up with Petersen to learn more about her transition to the tech world and experience with GitLab.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/Avx_RftRT_o\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Q & A with Leah Petersen, DevOps Engineer\n\n**Where do you work and what does your team do?**\n\nI work for a team in Samsung SDS called the Cloud Native Computing Team, and I'm [a DevOps engineer](https://about.gitlab.com/topics/devops/what-is-a-devops-engineer/). We deal primarily with containers in Kubernetes and helping companies modernize and move to the cloud. My team is super unique. We were kind of treated like an incubated startup within Samsung, so we're really given a lot of autonomy to make our own decisions.\n\nOur team was put together about five years ago, and Samsung really made a bet on Kubernetes being the future of orchestrating huge workloads in the cloud. Initially, we were focusing mainly on research and development, contributing to the Kubernetes community and learning who was a part of it, what their motives were, and how we could find our place in it. Over the last year, Samsung has really pivoted our role in the company, and we're looking at how we can help Samsung as a global organization move to Kubernetes and containers.\n\n**Where did you work before Samsung?**\n\nI was a motorcycle stunt rider before I became an engineer, and that career kind of organically grew out of my passion for motorcycles. I started stunting, loved the community and was able to meet people all over the country and travel. Being one of the few women who did it, I organically started getting calls for jobs and gigs. I thought, “If I can do this in my 20s and make this my full-time career, I'm definitely going to take a shot at it,” so I did.\n\nIt was an amazing opportunity and experience to travel the world and meet people all over this planet who are passionate about this crazy thing that I'm also passionate about. And I got to work with a lot of amazing brands and raise awareness about the sport that I love. So, I don't have any regrets about that and cherish the time that I got to spend on a motorcycle professionally.\n\n**How did you move from being a professional motorcycle stunter to a DevOps engineer?**\n\nI had been looking for a new career path and wasn't really sure what I was going to do. I knew that I wanted to build some tangible skills. I wanted skills that had a clear market value, and tech definitely provides that.\n\nI ended up taking an online coding course in Python, and had this “aha” moment where I realized, not only can I do this, which I didn't think was previously possible, but it's fun; I really like solving these problems. At that point I started taking more online courses and learning as much as I could for free. Then I ended up finding [Ada Developers Academy](https://www.adadevelopersacademy.org/), and that was the perfect segue into the industry.\n\n> I had this “aha” moment where I realized, not only can I do this, which I didn't think was previously possible, but it's fun\n\n**Can you describe how your experience has been as woman in tech?**\n\nYou definitely get a lot of strange reactions being a woman in tech. Walking into a situation, oftentimes people are surprised you're an engineer. You'll get reactions like, “Oh, I thought you were a project manager,” or, “I thought you were a recruiter,” or whatever other stereotype that you brought into the room. That can be discouraging and makes you feel unwelcome in that space. But I think we need women in every part of tech: frontend, backend, DevOps, operations, everything. If your interest is in UX, go for that. But don't let all the men who've been in the industry for 25 years on the operations side of things scare you off either. I really think we need diverse minds and approaches to problems in the whole spectrum of it.\n\nSometimes I forget about the gender disparity in tech because my team, specifically, has a couple of really amazing women who I get to work with every day. So, I'm very fortunate. But I recently went to KubeCon in Copenhagen, and it's a amazing conference with so much energy, but it's a real wake up call when you see the gender disparity there. There's 4,000 guys walking around and you feel like you stick out [or] when you're sitting in an auditorium, look around and realize, “Oh, I'm the only lady here.” It's something that you can't look away from.\n\n**Why did you decide to go into DevOps engineering?**\n\nIn my boot camp classes we were focusing on web development and building Ruby on Rails and Node.js apps. We each had an opportunity to do an internship at companies in Seattle that support the Ada program. Samsung was one of them, and they came in to do a presentation about their involvement in open source and Kubernetes. I had no idea what they were talking about, but Kubernetes and the momentum of the open source community was really appealing to me. So I took a chance and picked Samsung, dove right in, and found my way as I went along. I'm really happy that I chose Kubernetes and to specialize in the cloud.\n\n>Kubernetes and the momentum of the open source community was really appealing to me. So I took a chance, dove right in, and found my way as I went along\n\n**How did you get started with GitLab CI/CD? And how would you describe your transition to the application?**\n\nI always felt like I was fighting with the CI platform we were on prior to GitLab. It was never really functioning how we wanted it to, and something was always kind of failing. The whole reason you have CI/CD is to get visibility into what's happening with your code, right? You want to run your code through this pipeline and make sure there are no bugs, that you’re packaging it correctly and putting it in the places that you need it to be in production. It's this hugely critical component of going from the developer's computer to the world; that's the pipeline. So you really need the visibility to see what is happening every step of the way.\n\nOn the old system, I felt that I just didn't have that visibility. I was digging for the problems and not able to understand where they were coming from, where they were originating from, why they were happening or how to fix them. I feel like GitLab definitely does a great job of assisting the user in finding the origin of a problem, tracing that step back and making it clear where your issues are and when you're having success.\n\n**How has using GitLab impacted your career and workflow?**\n\nThere's a lot of talk about accessibility and user experience in tech. And we all know what it's like to have a bad user experience with a piece of technology; it's the most frustrating thing in the entire world. As a developer, you deal with lots of different tech every single day. When I started using GitLab about a year and a half into my career, it was certainly the first platform where I was like, ‘I feel so at home here. Everything’s fluid. I can find where everything is. I understand what everything is.’ There aren't these big black holes of confusion that have me asking, “Why does this exist and what am I doing here?’”\n\nWith GitLab, everything is just this cheery, happy place. And I really appreciate how it has now set the bar for me when it comes to the way in which a technology should function when I’m working with it.\n\nCover photo by [Rendiansyah Nugroho](https://unsplash.com/photos/JUePy_-uOSI) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[737,2382,3045,787,9,268,695,1263],{"slug":3299,"featured":6,"template":698},"leah-petersen-user-spotlight","content:en-us:blog:leah-petersen-user-spotlight.yml","Leah Petersen User Spotlight","en-us/blog/leah-petersen-user-spotlight.yml","en-us/blog/leah-petersen-user-spotlight",{"_path":3305,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3306,"content":3312,"config":3318,"_id":3320,"_type":13,"title":3321,"_source":15,"_file":3322,"_stem":3323,"_extension":18},"/en-us/blog/lee-tickett-my-gitlab-journey",{"title":3307,"description":3308,"ogTitle":3307,"ogDescription":3308,"noIndex":6,"ogImage":3309,"ogUrl":3310,"ogSiteName":685,"ogType":686,"canonicalUrls":3310,"schema":3311},"From user, to advocate, to contributor: my GitLab journey","Three years (as a user and as a contributor) with GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681735/Blog/Hero%20Images/cover_photo.jpg","https://about.gitlab.com/blog/lee-tickett-my-gitlab-journey","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"From user, to advocate, to contributor: my GitLab journey\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Tickett\"}],\n \"datePublished\": \"2020-11-13\",\n }",{"title":3307,"description":3308,"authors":3313,"heroImage":3309,"date":3315,"body":3316,"category":716,"tags":3317},[3314],"Lee Tickett","2020-11-13","{::options parse_block_html=\"true\" /}\n\n\n\n\nI have had a passion for technology since before I can remember. Thirteen\nyears ago I took the plunge, quit my day job, and started an IT development\nand support company called [Tickett Enterprises\nLimited](https://www.tickett.net). For the last three years, GitLab has been\na part of my journey.\n\n\n## 3 Years Ago \n\nWe were (and still are) using a helpdesk system we built ourselves. It does\nexactly what we need it to do - and any time it doesn’t, we change it. The\nmost important feature of the system is reporting. Specifically,\nfacilitating our monthly billing process; with a click of a button, we\ngenerate timesheets and invoices for all of our clients.\n\n\nThough I was aware of Git (and GitHub), I had not heard of GitLab. We were\nusing SVN in its most basic form (single repository for all projects and no\nbranching), with an integration so all commits would create notes in our\nhelpdesk.\n\n\n## 2.5 Years Ago\n\nWe decided that SVN was no longer fit for purpose. Our top issues were: \n\n* never knowing whether the code in our repository matched what was deployed\n\n* not being able to work collaboratively on projects\n\n* feature/knowledge limitations\n\n* Git was the industry standard \n\n\nWhile most of these issues were due to the way we were using SVN, we were\nkeen to adopt a more popular system. I don’t remember how I found GitLab,\nbut I did, and spun up a local on-prem instance of Community Edition (CE)\nusing separate projects/repositories and basic branching. If you are\nconsidering running a local instance, I recommend the [Bitnami\nappliance/.ova](https://bitnami.com/stack/gitlab).\n\n\nIt took some time to get used to local vs remote and to remember to push as\nwell as commit, but we picked it up pretty quickly.\n\n\n## 2 Years Ago\n\nWe wanted to use GitLab to help us improve our processes so we:\n\n* built a little UI for project creation (using the GitLab API). This\nensures new projects fit our naming standards, contain our standard template\nfiles, have our standard master/test/dev branches, contain the relevant\nmembers, and use our webhooks\n\n* recreated the helpdesk integration we had with SVN (every commit and\ncomment is replicated as a note on our helpdesk)\n\n* unaware of GitLab EE, we created a custom merge request approval process\nusing webhooks. Our master branch is always protected - a merge request\nrequires 2 approvals from 2 distinct reviewers (one for code and one for\nfunctionality)\n\n\n## 1.5 Years Ago\n\nA bit late to the party, but finally we set up the GitLab runner to automate\nour build, spin up our database, execute our unit tests and report test\ndetails and code coverage. GitLab CI for .NET was not as well documented as\nother use cases leading to a lot of trial and error when setting up the\nrunner.\n\n\nWe are using the Windows runner configured to use a standard shell (which I\nthink is no longer supported). We will either be moving to powershell on\nwindows or possibly using docker images. Here’s a sample .gitlab-ci.yml\n\n\n```yml\n\nstages:\n - build\n - test\n\nvariables:\n CI_DEBUG_TRACE: \"false\"\n ASSEMBLY_VERSION: \"1.0.4\"\n \nbuild:\n stage: build\n script:\n - 'C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\nuget restore'\n - '\"C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\MSBuild\\15.0\\bin\\msbuild\" /t:Restore,Clean,ReBuild /t:Database:Publish /p:Configuration=Debug;Platform=\"Any CPU\" /p:SqlPublishProfilePath=Database.publish.xml'\n - 'ping 192.168.99.99 -n 1 -w 10000 2>nul || type nul>nul'\n artifacts:\n paths:\n - Tests/bin/\n\ntest:\n stage: test\n script:\n - 'c:\\GitLab-Runner\\opencover\\OpenCover.Console.exe -returntargetcode:1000 -filter:\"+[*]* -[nunit*]* -[*Tests*]*\" -register -target:\"C:\\Program Files (x86)\\NUnit.org\\nunit-console\\nunit3-console.exe\" -targetargs:\"Tests\\Tests.csproj --result=testresult.xml;transform=C:\\gitlab-runner\\nunit3-junit.xslt\"'\n coverage: '/^Visited Branches .*(\\(\\d+\\.?\\d*\\))/'\n dependencies:\n - build\n artifacts:\n reports:\n junit: testresult.xml\n```\n\n\nWe were building another customization to allow us to search for code across\nall repositories. Unfortunately, we hit a limitation because the API did not\nallow searching anything but the default branch.\n\n\nAt this point, while Googling for help getting CI up and running, I learned\nthat GitLab is open-source. So I thought maybe I could extend the API to\nsupport searching any branch. This lead to [my first\ncontribution](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28069).\n\n\n## 1 Year Ago\n\nAt this point, I was completely new to all of the technologies, techniques,\nand best practices used by GitLab but found myself participating in my first\n[GitLab hackathon](https://about.gitlab.com/community/hackathon/). Somehow,\nI managed to take joint first prize!\n\n\nMy first few contributions were achieved by modifying my production GitLab\ninstallation (not ideal). So it was time to get the [GitLab Development Kit\n(GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) up and running.\nThis was certainly not without its challenges (many of which I suspect stem\nfrom me being in the minority of GitLab contributors running Windows).\n\n\nI have since contributed to the [GDK\nproject](https://gitlab.com/gitlab-org/gitlab-development-kit) and joined\nthe GDK office hour calls to help shape the way forward and resolve some of\nthe problems and frustrations.\n\n\nAt this point, I was leearning a lot. Not just about the tools and languages\nbut about the best practices and work ethos within the GitLab team. Better\nyet, I was able to start taking some of these learnings back to the office.\n\n\n## 0.5 Years Ago\n\nI attended GitLab Commit - London 2019. This really helped to confirm my\nsuspicions; we are only scraping the surface of GitLab's capabilities.\n\n\nOn a few occasions, I wondered whether GitLab may not be a good fit for my\ncompany as I watched huge companies like Porsche and Goldman Sachs present.\nA [presentation](https://www.youtube.com/watch?v=t0Eh1sq9r5s) by Huss\nEl-Sheikh from startup 9fin helped ease my concerns.\n\n\nAround this time, I moved from Windows to Ubuntu to make it easier to work\nwith GDK.\n\n\nI continued to learn a lot from my contributions, feedback, and interactions\nwith the GitLab team, again applying what I could back in the office. Much\naround the languages/technologies I hadn’t previously worked with (namely\nruby, postgres and vue), but also other takeaways such as:\n\n* when carrying out code reviews ask questions rather than give instructions\n(“what do you think about x?” is more productive than “change this to y”)\n\n* GitLab CI is capable of automating a lot of what we currently do by hand\n(e.g. code review for best practices)\n\n* always try to add tests when making code changes\n\n\nI am a firm believer of documenting processes, decisions, and rationale.\nThere’s nothing worse than someone saying “we do it this way” without being\nable to back that up with reasoning. With that in mind, we implemented Merge\nRequest Templates to ensure our team was consistent in our approach to\ncoding, testing, and releasing.\n\n\nBy now our development team had plenty of experience with GitLab and we were\nstarting to move our support team over. To help our team leads monitor merge\nrequests, we adopted 2 simple departmental labels (`Support`/`Development`)\nand used our webhook engine to ensure every MR is automatically labelled.\n\n\n## Today / What’s Next\n\nIn preparation for a transition to .NET core, deprecation of the Windows\nshell runner and a desire to start testing our frontend (web), I started\nputting a CI script together using docker and the\nmcr.microsoft.com/dotnet/core/sdk:latest image. The .gitlab-ci.yml looks\nlike;\n\n\n```yml\n\nstages: \n - build\n - test\n\nvariables:\n CI_DEBUG_TRACE: \"false\"\n ASSEMBLY_VERSION: \"1.0.1\"\n\nbuild:\n stage: build\n tags:\n - docker\n script:\n - 'dotnet build'\n\ntest:\n stage: test\n tags:\n - docker\n script:\n - 'nohup dotnet run --project Web &'\n - 'apt-get update'\n - 'apt-get install -y unzip'\n - 'wget https://chromedriver.storage.googleapis.com/83.0.4103.14/chromedriver_linux64.zip'\n - 'unzip chromedriver_linux64.zip -d ~/'\n - 'rm chromedriver_linux64.zip'\n - 'mv -f ~/chromedriver /usr/local/bin/chromedriver'\n - 'chown root:root /usr/local/bin/chromedriver'\n - 'chmod 0755 /usr/local/bin/chromedriver'\n - 'wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -'\n - 'sh -c ''echo \"deb https://dl.google.com/linux/chrome/deb/ stable main\" >> /etc/apt/sources.list.d/google.list'''\n - 'apt-get update'\n - 'apt-get install -y google-chrome-stable'\n - 'dotnet test -l:trx Tests/Tests.csproj /p:CollectCoverage=true'\n coverage: '/Total\\s*\\|.*\\|\\s(\\d+\\.?\\d*)%\\s*\\|.*\\|/'\n```\n\n\nAnd the tests look something like;\n\n\n```c#\n public class UiTests : IDisposable\n {\n private readonly Process _webServerProcess;\n private readonly IWebDriver _driver;\n\n [Fact]\n public void ClickNavPrivacyPolicy()\n {\n _driver.Navigate()\n .GoToUrl(\"http://localhost:5000/\");\n\n var link = _driver.FindElement(By.LinkText(\"Privacy\"));\n link.Click();\n\n Assert.Equal(\"http://localhost:5000/Home/Privacy\", _driver.Url);\n }\n\n public UiTests()\n {\n ChromeOptions chromeOptions = new ChromeOptions();\n chromeOptions.AddArguments(\"headless\", \"no-sandbox\");\n _driver = new ChromeDriver(chromeOptions);\n\n if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux)) return;\n\n _webServerProcess = new Process\n {\n StartInfo = {\n WorkingDirectory = Path.Combine(System.AppDomain.CurrentDomain.BaseDirectory, \"..\", \"..\", \"..\", \"..\", \"Web\"),\n FileName = $\"dotnet.exe\",\n Arguments = \" run\",\n UseShellExecute = true,\n }\n };\n _webServerProcess.Start();\n }\n\n private void KillWebServer()\n {\n if (_webServerProcess != null && !_webServerProcess.HasExited)\n {\n _webServerProcess.Kill();\n }\n }\n\n public void Dispose()\n {\n _driver.Dispose();\n KillWebServer();\n }\n }\n```\n\n\nYou can see some conditional code in there which allows Selenium tests to\nwork both locally on our development machines and remotely on our GitLab\nrunner. If you have a better way of achieving this, please leave a comment.\nI would love to chat and learn!\n\n\nI also want to start introducing some linting like we see in the GitLab\nproject to enforce rules around code formatting (spaces, carriage returns,\nindentation, etc.). I have started to look at JetBrains Resharper (R#)\ncommand-line but haven’t had enough time to implement it yet. Ideally. I\nwould like to start with just a rule or two and then slowly introduce more,\nbut it looks quite tricky to take this approach. Please let me know if\nyou’ve been able to achieve this!\n\n\nI would also like to lose our helpdesk and start using GitLab issues,\nservice desk, timelogs, etc. I am working on identifying the gaps and\nworking with the product managers to understand whether it is realistic to\nfill those gaps within the GitLab product. Alternatively, I will be looking\nto build some additional “bolt-ons” using webhooks and the API.\n\n\nWhile investigating gaps, I stumbled upon the [GitLab-Triage\nproject](https://gitlab.com/gitlab-org/gitlab-triage) and I expect we'll use\nthis to automate various workflows. I managed to help close a few issues and\neven create a few additional features which would make it work for us by\n[contributing to the GitLab-Triage\nproject](https://gitlab.com/gitlab-org/gitlab-triage/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=leetickett).\n\n\nWe also added more labels (`needs code review` & `needs functional review`)\nfor our merge request approval process now. We can see where we are and what\nneeds to be done at a glance. We previously relied on an MR checklist that\nwe are deprecating.\n\n\n![Merge request\nchecklist](https://about.gitlab.com/images/blogimages/lee-tickett-my-gitlab-journey/mr_checklist.png)\n\n\n![Merge requests with\nlabels](https://about.gitlab.com/images/blogimages/lee-tickett-my-gitlab-journey/merge_requests_with_labels.png)\n\n\n## Contributing to GitLab \n\n\nI am very proud to have joined the GitLab Core Team. Thanks to everyone who\nhas held my hand and patiently assisted me with contributions. \n\n\nWith the release of Microsoft Windows Subsystem for Linux v2, I have gone\nback to running Windows on my laptop with GDK running in Ubuntu on WSL2.\nThis is working brilliantly for me at the moment (the way Visual Studio Code\nhandles things especially is really cool).\n\n\nI now have 95 [merged merge\nrequests!](https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=leetickett)\nand have been helping several others get started contributing (getting GDK\nup and running etc). Once this crazy pandemic is over and we can start to\nsocialise again, I would like to try and start some sort of local\nmeetup/group.\n\n\nI would like to help make it easier to connect GitLab users. I have visions\nof a mechanism to search for others based:\n\n* the size of their user base \n\n* the languages they are using\n\n* the feature they are using\n\n\nAt present, we have several tools (Gitter, Issues, Forum etc) but there is a\nstrong reliance on being engaged and stumbling on questions/support\nrequests. I suspect many of us would be happy to have other users reach out\ndirectly.\n\n\nIf you need any more information around:\n\n* getting your development environment/tools setup on Windows 10\n\n* getting CI working with .NET and SQL Server projects\n\n* building customisations using GitLab webhooks and API\n\n\n...or would like to see a demo of anything discussed above, I would be happy\nto oblige!\n\n\nI would love to connect with others who are either looking to, or already\nusing GitLab for:\n\n* .NET projects\n\n* customer helpdesk \n\n* customer billing (using timelogs)\n\n\nThanks for reading! Here's a picture of me and the family repping with our\nGitLab merch!\n\n\n![The tickett family repping\nGitLab](https://about.gitlab.com/images/blogimages/lee-tickett-my-gitlab-journey/landing_page.png)\n",[108,268,1263,912,787,695,9],{"slug":3319,"featured":6,"template":698},"lee-tickett-my-gitlab-journey","content:en-us:blog:lee-tickett-my-gitlab-journey.yml","Lee Tickett My Gitlab Journey","en-us/blog/lee-tickett-my-gitlab-journey.yml","en-us/blog/lee-tickett-my-gitlab-journey",{"_path":3325,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3326,"content":3332,"config":3337,"_id":3339,"_type":13,"title":3340,"_source":15,"_file":3341,"_stem":3342,"_extension":18},"/en-us/blog/lendlease-driving-change-with-gitlab",{"title":3327,"description":3328,"ogTitle":3327,"ogDescription":3328,"noIndex":6,"ogImage":3329,"ogUrl":3330,"ogSiteName":685,"ogType":686,"canonicalUrls":3330,"schema":3331},"How global real estate company Lendlease is driving change with GitLab","Learn how Lendlease is using GitLab to improve visibility, foster collaboration, and empower everyone to be responsible for security.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670317/Blog/Hero%20Images/blog-banner-blue-neon.png","https://about.gitlab.com/blog/lendlease-driving-change-with-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How global real estate company Lendlease is driving change with GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2023-10-23\",\n }",{"title":3327,"description":3328,"authors":3333,"heroImage":3329,"date":3334,"body":3335,"category":1304,"tags":3336},[734],"2023-10-23","\n\nWhen Lendlease, a $6 billion (AUD) multinational real estate company, needed to facilitate a culture change in their software development teams, they turned to GitLab and its DevSecOps platform.\n\nThat’s the message Ciaran Hennessy, chief software architect for Lendlease Digital, a business unit of Lendlease, shared in an on-stage interview at the Melbourne, Australia, stop of [GitLab’s DevSecOps World Tour](https://about.gitlab.com/events/devsecops-world-tour/). By beginning to eliminate a complicated toolchain with an end-to-end platform, the Sydney-based organization has been able to fuel collaboration, increase visibility, and make everyone responsible for security.\n\n“We were breaking the old models of culture and teams,” said Hennessy, a self-described “uber nerd” with 23 years of experience in the tech industry. “Especially after COVID permanently transformed the working environment, we needed to create cohesion in teams when you can't have them all in the same room. And that gave us the opportunity to make other changes to the way we handle security, visibility, and managing our legacy technology.”\n\nIn an interview with Craig Nielsen, vice president of enterprise sales at GitLab, Hennessy also talked about pushing legacy technology into pipelines, and how he expects generative artificial intelligence (AI) will come into play.\n\nLet’s jump into what Hennessy had to say.\n\n## Gaining “radical visibility”\n\nWhen the COVID pandemic pushed businesses toward hybrid work structures, Lendlease saw it as the perfect time to change the way people not only get their jobs done but how they see their role and responsibilities inside a DevOps team, according to Hennessy. The challenge was to figure out how to give everyone from executives to coders and security specialists visibility into how projects were progressing, where stumbling blocks were popping up, and what solutions worked best.\n\nUsing a single platform gave them what Hennessy called “radical visibility.”\n\n“We have no walls between our teams anymore,” he told the DevSecOp World Tour audience. “Everybody can see everything. We’re empowering people to look at everything and learn about other parts of a project. It enables people to say, ‘Oh, I also had that problem. Let me help you solve that.’ And people aren’t spending their time asking, ‘Does anybody know where this code is?’ or ‘Does anybody know who worked on this last time?’ Everybody can track all of the work.”\n\nHennessy called this level of visibility a “game changer” for Lendlease.\n\n## Fostering collaboration\n\nWith that transparency into projects and workflows, it simply was much easier and more natural for teams to work together. And since the company’s software development organization is spread from Australia to Singapore, the U.S., and the U.K., team members needed a way to work together that went beyond instant messaging and phone calls. \n\n“We gained shared knowledge and context,” said Hennessy. “The platform enabled people to contribute to what others were working on and it means an individual is able to produce more easily what they need to.”\n\nHe added that being able to see what’s happening with a project from start to finish enables managers to act as mentors and teachers, guiding DevOps workers and helping them learn new ways to do their jobs. “I tell people that visibility doesn’t mean you’re the cop,” he added. “You’re the ones sitting on the edge cheering everybody on to do a good job. With a single platform, you’re creating those opportunities. This is where GitLab is really useful.”\n\n## Sharing security responsibility\n\nWhen Lendlease was considering adopting GitLab, a big part of the attraction was the fact that security was “baked into” the app, said Hennessy. With the GitLab DevSecOps Platform, security is pushed left, meaning developers start thinking about security when they begin planning new features or projects. And everyone can participate in securing code, so features or products aren’t left to only be tested right before production, stalling work and slowing releases.\n\n“Security is not an afterthought. It's part of the culture that we brought in,” said Hennessy. “Security is not useful in your software development process unless everybody is a security person. Everyone is responsible for security and with a platform that works.”\n\nHe noted that before using a platform, a developer might spot a vulnerability in his code but not fix it because he figured someone at the end of the process would deal with it. “Now, with the shift left, nobody is intentionally letting a security vulnerability go through into their product,” said Hennessy. “Someone might have created 20 vulnerabilities in their code, but it's fine because they were aware and acted responsibly, so the flaws never got through into a working environment.”\n\n## Adapting for the future \n\nA 65-year-old company, Lendlease has decades worth of legacy code. One challenge with that is some junior developers may not have experience working with older programming languages. However, it can still play a valuable role in the tech ecosystem. By taking a thoughtful and strategic approach to integrating legacy tech, the business is able to leverage its full technological capabilities while also prioritizing the needs of teams and stakeholders.\n\nSo how will they update or integrate this older tech? \n\n“There is so much value companies have invested in classic technology,” Hennessy explained. “We had applications running that no one had touched for 15 years. It's really hard to get people to work on that stuff because it's not cool and exciting. Try and give a mainframe application written in Modula-2 to a 23-year-old developer just out of university and see what happens.”\n\nHowever, using GitLab’s platform, Hennessy’s teams push legacy code into pipelines and containerize it. By creating container images that mimic the company’s current environments and dependencies, new developers can use that to work on and test the applications, applying new methodologies and best practices. \n\n“Good code never dies. It just becomes legacy,” said Hennessy. “We gave it new value.”\n\n## Adding muscle with generative AI\n\nHennessy is welcoming of generative AI, noting that he’s not really concerned about the technology replacing software developers’ jobs. He does, however, wonder how it will affect how, and how much, coders learn. \n\n“The bit I'm worried about is the loss of the foundational skills that good software developers have,” he explained. “AI will provide a lot of acceleration to get them past the things they might need to learn through time and experience, and doing stupid things and working through it. We could have a generation of software developers who know how to do all the top-layer stuff but they won’t know the foundational things of how it all works.”\n\nDespite those concerns, Hennessy told the Melbourne audience he expects using generative AI will be like adding extra hands to his DevSecOps teams. \n\n“The thing I find really interesting about it is you get a resource that you can use to help you create new value,” he said. “I’m really interested in how we can use it to massively accelerate creation.”\n\n_Lendlease is a globally integrated real estate group. Its core capabilities are reflected in three operating segments — investments, development, and construction. The combination provides them with the ability to deliver innovative integrated solutions for its customers._\n\n_Read more GitLab customer stories on our [customers page](https://about.gitlab.com/customers/)._\n",[1141,9,807],{"slug":3338,"featured":6,"template":698},"lendlease-driving-change-with-gitlab","content:en-us:blog:lendlease-driving-change-with-gitlab.yml","Lendlease Driving Change With Gitlab","en-us/blog/lendlease-driving-change-with-gitlab.yml","en-us/blog/lendlease-driving-change-with-gitlab",{"_path":3344,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3345,"content":3351,"config":3357,"_id":3359,"_type":13,"title":3360,"_source":15,"_file":3361,"_stem":3362,"_extension":18},"/en-us/blog/lessons-weet-learned-lokalise",{"title":3346,"description":3347,"ogTitle":3346,"ogDescription":3347,"noIndex":6,"ogImage":3348,"ogUrl":3349,"ogSiteName":685,"ogType":686,"canonicalUrls":3349,"schema":3350},"How Weet integrates localization into the GitLab pipeline with Lokalise","Localization is an increasingly important option for users. Here's how to integrate localization in your GitLab pipeline.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668543/Blog/Hero%20Images/lokalise_cover.png","https://about.gitlab.com/blog/lessons-weet-learned-lokalise","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How Weet integrates localization into the GitLab pipeline with Lokalise\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Alexander Pereverzevs\"}],\n \"datePublished\": \"2021-09-13\",\n }",{"title":3346,"description":3347,"authors":3352,"heroImage":3348,"date":3354,"body":3355,"category":757,"tags":3356},[3353],"Alexander Pereverzevs","2021-09-13","\n\nAs a GitLab customer, Weet has fully invested in the premise of \"Iterate faster, innovate together.\" Weet has a low tolerance for processes that don't keep pace with the way they develop and launch. One important process that was slowing the business down – localizing their app.\n\nLocalization is a key way to drive growth and accelerate product adoption. When done poorly, localization or l10n, as it's commonly known, can slow down your development process, introduce bugs, and make it cumbersome to launch updates. When done right, teams can smooth out the process and [continuously localize](https://lokalise.com/features/localization-process-automation) their app. We unpack how Weet conquered its localization problems using GitLab and Lokalise.\n\n## What is Weet?\n\n[Weet](https://beeweet.com) is an asynchronous video communication tool designed to reduce the need for meetings. By combining video, audio, and screen sharing, it provides the nuance that written communication simply does not. For example, Weet's 10-person team, which is spread between France and the US, uses the product to speed through code reviews. The product has also been used for demos, design feedback, bug reports, QA reviews, and client presentations. At Lokalise, we use the tool to communicate with team members across time zones with ease and clarity.\n\nWeet started using GitLab five years ago and is using the latest version (13.11 as of this writing). For the runner they use 13.11 too, with an auto-scalable configuration (best feature ever!). The instance is self-managed on Google Cloud.\n\nWeet uses roughly 50 pipelines to manage processes such as: building the entire stack of the Weet application, checking the unit tests, deploying to a QA environment, deploying in production, launching the end-to-end tests, and more. The company currently has 17 projects set up, which are combined with GitLab CI/CD to deploy the Weet application.\n\nThey are, in summary... GitLab fans.\n\n## The first l10n solution\n\nWhen Weet first started localizing their app the engineering team considered two options:\n\n1. Download CSV files of strings, email them to the translators, and then reintegrate the data after the translation work was complete\n2. Translate directly in the IDE\n\nBoth options had their drawbacks. Downloading and uploading files takes developers out of the flow, but worse than that, the process can introduce l10n bugs that make the app look unreliable or amateurish. Also, these problems take time to resolve. It's not uncommon for version control to be an issue with this type of system.\n\nWeet chose the Web IDE option because it was easier to get started, but the process wasn't working at the pace they wanted.\n\n>> \"Before we used the Lokalise integration, we had to validate the new wording before each code push. The process was time-consuming as approvers were spread across different time zones,\" - Geraud Bonou-Selegbe, Full-stack engineer at Weet.\n\nHunting through the code to change all the instances of a word that needs to be replaced is not high on anyone's list of fun things to do.\n\nIt wasn't long before Jeremy Rouet, the CTO and co-founder of Weet, started looking for new options. If they wanted to fulfill the CI/CD promise of GitLab, they needed a tool that would integrate cleanly into the pipeline. Jeremy began testing translation management systems (TMS) and settled on integrating [Lokalise with GitLab](https://docs.lokalise.com/en/articles/1789855-gitlab).\n\n## How to continuously localize your product\n\nLokalise integrates into GitLab and allows a user (like Weet) to pull files into Lokalise, where translation tasks can be assigned and completed and then easily merged back.\n\n![Schema of how Lokalise works in GitLab](https://about.gitlab.com/images/blogimages/lokalize1.png){: .shadow.medium.center}\nA schema of how Lokalise works in GitLab.\n{: .note.text-center}\n\nDevelopers code as normal aiming to complete their work prior to each weekly release. Each push on master sends text strings automatically into Lokalise. Lokalise detects any changes to the text, so the developers don't have to remember what exactly they changed. Jeremy then uses the task features in Lokalise to assign the translation tasks to the Weet marketing team, who then go in and check all the new words.\n\nOnce the translation team is done, they create a merge request, and the product is ready to launch.\n\n>> \"Lokalise enabled us to bridge this gap by letting developers do what they do the best: coding. If my phrasing is not perfect, language experts can review it on Lokalise and then send a merge request with their updates. Now we've got the right expert in the right place for each milestone of our development process,\" says Geraud.\n\n![Lokalise Merge Request in GitLab](https://about.gitlab.com/images/blogimages/lokalize2.png){: .shadow.medium.center}\nWhat a merge request looks like using Lokalise and GitLab.\n{: .note.text-center}\n\nGone are the days of manually updating translations in the IDE in order to fix phrasing. Now app localization is a seamless and reliable part of the development workflow of the CI/CD process that is built around GitLab.\n\n## Steps to set up the integration\n\nFull instructions are available here. With over 500 keys in the app, the Weet team created several internal processes to keep their work tidy.\nOne move they made was to split their localization data into 5 projects/files. Each localization is a .json file. The separate files are:\n\n- emails\n- frontend\n- integration\n- server-side rendering\n- mobile – iOS/Android (WIP)\n\nThen to simplify key maintenance they used a naming pattern so that each component has its own keys. When they delete a component, they simply remove the main key from the localization file, which removes each label for this component. See below:\n\n![Deleting a component and removing main key from the localization file](https://about.gitlab.com/images/blogimages/lokalize3.png){: .shadow.medium.center}\nHow to delete a component and remove the main key from the localization file.\n{: .note.text-center}\n\nFinally, they tackled conflicts. The developers are able to edit the localization files both in Lokalise and in their environment. Changes in multiple systems could clash. To solve this problem, they decided that developers can only use Lokalise to update labels and they can only add or remove keys in their local environment.\n\n## What localization delivers\n\nIt took the Weet team some time and trial and error to smooth out the process.\n\nNow that the process is totally seamless, they can localize a new release in less than an hour with just a short quality check. That’s a big improvement from the days when they had to synchronize the dev, PO, and QA teams over a few days, to check and correct the new localization.\n\nWith their ability to continuously localize their app, they can focus on developing and delivering the best product possible. And it seems to be working as they were recently voted the #2 (closed) product of the week on Product Hunt. Coming up on the roadmap – mobile apps and more languages.\n",[9,232,787],{"slug":3358,"featured":6,"template":698},"lessons-weet-learned-lokalise","content:en-us:blog:lessons-weet-learned-lokalise.yml","Lessons Weet Learned Lokalise","en-us/blog/lessons-weet-learned-lokalise.yml","en-us/blog/lessons-weet-learned-lokalise",{"_path":3364,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3365,"content":3371,"config":3376,"_id":3378,"_type":13,"title":3379,"_source":15,"_file":3380,"_stem":3381,"_extension":18},"/en-us/blog/lockheed-martin-aws-gitlab",{"title":3366,"description":3367,"ogTitle":3366,"ogDescription":3367,"noIndex":6,"ogImage":3368,"ogUrl":3369,"ogSiteName":685,"ogType":686,"canonicalUrls":3369,"schema":3370},"GitLab, AWS help strengthen Lockheed Martin’s digital transformation","Lockheed Martin’s software factory selected GitLab’s DevSecOps Platform, along with AWS, to streamline toolchains, increase collaboration, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668830/Blog/Hero%20Images/lockheed-martin-cover-2.jpg","https://about.gitlab.com/blog/lockheed-martin-aws-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab, AWS help strengthen Lockheed Martin’s digital transformation\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n \"datePublished\": \"2023-05-16\",\n }",{"title":3366,"description":3367,"authors":3372,"heroImage":3368,"date":3373,"body":3374,"category":757,"tags":3375},[690],"2023-05-16","\nLockheed Martin launched its 1LMX initiative to transform its end-to-end business processes and systems. One focus of the transformation was to pare down the company’s wide variety of DevOps tools – each program or product line at Lockheed Martin had its own toolchain. To mitigate this issue, drive rapid production, and increase collaboration, Lockheed Martin adopted GitLab’s DevSecOps Platform, run on AWS.\n\n“GitLab has strengthened our 1LMX transformation, upgrading the way we collaborate and innovate to develop software. Now, all of our programs have access to a high-quality software development environment,” said Alan Hohn, Lockheed Martin’s Director of Software Strategy.\n\nGitLab’s DevSecOps Platform enables Lockheed Martin to ship software more efficiently and securely for thousands of their programs, ranging from satellite platforms and aerospace systems to ground control software and maritime surface and subsurface software.\n\nHere are some top-level benefits that Lockheed Martin has seen with GitLab’s DevSecOps Platform:\n* Using GitLab’s single platform, Lockheed Martin’s legacy projects are delivered to testing every six days, down from a monthly cadence using distributed toolchains.   \n* Developers experienced a 90% reduction in time spent on system maintenance.\n* The organization has seen 200% annual growth in adoption of The DevSecOps Platform.\n* AWS enabled automated Infrastructure as Code for a scalable and resilient cloud architecture.\n\n## Efficiency gains\n\nIn migrating to GitLab, Lockheed Martin has realized a number of benefits and eliminated obstacles. In three and a half years, Lockheed Martin has created 64,000 projects on GitLab, and created 110,000 continuous integration builds daily. \n\nAdditionally, they were able to retire thousands of separately maintained servers thereby reducing time spent on maintenance by 90%. GitLab further enables internal efficiency within the organization by allowing teams to securely share reusable code components in globally accessible environments. Since implementing GitLab, Lockheed Martin teams have added 18 new repositories a day for the past two years. \n\n## How GitLab, AWS, and Lockheed Martin work together\n\nIn 2022, after rapid adoption of GitLab created the need for a more scalable solution, Lockheed Martin, GitLab, and AWS worked together to automate and optimize Lockheed Martin's code deployment across the enterprise. \n\nThe solution started with a well-architected review of the design between Lockheed Martin, AWS, and GitLab. AWS then helped to automate and optimize the Lockheed Martin GitLab deployment for continuous integration and continuous delivery (CI/CD) environment by delivering Infrastructure as Code to deploy the environment in two hours vs. several hours previously. \n\nThe AWS team also established workflows to deliver a fully automated, highly available, disaster recovery-compliant, scalable architecture for GitLab enabling a consistent process that runs without manual intervention.\n\nAWS supported load balancing to auto-scale the deployment process based on developer demand for pipeline runs and user traffic so that developers are not waiting on their deployments to execute. Pre-migration testing was performed to establish baselines, followed by post-migration testing to measure performance and scalability gains in delivering faster deployments. \n\nAdditionally, monitoring and security controls were implemented to comply with Lockheed Martin policies. As a result, the team was able to deliver operational efficiencies with the number of build requests waiting to be processed decreasing from 200 to zero, and reduced time for code deployment across the enterprise.\n\nThis effort showcased how large enterprises with thousands of software developers can build and deploy automated, scalable, and resilient code pipelines in the cloud using platforms such as GitLab by leveraging AWS best practices.\n\nGitLab’s Chief Product Officer David DeSanto added, “For more than a century, Lockheed Martin has set the standard for innovation within the public sector, and demonstrates what is possible when organizations invest in digital transformation efforts.”\n\nLockheed Martin has 20,000 GitLab users, and is looking to double that number and migrate even more of their projects over to The DevSecOps Platform in the coming years. To dig deeper into how Lockheed Martin uses GitLab, read [our case study](/customers/lockheed-martin), and to learn more about GitLab for the Public Sector, visit [our site](/solutions/public-sector/).\n",[1141,1988,9],{"slug":3377,"featured":6,"template":698},"lockheed-martin-aws-gitlab","content:en-us:blog:lockheed-martin-aws-gitlab.yml","Lockheed Martin Aws Gitlab","en-us/blog/lockheed-martin-aws-gitlab.yml","en-us/blog/lockheed-martin-aws-gitlab",{"_path":3383,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3384,"content":3390,"config":3396,"_id":3398,"_type":13,"title":3399,"_source":15,"_file":3400,"_stem":3401,"_extension":18},"/en-us/blog/making-remote-work-better",{"title":3385,"description":3386,"ogTitle":3385,"ogDescription":3386,"noIndex":6,"ogImage":3387,"ogUrl":3388,"ogSiteName":685,"ogType":686,"canonicalUrls":3388,"schema":3389},"Tangram Vision engineers succeed at remote work with GitLab","The start-up's developers can collaborate efficiently, handling everything from merge requests to code reviews, and providing a single source of the truth.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668018/Blog/Hero%20Images/allremote.jpg","https://about.gitlab.com/blog/making-remote-work-better","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab's DevOps platform enables Tangram Vision's engineering team to succeed at remote work\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lauren Gibbons Paul\"}],\n \"datePublished\": \"2022-04-21\",\n }",{"title":3391,"description":3386,"authors":3392,"heroImage":3387,"date":3393,"body":3394,"category":757,"tags":3395},"GitLab's DevOps platform enables Tangram Vision's engineering team to succeed at remote work",[2886],"2022-04-21","\n\nOn March 14, 2020, Tangram Vision CEO Brandon Minor flew from Colorado into the Bay Area to meet with COO Adam Rodnitzky. The two had just launched [Tangram Vision](https://www.tangramvision.com/), the company they co-founded to make sensors simpler for robotics, drones, and autonomous vehicles. Their plan was to, each month, alternate working at each other's location. However, that week, the Covid-19 pandemic lockdown began, forcing them to scrap that plan and figure out how to successfully collaborate from afar.\n\n“We didn’t see each other in person again for a very long time. That kicked off our remote work experience,” Minor says.\n\nThe Tangram Vision engineering team started using GitLab's DevOps platform, which enabled them to work together without missing a beat. “GitLab was a key tool that allowed us to work really fluidly in a remote context,” says Minor. “Our engineering team has placed GitLab at the core of our remote workflow because it reinforces our values and perspectives around working well remotely.”\n\nThe Tangram Vision Platform takes care of complex perception tasks like sensor fusion, calibration, and diagnostics built on a scalable data backend that allows engineers to track, optimize, and analyze every sensor in their fleet. Tangram Vision’s SDK includes tools for rapid sensor integration, multi-sensor calibration, and sensor stability, saving robotics engineers months of engineering time.\n\n## Supporting complex collaboration\n\nPerception systems are notoriously hard to get up and running and then maintain over time because of important lower-level activities like sensor integration and calibration. “We make sure all the sensors' data is running smoothly, everything's working together perfectly to basically a plug-and-play level. And then we enable the developers working on top of that to monitor and correct their system over time,” Minor says. \n\nTangram Vision has just launched a user hub that functions as a centralized sensor data center. The user hub joins their multi-sensor calibration module, as well as a multiplexing module that maintains stream reliability for all connected sensors. Developers can access a starter set of perception development tools (Tangram Vision Platform - Basic), which will be available on an open-source hub. Much of the initial user feedback will come through and be managed within repositories hosted on GitLab, both public and private, Minor says.\n\n## GitLab as a core for code\n\nThe engineering team has evaluated other platforms, according to Greg Schafer, senior web architect. “We’ve looked around but we've been very turned off by them for one reason or another. We really haven't swayed in wanting to use GitLab as our core for code,” Schafer says. \n\nThe team uses GitLab to manage branches and merge requests (MRs), boosting efficiency and control. “We were having a bit of a struggle early on managing the short-term flow. It was hard to put down tasks to paper. So, I dove deep into GitLab to see how it could help us there. And now that's what we use. GitLab is my product management tool,” Minor says.\n\nThe alternative, siphoning MRs into tools like Notion and Slack, would have been too cumbersome. “Having code-focused discussions in those places would've been very awkward vs. our current orientation of having those discussions in GitLab. Having that history of MRs and threads has been very useful,” Schafer says.\n\nDoing all of the code reviews in the MR itself builds a paper trail of documentation for the future. That means the team can look back at exactly when a change was introduced and find any discussion about potential trade-offs next to a change. This gives the engineers confidence in understanding the context behind a change months or years after it has been introduced. “It encourages team members to be able to work asynchronously, as that context is not held in any single individual’s head but instead written and made explicit,” Minor says.\n\n## A host of features and options in GitLab\n\nFor Rodnitzky, what stands out about GitLab is that it has a host of features and options in one place. “It’s not just hosting code and MRs and all those discussions and things around that, but also the [continuous integration/continuous delivery], having that tightly integrated is really helpful,” he says. For example, there are different types of reports that might show up on the MRs. GitLab makes it easy to reference different CI steps in the MRs. \n\n“You're not jumping to different websites or services to do that. It’s all in one place, which is super helpful,” he says.\n\nMinor agrees, and adds, “The amount of oversight I have into every process going on, the transparency that gives me as a product manager to make the next decision has been invaluable.” \n\nIt’s not a stretch to say the transparency enabled by GitLab is reflected in Tangram Vision’s business model. “We’re transparent with our customers and developers,” says Minor. “There are a couple of morsels of code that will be private for a while, but, for the most part, the mission of the company is to make any engineer a computer vision engineer. To do that, a lot of education and openness is required. That’s already part of our culture.”\n",[9,1141,695],{"slug":3397,"featured":6,"template":698},"making-remote-work-better","content:en-us:blog:making-remote-work-better.yml","Making Remote Work Better","en-us/blog/making-remote-work-better.yml","en-us/blog/making-remote-work-better",{"_path":3403,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3404,"content":3409,"config":3414,"_id":3416,"_type":13,"title":3417,"_source":15,"_file":3418,"_stem":3419,"_extension":18},"/en-us/blog/manage-agile-teams-with-microservices",{"title":3405,"description":3406,"ogTitle":3405,"ogDescription":3406,"noIndex":6,"ogImage":2257,"ogUrl":3407,"ogSiteName":685,"ogType":686,"canonicalUrls":3407,"schema":3408},"How to manage Agile teams with microservices","GitLab Groups and Projects can help teams divide work by product or system.","https://about.gitlab.com/blog/manage-agile-teams-with-microservices","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to manage Agile teams with microservices\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2019-08-23\",\n }",{"title":3405,"description":3406,"authors":3410,"heroImage":2257,"date":3411,"body":3412,"category":693,"tags":3413},[951],"2019-08-23","\n\nWe’re getting closer to the 2019 finish line, but there’s still time to jump on\nthe microservices train to accelerate your team’s delivery. We’ve written about\nmicroservices in the past, including discussing\n[best practices for microservices implementation](/blog/strategies-microservices-architecture/)\nand [GitLab’s integrated vision for microservices](/blog/microservices-integrated-solution/),\nbut I’m here to share something a little different: How you can use microservices\nto manage your team.\n\nBut first, a recap: Microservices is a collection of independently deployable\nservices that advances a goal, with each application managing a specific function\n_really_ well.\n\n> “The term ‘Microservice Architecture’ has sprung up over the last few years to\ndescribe a particular way of designing software applications as suites of\nindependently deployable services.” –\n[Martin Fowler](https://martinfowler.com/articles/microservices.html)\n\n## GitLab microservices for Agile team management\n\nUsing GitLab [Projects](https://docs.gitlab.com/ee/user/project/) and\n[Groups](https://docs.gitlab.com/ee/user/group/), teams can organize their work\nto increase visibility and collaboration. GitLab supports Agile teams by providing\n[Milestones](https://docs.gitlab.com/ee/user/project/milestones) (or sprints),\n[Issues](https://docs.gitlab.com/ee/user/project/issues/) (or user stories),\n[Weights](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) (or points and estimation),\nand other common [Agile artifacts](/blog/gitlab-for-agile-software-development/).\n\nHere are a few ways to use groups and projects:\n\n### Organizing your team by system\n\nOne of the more traditional ways to divide work, organizing by system separates\nteams by component and subsystem. For example, the teams that handle mobile iOS,\nmobile Android, and website have different projects, each with their own code\nrepo and [issue tracker](https://docs.gitlab.com/ee/user/project/issues/). This\ntype of structure works well with operations-driven organizations, but it’s not\na modern approach, so we recommend one of the following structures instead.\n\n### Organizing your team by product area\n\nDividing work by product is a best practice that drives business value. Using\nGitLab Groups, you can create `Code` and `Teams`. Within `Code`, separate projects\nrepresent various components (e.g. mobile iOS and user accounts), with individual\ncode repositories and sets of [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/).\nOnce you’ve created your projects (and code repos), you can build another group\nfor `Teams`, which includes fullstack product teams (i.e., engineers, PMs, designers),\nenabling parallel milestones and Agile boards. The benefit of organizing work by\nproduct area is that there’s a separation between code repos and work, so that\nevery piece of code in your organization is open to contributions from all teams.\n\n### Organizing your team with a hybrid approach\n\nThis approach combines both product and system organization structures and is\nwell suited for organizations that have cross-platform teams. For example, a mobile\nteam has dedicated iOS and Android engineers rather than full teams for both\nplatforms. In this model, the `Code` group will have individual projects according\nto component, but `Teams` is consolidated so that there’s only a website and mobile\nteam.\n\nWatch this demo and check out its\ncorresponding [example application](https://gitlab.com/trustful-finance-demo) to see groups and projects in action. 🍿\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/VR2r1TJCDew\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nDoes your team use microservices for Agile development? We’d love to hear your\nthoughts.\n\nCover image by [Martin Sanchez](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/MD6E2Sv__iA)\n{: .note}\n",[891,9,695,912],{"slug":3415,"featured":6,"template":698},"manage-agile-teams-with-microservices","content:en-us:blog:manage-agile-teams-with-microservices.yml","Manage Agile Teams With Microservices","en-us/blog/manage-agile-teams-with-microservices.yml","en-us/blog/manage-agile-teams-with-microservices",{"_path":3421,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3422,"content":3427,"config":3433,"_id":3435,"_type":13,"title":3436,"_source":15,"_file":3437,"_stem":3438,"_extension":18},"/en-us/blog/manage-conversation-staying-agile",{"title":3423,"description":3424,"ogTitle":3423,"ogDescription":3424,"noIndex":6,"ogImage":946,"ogUrl":3425,"ogSiteName":685,"ogType":686,"canonicalUrls":3425,"schema":3426},"5 Ways to stay agile in a growing organization","Some of the GitLab Manage team have a conversation about staying agile as a company grows.","https://about.gitlab.com/blog/manage-conversation-staying-agile","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 Ways to stay agile in a growing organization\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jeremy Watson\"}],\n \"datePublished\": \"2019-06-10\",\n }",{"title":3423,"description":3424,"authors":3428,"heroImage":946,"date":3430,"body":3431,"category":693,"tags":3432},[3429],"Jeremy Watson","2019-06-10","\nSome of us on GitLab's [Manage team](/handbook/engineering/development/dev/manage/) had a discussion a while back about the challenges of staying agile while a company scales. In true GitLab style, the [discussion took place asynchronously via an issue](https://gitlab.com/gitlab-org/manage/issues/13). Here it is:\n\n## How do you stay agile in a growing organization?\n\n### 1. Make quick, but thoughtful decisions\n\n[Jeremy, product manager](/company/team/#gitJeremy): This is the fundamental thing that allows startups to be competitive against dominant players in a market: It's using your resources more efficiently and moving faster than anyone else.\n\nTo me, two primary characteristics that support agility are making quick but thoughtful decisions, and focus. I think Amazon is a great example of the first, and I like [Amazon's simple Type-1/Type-2 framework](https://www.forbes.com/sites/eriklarson/2018/09/24/how-jeff-bezos-uses-faster-better-decisions-to-keep-amazon-innovating/#5feb716c7a65) for identifying the Type 2 decisions that are easily reversed, and allowing the threshold of approval to be relatively low.\n\nAs companies grow, it feels like the perceived number of Type 1 decisions grows in turn – and the organization slows down as more decision layers emerge. One thing I love about GitLab is that we're still dedicated to moving quickly and we're not constantly asking for permission to make things better. If it's easily revertible and makes something better, ship it. In all honesty, I think this is one of our biggest competitive advantages.\n\n### 2. Hire the right people\n\n[Liam, engineering manager](/company/team/#lmcandrew): The interesting thing here is that lots of organizations (big and small) now realize the value of Agile ways of working (admittedly, many of which do agile but aren't agile), making it less of a competitive advantage and more like table stakes. Therefore, I think of Agile as the sensible (only?) choice when it comes to delivering your own product to customers. An Agile mentality lets you deliver incremental, low-risk value to customers, allowing you to get feedback or pivot with minimal investment.\n\nI think the single most important thing for me here is hiring – hiring the right people who truly understand the value of agile ways of working.\n\nOne of the statements in [GitLab's Efficiency value](https://handbook.gitlab.com/handbook/values/#efficiency) points out a particular behavior that is so important here:\n\n> Accept mistakes: Not every problem should lead to a new process to prevent them. Additional processes make all actions more inefficient and a mistake only affects one.\n\nAs an organization grows its headcount, the number of business processes invariably grows with it. It's very easy to add process as a knee-jerk reaction to a problem or because it makes you feel more confident in something being executed. Having a team question the value of new processes and perhaps ask \"What do we lose by introducing this process?\" is vital to keep agility.\n\n### 3. Keep teams small and focused\n\n[Jeremy](/company/team/#gitJeremy): I don't know if I agree that as an organization grows that business processes invariably grow as well. This is what I meant earlier when I mentioned focus; without smaller teams focused on problems they own, interests start to compete and decision-making slows down because more people have a stake in the outcome.\n\nYou can mitigate this with small, focused teams. This is harder in monolithic codebases with lots of dependencies between teams.\n\nI do agree that hiring is critical to ensure everyone is questioning the status quo. The default answer to new process should be \"no,\" unless there's some acute pain it alleviates.\n\n[Luke Bennett, frontend engineer](/company/team/#__lukebennett): It is hard to avoid the reduction in velocity as a single team grows beyond some unknown threshold. A \"single team\" is a group of humans (or robots I suppose) making informed decisions about a cross-section of a product. As the team grows, it typically means the number of issues is already growing. There are more people accountable for those issues, more people making decisions on those issues, and more people contributing to those issues.\n\nIn software it also leads to team members working \"at the same workbench\" too often and of course makes the job of managing the team harder; even hosting a productive team call or keeping in touch with team members can become a challenge. This can easily lead to inefficient hierarchies to \"patch\" the problem, which can seem like a simple short cut compared to getting **more** Agile.\n\nFrom my own experience, splitting a large team into smaller ones instantly provides a feeling of relief for team members. Of course it's not just about the size of the team, it's also about their responsibilities/scope. Team members desperately want to be contributing meaningful changes on time and a reduction in scope lets them focus again on a more specific cross-section of the product, shifting attention away from the larger team discussions that may not be specific to a product area. Put simply, a discussion between [Manage](/stages-devops-lifecycle/) product category members of 10 people will be much more product-focused than a Frontend discussion of 20 people. You can expect their contributions to be the same. Additionally, the chance to build a stronger connection and appreciation for your team members is not to be ignored. There are definitely productivity gains when everyone is on the same raft!\n\n>Team members desperately want to be contributing meaningful changes on time and a reduction in scope lets them focus again on a more specific cross-section of the product, shifting attention away from the larger team discussions that may not be specific to a product area.\n\nI feel like this is a natural behaviour of humans. Agile feels natural to me at least and historically people never seem to work too well in very large groups. In the UK at least, we often reference the proverb \"Too many cooks spoil the broth.\" It's a little more complex and less brutal than that in software development, but it stands.\n\nThat said, avoiding large teams can lead to more problems. It reminds me of [Amdahl's law](https://en.wikipedia.org/wiki/Amdahl%27s_law) in that when you create more Agile teams, you create management overhead to orchestrate the direction of the teams. Agile with small teams is relatively simple because this effect is negligible, but as you scale your Agile organisation, you have to start paying attention to it.\n\n### 4. Allow teams to experiment with their own processes\n\n[Sanad Liaquat, senior test automation engineer](/company/team/#sanadliaquat): To me, keeping the size of teams small and focused on specific areas with well defined scope/boundaries is very important to stay agile in a growing organization. Also, the team should be allowed to discover their own processes and evolve. This works very well when the organization has teams laboring on separate projects with separate codebases. Each Agile team/project can then share what works best for them with other teams which can decide to adopt the practice or not. When projects have dependencies on each other, it is important that there be effective coordination on release timings between teams.\n\nWith organizations such as GitLab, where there is a single codebase, teams having their own process is not pragmatic. I believe GitLab handles Agile very well by dividing the organization into 2D slices of teams (Frontend, Backend, Security, Quality, etc.) and groups (Plan, Manage, Create, etc.) and having well-defined processes shared across groups. I believe it is necessary to keep an eye on the size of the group and think about breaking it down if it grows beyond what is considered a small and effective Agile group. (How small is \"small\" would be a separate discussion.)\n\n[Jeremy](/company/team/#gitJeremy): Yeah, I agree that small teams are pretty key. Sanad brought up dependencies, which is really important. You can have small teams, but if they can't operate independently you'll lose all your velocity.\n\nIt's interesting that you say that teams at GitLab don't have their own processes, because it feels like our teams DO have their own processes. We have some standardization like release cadence (monthly on the 22nd) and some labels (Deliverable), but we're free to do our own thing.\n\nWe operate differently than [Plan](/handbook/engineering/development/dev/plan/) and [Create:Source Code](/handbook/engineering/development/dev/create/source-code-be/), for instance. Plan uses the \"due-22nd\" label to split the work into two-week chunks, and Create:Source Code still estimates issues individually. I think it's a strength that we can individually experiment, but why isn't this more of a problem?\n\nI do think that different teams have different needs. I feel like some processes work better for other teams – maybe based on the personalities of the people or the engineering/product maturity of that particular stage.\n\nI don't know if we've really asked \"why\" or documented what's worked and what hasn't. I'm sure individual teams have experimented a lot, but I wonder if we're missing out by not tracking and sharing some of the things we've tried.\n\n[Sanad](/company/team/#sanadliaquat): I was not aware of other teams within GitLab having different processes like the ones Jeremy mentioned. I do agree that some processes can differ within teams and it is a strength that allows a team to experiment on their own and evolve as they deem fit for themselves. However, when working on the same codebase, it is better (or unavoidable) for teams to have uniformity on things like the code review process, testing strategies, documentation standards, etc.\n\n### 5. Make sure everyone is on the same page\n\n[Martin Wortschack, senior frontend engineer](/company/team/#wortschi): I also want to emphasize how important it is for an organization's leadership to understand what \"Agile\" means and that it's not just another fancy buzzword. It requires change. Depending on the organization it could mean anything including introducing new processes, hiring the right people, etc. Therefore it's very important that everyone involved has the same expectations and common understanding of \"staying Agile\" (or \"becoming Agile\") and understands the necessary steps that need to be taken towards being an Agile organization. The best talent won't be able to change much if their decisions are not backed by the executives. I've seen a lot of companies that would consider themselves an \"Agile organization\" just because they have set up a Jira project.\n\nSo, to me the most important thing is everybody's ability and willingness to change.\n\n_If you'd like to see more of these discussions around other topics, please let us know in the comments below or in [the original issue](https://gitlab.com/gitlab-org/manage/issues/13)._\n\n[Photo](https://unsplash.com/photos/HSXv_s2gH3U?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by Andrew McElroy on [Unsplash](https://unsplash.com/search/photos/sprint?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[891,9,934],{"slug":3434,"featured":6,"template":698},"manage-conversation-staying-agile","content:en-us:blog:manage-conversation-staying-agile.yml","Manage Conversation Staying Agile","en-us/blog/manage-conversation-staying-agile.yml","en-us/blog/manage-conversation-staying-agile",{"_path":3440,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3441,"content":3446,"config":3451,"_id":3453,"_type":13,"title":3454,"_source":15,"_file":3455,"_stem":3456,"_extension":18},"/en-us/blog/manager-training",{"title":3442,"description":3443,"ogTitle":3442,"ogDescription":3443,"noIndex":6,"ogImage":1174,"ogUrl":3444,"ogSiteName":685,"ogType":686,"canonicalUrls":3444,"schema":3445},"Building an All-Remote Management Enablement Program","How to build an all-remote management training & enablement program for the future of work.","https://about.gitlab.com/blog/manager-training","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Building an All-Remote Management Enablement Program\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Josh Zimmerman\"}],\n \"datePublished\": \"2021-02-19\",\n }",{"title":3442,"description":3443,"authors":3447,"heroImage":1174,"date":3448,"body":3449,"category":716,"tags":3450},[1179],"2021-02-19","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nOne of GitLab Learning & Development’s (L&D) biggest charters for FY21 was building out a management training program. It was a huge task! The CEO asked the L&D team to build a program that trained managers on remote leadership, managing teams, and management best practices. GitLab has been around since 2011. With our massive growth over the years, there was a huge need to train and develop managers for the future. Building a program from scratch was going to require a proactive approach to ensure all voices were heard and to build a program that equipped our leaders with the right skills. \n\nSo, how do you build a management training program for an all-remote company? What do you include? How do you design and develop an impactful program? \n\nIn this blog, I’ll cover some tips and tricks to what we did in L&D to build the [Manager Challenge](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/) program. \n\n### Start With a Learning Needs Analysis\n\nWhen I first started at GitLab, I learned that there had never been a formal management training program. L&D was a relatively new function within the organization. With the massive growth, L&D saw an opportunity to train our managers for the skillset they needed to be successful. Our first task for developing a program was to conduct a learning needs analysis. We took a consulting approach to the analysis by interviewing a wide range of stakeholders at the company with varying experience levels. From C-suite executives to new managers, to established Directors, we had to diversify who we would receive input from. \n\nWe divided between us, at the time a team of two, by collecting feedback on the management needs and skill gaps. We conducted a job task analysis by determining what managers do at GitLab and what knowledge and skills they would need. During the interviews, we identified consistent themes across stakeholder groups. Some of the themes mentioned “foundational management” as a critical area to focus skill building. Many of our people leaders had been recently promoted and never managed a team before. The skills needed to manage people are different when you have direct reports versus being an individual contributor. \n\nFrom the learning needs analysis, we could pull out additional themes and recommendations for the training. Managing an all-remote team requires a different set of skills than a colocated office environment. For one, people leaders need to ensure their people are set up to be “[Managers of One](https://about.gitlab.com/handbook/leadership/#managers-of-one).” You have to empower your people to work autonomously and get the job done to achieve results. We synthesized the themes which led us into the storyboarding and training design phase. \n\n### Design a Training Experience That Fits Your Culture\n\nEveryone is super busy at GitLab. Like any high-growth, pre-IPO organization, the company moves at lightning speed. We knew that managers would have limited time to dedicate to training. L&D didn’t want to make managers take huge chunks out of their day to dedicate to training. And there is nothing worse than being on a three to five-hour-long virtual training event! \n\nThe training was divided into two parts: \n1. Daily asynchronous learning activities \n2. Weekly live learning sessions\n\nWe knew that the training needed to be bite-sized over a period of time to reinforce management behaviors and skill-building. When we started designing the program, we looked at 30-day challenges as a framework to support behavior change. Participants would be required to do a short daily challenge that would take twenty minutes to complete on their own time. GitLab is a global company. Our team members live in over 65+ countries around the globe. Coordinating calendars with managers was going to be difficult for dedicated virtual live training time. Instead, we built the curriculum by dividing up themes and topics into weeks and days. We created bite-sized learning and actions for participants to complete on their own time. \n\nAt GitLab, we don’t just read off of slides during a presentation. We ask that participants review slides ahead of the call and use the time together to ask questions while facilitating a discussion. We designed the live learning sessions with these best practices in mind. The live learning sessions would focus on the themes covered during the daily asynchronous activities. Also, we prompted managers to openly discuss specific management topics (i.e., giving/receiving feedback, performance discussions, wellbeing check-ins, etc.) that are important to GitLab. \n\nThe program design started to take shape. We designed a three-week program with asynchronous learning activities to be completed Monday-Wednesday. Thursday’s were dedicated to live-learning events to network and learn from other managers. Friday’s served as catch up days, weekly course evaluations, and self-reflections.\n\n### Use What You Have Available \n\nThe best way to understand how GitLab works is to use it for as much of your job as possible. We [dogfood](https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything) our product by threading it into everything we do in the organization. Managers need to be well-equipped with using GitLab to manage their all-remote team. We designed the training to incorporate GitLab into the curriculum as much as possible. The daily asynchronous learning activities are posted in a [GitLab Issue](https://docs.gitlab.com/ee/user/project/issues/). Everyone in the program, anyone with a GitLab.com account, has access to the learning content. The asynchronous topic was posted daily. Participants could read through the Issue and complete the action item by posting their responses in the comments section. \n\nThe practice enabled our [transparency value](https://handbook.gitlab.com/handbook/values/#transparency) by allowing all participants (anyone really) to review manager’s responses. The benefit of using GitLab reinforced multiple behaviors. One, everyone was dogfooding our product. Two, participants could learn from others by reading how other managers respond to different situations. Three, participants now have a reference point to go back to as they grow in their careers. \n\nDoes your organization have a tool like GitLab to help facilitate L&D initiatives? If so, consider using it to reinforce behaviors and to allow managers to become comfortable using them. If not, consider having your team members sign up for a free [GitLab account](https://gitlab.com/) and [implement a challenge](https://about.gitlab.com/handbook/people-group/learning-and-development/manager-challenge/#learning-and-development-team) using GitLab. \n\n### Apply Social Learning \n\nRemote work can have some drawbacks. One of those challenges may be a lack of connection with your coworkers. Managers need to form relationships with their team members over virtual calls. And people leaders may not have a lot of opportunities to learn from others in a social setting. When you work for a globally distributed team, there can be isolation if the rest of your team is in different time zones. \n\nWe designed the live learning session as a forum for social learning. Managers were given prompts and scenarios on certain situations they would face in their role. Breakout activities were implemented to strengthen networks and collaboration. Participants would share tips on how they would handle the scenarios. We focused less on slides and presenting material and more on engaging with one another to learn from others. Managers shared lessons learned, and many participants walked away from the live learning sessions with new skills to apply right away on the job. \n\n### Review and Validate the Program with Executives\n\nWe are lucky that our leadership team is passionate about the growth and development of our team members. GitLab’s CEO, Sid, asked us to spearhead management training, and he partnered with us on reviewing the content to ensure it aligned with his vision. High Output Management is a book written by Andrew Grove, former CEO of Intel. It is one of our CEO’s favorite books!\n\nWhen we met with Sid for the first time to review the curriculum, he wanted us to ensure that important principles covered in the book were included. We threaded multiple topics (i.e., 1-1 meetings, performance management, making decisions, etc.) into the program. \n\nAlso, our executive review meetings validated whether or not the program reinforced our values. [Gitlab Values](https://handbook.gitlab.com/handbook/values/) are central to how the organization operates. I’ve never worked for a company where they are emphasized so much! Executives had a keen eye on ensuring that the program equipped managers with being role models of our values. The review and validation from executives were vital as we launched GitLab’s management training program. \n\n### Don’t be afraid to Iterate\n\nIt’s easy for L&D professionals to get caught up in requirement gathering and rapidly develop learning programs. However, it’s important to remember that your solution’s best feedback will occur once you pilot the program. We’ve launched two iterations of the Manager Challenge program, and the two looked completely different. The first program was longer, four weeks, and didn’t do enough to reinforce GitLab Values. We also held several meetings with leadership to thread more GitLab “ways of working” content into the curriculum. We ended up cutting out one of the weeks of training to make it three weeks and used the book High Output Management as the foundation to the enablement. \n\nFor the first iteration, we created a large project plan. We didn’t start with the [smallest thing possible and get it out as quickly as possible](https://about.gitlab.com/blog/behind-the-scenes-how-we-built-review-apps/). The plan allowed us to develop a comprehensive curriculum, but it was without testing. The upfront work took a great deal of time. Looking back, we should have developed a shorter program, iterated, and moved forward with the next version. To be successful, we had to get something out right away, pilot, receive feedback, and update. \n\nDuring the training, we conducted weekly evaluations of the content. With the feedback, we were able to apply constructive points and incorporate them into the next week. For example, participants wanted to network more. So we adapted the curriculum and added more social learning in the remaining weeks. \n\nIteration was central to how we rolled out a more seamless program that incorporated GitLab Values and ways-of-working. Don’t be afraid to iterate if you are building a management training program. The best feedback will come once you get it out the door. \n\n### The Result\n\n\nAfter months of planning, content development, stakeholder reviews, we developed the Manager Challenge program for GitLab people leaders. The program is a blended learning approach that incorporates self-paced daily challenges and live learning sessions to build foundational management skills. The program includes leadership assessments, interactive learning, networking, and digital learning, all in three weeks. The program builds a set of baseline management skills that complement our values. \n\nHere’s what a few participants had to say about the program: \n1. \"The handbook has so much content, it's easy to forget how much tactical information can be found right at your fingertips.\"\n2. \"Team performance is cyclical. Perceived regressions aren't bad, but rather a reflection of a change in team dynamics. Look for the types of questions people are asking to know how to respond.\"\n3. \"The handbook is a great resource with tons of information on being a manager, having hard conversations, and helping teams grow.\"\n4. \"For me, these are good reminders of what are the best practices to adopt as a Manager. I am always exploring what are ways we can do tasks better and faster. With that said, as a manager, we need to be sure my people and others are part of the process.\"\n5. \"I learned that there are so many amazing managers here at GitLab. Each of the days' comments were treasure troves into how to approach something differently or new techniques that others have found success with.\"\n6. \"It's possible to be a great remote manager!\"\n\nIf you are set out to create a management training program for your organization to develop leaders, use some of the points in this blog as a reference point. Feel free to reach out to GitLab Learning & Development at `learning@gitlab.com`. \n\n### Looking for more Learning and Development material from GitLab?\n\nIf you want to learn more about what the Learning and Development team at GitLab is up to, check out our [handbook page](/handbook/people-group/learning-and-development/) or read our past newsletters.\n",[1097,934,9],{"slug":3452,"featured":6,"template":698},"manager-training","content:en-us:blog:manager-training.yml","Manager Training","en-us/blog/manager-training.yml","en-us/blog/manager-training",{"_path":3458,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3459,"content":3465,"config":3471,"_id":3473,"_type":13,"title":3474,"_source":15,"_file":3475,"_stem":3476,"_extension":18},"/en-us/blog/managing-global-projects-requiring-rapid-response-continuously",{"title":3460,"description":3461,"ogTitle":3460,"ogDescription":3461,"noIndex":6,"ogImage":3462,"ogUrl":3463,"ogSiteName":685,"ogType":686,"canonicalUrls":3463,"schema":3464},"How to leverage distributed engineering teams for rapid response","Rapid response issues can be handled in a compressed time frame if distributed engineering teams can work continuously. Here's what we've learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681331/Blog/Hero%20Images/all-remote-world-banner-1920x1080.png","https://about.gitlab.com/blog/managing-global-projects-requiring-rapid-response-continuously","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to leverage distributed engineering teams for rapid response\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Chris Baus\"}],\n \"datePublished\": \"2021-06-04\",\n }",{"title":3460,"description":3461,"authors":3466,"heroImage":3462,"date":3468,"body":3469,"category":1053,"tags":3470},[3467],"Chris Baus","2021-06-04","\n\nI am an [Engineering Manager](https://gitlab.com/chris_baus) working on a distributed engineering team at GitLab. [Our team](/handbook/engineering/development/fulfillment/purchase/) is distributed globally, and we have engineers working in India, Germany, Australia, New Zealand, and the United States. I am [located](https://www.google.com/maps/place/Stateline,+NV/) in the U.S. in Pacific Standard Time (PST). In coordination with [other](/handbook/engineering/development/ops/verify/#verifycontinuous-integration) globally distributed engineering teams, we recently responded to an [abuse issue](/blog/prevent-crypto-mining-abuse/) which was causing disruptions for legitimate GitLab.com users, and required a [rapid response](/handbook/engineering/workflow/#rapid-engineering-response).\n\n## Global distribution as an advantage\n\nMany managers view global team distribution as a constraint (because synchronous communication becomes more difficult), but it is possible to [embrace the constraint](https://basecamp.com/gettingreal/03.4-embrace-constraints) and turn it into an advantage. When teams are globally distributed it is possible for work to continue around-the-clock, uninterrupted, and decrease the overall delivery time of projects. I refer to this as \"continuous development.\"\n\nWhile we don't typically work this way, when problems are pressing, working continuously can be a strategy to advance the delivery time frame. In this case, two engineers from our team worked on the problem [17](https://www.google.com/maps/place/Bellingham,+WA/) [hours](https://www.google.com/maps/place/Melbourne+VIC,+Australia/) apart. This provided some overlap in the afternoon (PST), but for the most part, the engineers were working on the project at different times which allowed work to progress continuously.\n\nIt requires some extra management compared to the typical workflow, but the effort may be worth the investment if time is critical.\n\n## Define clear handoffs\n\nOne risk of multiple engineers working continuously and [asynchronously](https://baus.net/embrace-asynchronous-work/) is duplicating work from lack of clear separation of work or handoffs. If possible, it is best to separate work, so engineers are working in different areas of code, but separating work might not always be feasible or practical. In either case, when an engineer finishes working for the day, they should provide an update describing the work which was completed, any problems impeding progress, and what is left to be done.\n\nIf engineers are working in the same area of code, it should be clearly defined if they are working in the same branch or separate branches. If they are working in the same branch, it might make sense for one engineer to maintain branch and accept merges from other engineers before it merged into the main development branch.\n\n## Agree on interfaces\n\nWhen distributed engineering teams are working on a project, it is critical to define clear and documented interfaces between systems and components. System interfaces should be documented in a centrally maintained location. If there is a need to change the interface, then everyone affected by the change should be notified.\n\nIn retrospect, we lost nearly a day of testing because of confusion about an interface between the frontend and backend of the system. These types of problems tend to be amplified when not all engineers involved in the project are available at the same time, as it may take an entire 24-hour cycle to handle and communicate changes. When a discrepancy is found, the problem should be documented by the engineers currently working and, if possible, a solution proposed.\n\n## Place synchronous communication on management\n\nWhen working concurrently, to help ensure all teams are on the same path, it can be helpful to discuss the project status synchronously. This can be difficult to arrange with distributed engineering teams. On this project, the technical teams met twice weekly for 15-30 minutes. It can be tempting to require team members to work off hours to attend synchronous meetings. I'd recommend fighting this tendency.\n\nIt's the responsibility of a manager to ensure effective communication across teams. During rapid-response actions, it's helpful to keep flexible working hours to synchronize with team members across different time zones. I accept working outside my typical hours (knowing I can [adjust my hours](/company/culture/all-remote/non-linear-workday/) at other times of the day), to communicate the status of my team synchronously. This also requires the manager to have a more detailed technical understanding of the implementation and status than is normally required, so they can speak on behalf of offline team members.\n\nInstead of requiring synchronous meeting attendance, [take good notes](/company/culture/all-remote/meetings/#document-everything-live-yes-everything) and [record the meeting](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) so team members in other time zones can review the status and decisions from synchronous meetings.\n\n## Trade-offs\n\nIn many ways, engineering is the art of balancing trade-offs. Operating in a continuous, globally-distributed fashion takes more management and cognitive overhead than typical asynchronous workflows, but when time is a priority, it could decrease the release time on critical projects.\n\nOperating continuously may come at cost of other management tasks as compressing time increases the effort required to oversee the project requiring a [rapid response](/handbook/engineering/workflow/#rapid-engineering-response). At the end of the rapid-response issue, a retrospective should be held to determine if the engineering strategy provided the expected results, relative to the increased overhead. My recommendation is to be realistic about costs when planning continuous development even when it provides short-term results.\n\n_Read more on [leading engineering teams](/blog/cadence-is-everything-10x-engineering-organizations-for-10x-engineers/)._\n",[1097,934,891,9],{"slug":3472,"featured":6,"template":698},"managing-global-projects-requiring-rapid-response-continuously","content:en-us:blog:managing-global-projects-requiring-rapid-response-continuously.yml","Managing Global Projects Requiring Rapid Response Continuously","en-us/blog/managing-global-projects-requiring-rapid-response-continuously.yml","en-us/blog/managing-global-projects-requiring-rapid-response-continuously",{"_path":3478,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3479,"content":3485,"config":3492,"_id":3494,"_type":13,"title":3495,"_source":15,"_file":3496,"_stem":3497,"_extension":18},"/en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt",{"title":3480,"description":3481,"ogTitle":3480,"ogDescription":3481,"noIndex":6,"ogImage":3482,"ogUrl":3483,"ogSiteName":685,"ogType":686,"canonicalUrls":3483,"schema":3484},"How to manage your Snowflake spend with Periscope and dbt","The GitLab data team is open sourcing the dbt package they use to manage their Snowflake spend.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670255/Blog/Hero%20Images/data-servers.jpg","https://about.gitlab.com/blog/managing-your-snowflake-spend-with-periscope-and-dbt","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to manage your Snowflake spend with Periscope and dbt\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor Murphy\"},{\"@type\":\"Person\",\"name\":\"Emilie Schario\"}],\n \"datePublished\": \"2019-08-26\",\n }",{"title":3480,"description":3481,"authors":3486,"heroImage":3482,"date":3489,"body":3490,"category":784,"tags":3491},[3487,3488],"Taylor Murphy","Emilie Schario","2019-08-26","On the data team at GitLab, we are grateful to be empowered with best\nin-class tools that enable us to produce high-quality work. At the 2018\nDataEngConf (now Data Council), GitLab data engineer [Thomas La\nPiana](/company/team/#tlapiana) spoke about how a team of three was\nsupporting the data needs of a billion-dollar company. As he explains in\nthis talk, we focus a lot on processes and workflows.\n\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/eu623QBwakc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\n## Where are the existing gaps?\n\nToday, the data team has grown from three to seven: three engineers and four\nanalysts.\n\nSince we've more than doubled in the last six months, we've had to take a\nstep back and revisit our processes.\n\n\n![GitLab Team\nHeadcount](https://about.gitlab.com/images/blogimages/team_headcount.png){:\n.shadow.medium.center}\n\nThe GitLab team has grown significantly in the past few months.\n\n{: .note.text-center}\n\n\n### GitLab is growing fast\n\n\nDespite the significant jump in the data team's headcount, our growth has\nnot matched the exponential growth of the team supporting GitLab.\n\nAs GitLab grows, more folks aim to include more data in their\ndecision-making process.\n\nThis means we're iterating quickly, collecting feedback, and constantly\nimproving on the quality of the analyses we are producing for our business\nstakeholders.\n\nThe demand for more data means there is a lot more to accomplish – making\nnow an opportune time to review our processes and improve the data team's\nimpact across GitLab.\n\n\nFor example, a data team member pointed out that refinement isn't a part of\nour [milestone planning\nprocess](/handbook/business-technology/data-team/how-we-work/#milestone-planning).\n\nNo wonder our backlog wasn't moving anywhere! We identified the root of the\nproblem by asking our team, \"What is the problem we're trying to solve?\" and\nthen laid out a plan to address it.\n\n\n### Onboarding can be hard\n\n\nWe've made some great data analyst hires recently!\n\nWe don't require our new team members to be familiar with our existing data\nstack (Stitch/Singer - Snowflake - dbt - Periscope), but we do require them\nto have technical skills that match their role.\n\nThis usually includes Git, SQL, and Python (Pandas) at the bare minimum,\nthough we welcome R (tidyverse) as well.\n\nWhile onboarding at any company can be difficult, it's especially\nchallenging in an all-remote organization such as GitLab.\n\n\nIn addition to introducing candidates to our specific technologies, part of\nthe [data analyst\nonboarding](https://gitlab.com/gitlab-data/analytics/blob/master/.gitlab/issue_templates/data_onboarding.md)\nincludes a unit on resource consumption.\n\nWe spend time introducing the concepts of databases and warehouses in\nSnowflake, because storage and compute being separate are often novel ideas\nto folks joining GitLab from an on-premise data organization.\n\nIn some cases, we are teaching our new hires a new way to think about the\ndata-related problems they're solving, and introducing different resources\nto remedy these problems.\n\n\n### With great power comes great responsibility\n\n\nWe consume more resources as the data team headcount grows. I think about\nthis like folks using water in a household. If everyone is on vacation, the\nwater bill will be low, but if all the cousins come visit for a week, the\nbill will be high.\n\nSimilarly to why we encourage a big group of visiting relatives to take\nshorter showers to conserve water, on the data team we work to steward\nresources effectively. This means we must identify wasted resources to\nrecapture them.\n\nIt's important that our operating expenses not balloon with headcount.\n\n\n## Are you protected against a leak?\n\n\nAs a homeowner, I can share a myriad of appliance-gone-wrong stories, but\none tops them all: the time there was a leak in our front yard that we only\ndiscovered because of a $1,000 water bill.\n\nOften, homeowners can only measure water usage when the bill arrives, when\nit's always too late to fix it.\n\n\nLucky for our team and yours, Snowflake is much more generous than my water\ncompany.\n\nWe *can* monitor our costs as it accrues.\n\nAfter having this process in place for a bit now, we'd encourage you to\nimplement it in your stack.\n\n\n## Monitor your Snowflake spend with dbt and Periscope\n\n\nWe're excited to make our [Snowflake spend dbt\npackage](https://gitlab.com/gitlab-data/snowflake_spend) widely available\nfor use.\n\nDoing this is in line with our belief in the value of [open source\nanalytics](/blog/open-source-analytics/).\n\n\nTo get started, you'll need to grant access to the `snowflake` database to\nyour dbt-specific role with:\n\n```\n\nGRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE \u003Crole>;\n\n```\n\n\nThen you'll need to update the `packages.yml` file in your dbt project to\ninclude the following:\n\n```\n\npackages:\n - git: https://gitlab.com/gitlab-data/snowflake_spend.git\n revision: v1.0.0\n```\n\n\nToday, you can only install the package directly from Git.\n\nSince it doesn't depend on any other packages, you don't have to worry about\nversion management, so this should not cause any problems.\n\nYou can run `dbt deps` to ensure the package is installed correctly.\n\n\nYou will need a csv called `snowflake_contract_rates.csv` which has two\ncolumns: effective date and rate. The effective date is the day the new\ncontracted rate started and it should be in YYYY-MM-DD format. The rate is\nthe per credit price for the given time period. You can see how the data\nteam configures [their csv\nfile](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/data/snowflake_contract_rates.csv).\nYou will need to run `dbt seed` for the csv to be loaded as a table and for\nthe model to run succesfully.\n\n\nFinally, you will need to update your `dbt_project.yml` file to enable this\npackage with the following block.\n\n```\n\nmodels:\n snowflake_spend:\n enabled: true\n```\n\nYou can see [how the data team has configured the\npackage](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/dbt_project.yml#L68)\nin our `dbt_project.yml` file.\n\n\nRunning `dbt compile` will not only test that you've configured all of this\ncorrectly, but also will compile the files in the `analysis` directory.\nThese are the queries that we use to underlie the exact Periscope dashboard\nthat we have automatically posted in Slack every day.\n\n\n![GitLab's Periscope dashboard for managing Snowflake\nspend](https://about.gitlab.com/images/blogimages/periscope_snowflake_spend1.png){:\n.shadow.medium.center}\n\n![GitLab's Periscope dashboard for managing Snowflake\nspend](https://about.gitlab.com/images/blogimages/periscope_snowflake_spend2.png){:\n.shadow.medium.center}\n\n\nOnce you've set up this dashboard, you can configure it to auto-refresh\ndaily.\n\nThen use Slack's `/remind app.periscopedata.com/dashboardurl` to have it\nregularly publish in the channel of your choice.\n\n\nYou can see how our resource management initiatives have been effective.\n\nWe hope you'll find monitoring a key step to helping manage your own\nSnowflake spend.\n\n\nHave any thoughts, questions, or suggestions? [Create an\nissue](https://gitlab.com/gitlab-data/snowflake_spend/issues).\n\n\nPhoto by [Taylor Vick](https://unsplash.com/photos/M5tzZtFCOfs) on\n[Unsplash](https://unsplash.com/)\n\n{: .note}\n",[9,268,787,2480],{"slug":3493,"featured":6,"template":698},"managing-your-snowflake-spend-with-periscope-and-dbt","content:en-us:blog:managing-your-snowflake-spend-with-periscope-and-dbt.yml","Managing Your Snowflake Spend With Periscope And Dbt","en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt.yml","en-us/blog/managing-your-snowflake-spend-with-periscope-and-dbt",{"_path":3499,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3500,"content":3505,"config":3510,"_id":3512,"_type":13,"title":3513,"_source":15,"_file":3514,"_stem":3515,"_extension":18},"/en-us/blog/marcel-amirault-contributor-post",{"title":3501,"description":3502,"ogTitle":3501,"ogDescription":3502,"noIndex":6,"ogImage":1276,"ogUrl":3503,"ogSiteName":685,"ogType":686,"canonicalUrls":3503,"schema":3504},"GitLab Code Contributor: Marcel Amirault","Recent MVP Marcel Amirault shares why he started contributing to GitLab.","https://about.gitlab.com/blog/marcel-amirault-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Marcel Amirault\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-04-12\",\n }",{"title":3501,"description":3502,"authors":3506,"heroImage":1276,"date":3507,"body":3508,"category":784,"tags":3509},[1281],"2019-04-12","\n\nI'm excited to continue the [series of GitLab contributor blog posts](/blog/tags.html#contributors)\nwith [Marcel Amirault](https://gitlab.com/Ravlen), [the MVP for the 11.9 release](/community/mvp/).\nLet's get to know more about him!\n\n### Can you tell us where you live and share anything interesting about your area?\n\nI'm originally from Halifax, in eastern Canada, but I now live in [Kagoshima, Japan](https://www.google.com/maps/place/Kagoshima,+Japan/@31.523208,130.2782569,10z/data=!3m1!4b1!4m5!3m4!1s0x353e615200e3c53d:0x9adcfdad5d5c5885!8m2!3d31.5968539!4d130.5571392) (and yes, I have seen wild tanuki!).\nKagoshima is famous for being right next to one of the world's most active volcanos, Sakurajima,\nwhich regularly dusts the city in ash. You have to keep an eye on the wind before you decide\nto put out your laundry, or else you'll have some ashy-grey clothes pretty quickly.\nIt's also known for inspiring some famous movies. Hometown hero Saigō Takamori and the\nlocal Satsuma clan were the inspirations for \"The Last Samurai,\" and Yakushima Island was\nthe inspiration for the forest in \"Princess Mononoke.\"\n\n![Picture of Sakurajima](https://about.gitlab.com/images/blogimages/Marcel-blogpost/kagoshima.png){: .shadow.small.center}\n*\u003Ccenter>\u003Csmall>Sakurajima in the distance\u003C/small>\u003C/center>*\n\n### Can you tell us what you do professionally?\n\nOriginally, I worked in IT Support, peaking as a Network Technician at a telecom company\nin eastern Canada. I loved the job, but I wanted to live abroad for a while before settling into my career.\nI decided to teach English in Japan \"for six months,\" but fell in love with the country and have\nbeen here ever since. I currently teach English as a second language to Japanese students, and\nhave taught all ages and types of students over the years. I write, proofread, and teach curricula\nfor various types of students, ranging from people preparing for their first trip abroad, to seminars\nin hospitals for medical professionals. From time to time I proofread documents brought to me,\nsuch as applications to international programs, or scientific papers being prepared for submission for peer review.\n\n![Marcel in the classroom](https://about.gitlab.com/images/blogimages/Marcel-blogpost/marcel-teaching.jpg){: .shadow.small.center}\n\n### When did you first contribute to GitLab and why did you decide to contribute?\n\nAbout a year ago, I started a Rails course to try to get back into the IT world, and needed to\nchoose a place to store my Git repo. A friend suggested GitLab, and I dove right in.\nWhile reading the documentation, I sometimes found small mistakes that the English teacher\nin me couldn't ignore, so I started submitting MRs for small things like typos or obvious grammar mistakes.\nIn fact, [my first MR](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/11848) was to correct grammar.\nFrom there, the MRs got a little bigger, and a little more involved, and it's something I enjoy doing when things are slow at work.\n\n### What was the most difficult part of contributing for you in the beginning?\n\nThere was no significant hurdle to starting, because contributing to documentation was not\nintimidating at all, and I never had to worry about complicated reviews.\nWhen I first submitted a small change to the language in a section of the UI though, I suddenly\nhad a lot of reviews and suggestions, and started to realize how a small change could have a large impact.\nUnderstanding the impact that one person could have on a major project was something I had to learn.\nThankfully, a lot of GitLab team-members offered help and explained things for me, which I really appreciated.\n\n### Which areas of GitLab have you contributed to most and how do you find issues that you want to work on?\n\nUpdating technical documentation was a natural fit for me. I enjoy learning, so I frequently\nread the GitLab documentation, but my \"English teacher eyes\" can't ignore language that can be improved.\nI take advantage of free time at work, and I'm fortunate to have free access to computers and\na flexible boss (as long as my lesson quality is maintained). As a result, I'm often able to fill\nthe gaps between lessons by working on documentation issues. When I'm struggling to stay\nawake because my kids kept me up at night and I have a gap in my schedule, working on an\ninteresting bit of documentation wakes me up as much as a strong cup of coffee!\nI usually find documentation that can be improved on my own as I read through, but I\nsometimes search for [`Accepting Merge Requests` issues for Documentation](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20merge%20requests&label_name[]=Documentation) if I need a new project to work on. Recently I have given myself \"challenges,\"\nlike \"Find ALL examples of a certain grammar mistake project wide, and fix them\" or\n\"Find ALL examples where CE and EE documentation have diverged accidentally, and realign them when possible.\"\n\n### What do you enjoy doing when you're not working?\n\nI like doing home improvements when I can, and really like outdoor carpentry like putting up\nfences or wooden decks. I'm a big fan of hiking and camping, but it has been hard to get out\nto camping places in the past few years as my kids are still young. We are hoping to bring them\non their second ever camping trip this spring/summer. Finally, my friends and I try to get together\nabout once every month or two for poker or board gaming. Some of my favorite games are\nSettlers of Catan, Carcassonne, Puerto Rico, Pandemic, San Juan, and Guillotine.\n\n![Marcel and his children](https://about.gitlab.com/images/blogimages/Marcel-blogpost/marcel-family.png){: .shadow.small.center}\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nDon't be shy! If you are worried about your contribution, feel free to make your MR a [draft](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html)\n(document last updated by me! 😉), and ask for help. Everyone is super friendly and always willing to give advice!\n\n### Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn\nhow you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":3511,"featured":6,"template":698},"marcel-amirault-contributor-post","content:en-us:blog:marcel-amirault-contributor-post.yml","Marcel Amirault Contributor Post","en-us/blog/marcel-amirault-contributor-post.yml","en-us/blog/marcel-amirault-contributor-post",{"_path":3517,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3518,"content":3524,"config":3530,"_id":3532,"_type":13,"title":3533,"_source":15,"_file":3534,"_stem":3535,"_extension":18},"/en-us/blog/marker-io-gitlab-integration",{"title":3519,"description":3520,"ogTitle":3519,"ogDescription":3520,"noIndex":6,"ogImage":3521,"ogUrl":3522,"ogSiteName":685,"ogType":686,"canonicalUrls":3522,"schema":3523},"How to radically simplify bug reporting in GitLab","Marie Hargitt from Marker.io shares how product teams can empower colleagues to report actionable issues in GitLab, without driving developers crazy.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679899/Blog/Hero%20Images/gitlab-marker-io.png","https://about.gitlab.com/blog/marker-io-gitlab-integration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to radically simplify bug reporting in GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Marie Hargitt\"}],\n \"datePublished\": \"2019-01-09\",\n }",{"title":3519,"description":3520,"authors":3525,"heroImage":3521,"date":3527,"body":3528,"category":1053,"tags":3529},[3526],"Marie Hargitt","2019-01-09","\n\nIf you’re like us, you’re constantly pushing out new features and improvements to your product, but with those updates and changes comes the inevitable risk of bugs. The best way to find and fix those bugs are your internal reporters and developers, but getting the whole team to report bugs into GitLab can be hard.\n\nWhether it’s your copywriters on the lookout for wonky content, your QA testers that find a broken form, designers that spot a font size five times too big, or your customer support team receiving word that a billing issue is blocking customers from paying – reporters can take forever to send actionable feedback to developers, who in turn don’t always get the information they need to smash those bugs.\n\n## What a bug-reporting workflow usually looks like ...\n\n### ... for reporters\n\nBecause reporters aren’t always super tech-savvy, it can be tricky for them to share reports that are helpful for your developers. The process is long, complicated, and tracking down the crucial technical information isn’t always easy.\n\nIn most teams, reporting bugs into GitLab looks like this:\n1. Find the bug.\n1. Open screenshot tool, capture bug.\n1. Open software to annotate screenshot, add comments.\n1. Open and log into GitLab.\n1. Select the correct project.\n1. Create new issue.\n1. Document the bug. (How exactly do I do this!?)\n1. Add technical information. (What is this even?)\n1. Attach screenshots.\n1. And then finally: submit report.\n\nThat’s a whopping 10 steps to report even the smallest bugs.\n\nAnd we didn’t even mention the super-fun scavenger hunt reporters have to go on to identify all of the environmental data developers need to even start thinking about fixing the bugs.\n\n### ... for developers\n\nDevelopers get feedback flying at them in all forms – emails, phone calls, sticky notes and screenshots.\n\nThey’re ready to gouge their eyes out because they can’t reproduce the reported bugs, because they’re not receiving actionable feedback from the get-go, and they don’t have time to investigate all the bug reports they receive.\n\n## So what can you do to make sure everyone can contribute?\n\n### Speed up workflow for reporters\n\nWe created Marker.io to speed up and simplify your team bug reporting. Now, those 10 steps are only three:\n\n1. Capture and annotate screenshot of bug.\n1. Send bug reports straight to your GitLab project.\n1. Keep hunting for more bugs!\n\nOne real-life example is an issue we ran into with our pricing page a while back. During our QA process, we noticed a weird bug: the price for our Team Plan was mysteriously missing. Instead of using the lengthy process mentioned earlier in this post, we used Marker.io to quickly send feedback to our dev team and get the bug fixed in no time.\n\nThis is what reporting the issue with Marker.io looked like:\n\n![Creating the bug report issue in GitLab](https://about.gitlab.com/images/blogimages/GitLab-creating-issue-Marker-io.gif){: .shadow.center.medium}\n\nNow, not only is the process much faster, but you never have to leave your website, there is nothing to configure, and all the technical data the developers need is automatically captured by Marker.io.\n\n### Create actionable reports for your developers\n\nOnce a visual feedback tool like Marker.io is introduced into the equation your developers can choose where they receive feedback, down to the specific bug-tracking GitLab project, and the important technical data they need is automatically grabbed and included in every bug report.\n\nThat means environment data, including:\n- Browser\n- Operating system (OS) and version\n- Screen size\n- Zoom level\n- Pixel ratio\n\nHere’s an example of what a Marker.io bug report looks like in GitLab:\n\n![The bug report issue inside GitLab](https://about.gitlab.com/images/blogimages/GitLab-issue-created-with-Marker-io.gif){: .shadow.center.medium}\n\nThis GitLab issue has all the information needed for your developers to act on it:\n\n- The issue is in the correct project.\n- Any pre-set epics, milestones or labels are included.\n- The issue is assigned to a team member.\n- The annotated screenshot is attached.\n- The expected and actual results are well documented.\n- The steps to reproduce are detailed.\n- The technical environment information is all there.\n- The issue has the URL where the screenshot was captured.\n- The issue has a due date.\n\nNo more wasted time following up with reporters to fill in the gaps. It’s all there, organized directly in your chosen GitLab project – complete with everything vital to fix your bugs.\n\nWant to try for yourself? Marker.io comes with a free 15-day trial. Give it go ➡️ [Marker.io/gitlab](https://marker.io/gitlab?utm_source=gitlab&utm_medium=post&utm_campaign=gitlab_bug_reporting)\n\n### About the guest author\n\nMarie Hargitt is the Marketing Manager of [Marker.io](https://marker.io/gitlab), a powerful tool that makes bug reporting and visual feedback easy for the whole team.\n",[9,232,912],{"slug":3531,"featured":6,"template":698},"marker-io-gitlab-integration","content:en-us:blog:marker-io-gitlab-integration.yml","Marker Io Gitlab Integration","en-us/blog/marker-io-gitlab-integration.yml","en-us/blog/marker-io-gitlab-integration",{"_path":3537,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3538,"content":3543,"config":3549,"_id":3551,"_type":13,"title":3552,"_source":15,"_file":3553,"_stem":3554,"_extension":18},"/en-us/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners",{"title":3539,"description":3540,"ogTitle":3539,"ogDescription":3540,"noIndex":6,"ogImage":2451,"ogUrl":3541,"ogSiteName":685,"ogType":686,"canonicalUrls":3541,"schema":3542},"Meet the 2023 GitLab Partner of the Year award winners","We recognized our channel, technology, and cloud partners for their collaboration and contributions.","https://about.gitlab.com/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Meet the 2023 GitLab Partner of the Year award winners\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nima Badiey\"}],\n \"datePublished\": \"2023-07-20\",\n }",{"title":3539,"description":3540,"authors":3544,"heroImage":2451,"date":3546,"body":3547,"category":1203,"tags":3548},[3545],"Nima Badiey","2023-07-20","\nAt GitLab’s second annual Partner Leadership Summit in June, we invited channel, technology, and cloud partners to join us to celebrate their achievements, empower their success, and provide resources and support for the year to come. \n\nWe recognized our partners for their contributions via the Partner Leadership Awards, including Partner of the Year, Public Sector Partner of the Year, Public Sector Distributor of the Year, and Public Sector Services Partner of the Year. \n\nWe also introduced a new award category: Emerging Partner of the Year. The Emerging Partner of the Year award recognizes a new partner who consistently demonstrates a commitment to building a solution practice based on GitLab’s leading DevSecOps platform.\n\nGitLab strives to create collaborative and mutually beneficial relationships with our partners, and we also encourage our partners to embrace GitLab’s values of Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency ([CREDIT](https://handbook.gitlab.com/handbook/values/)). Each award winner demonstrated a strong partnership with GitLab and alignment with CREDIT values.\n\nOur 2023 Partner Leadership Summit Award winners are:\n\n### Partner of the Year: SHI Stratascale, a SHI Company\n_Stratascale, a subsidiary of SHI International, brings a consultancy-first approach to helping customers rapidly adapt to business changes by delivering end-to-end support of the transformation process._\n\nStratascale was selected as GitLab’s Partner of the Year because it provides a strong delivery framework, which is leveraged by customers looking to migrate their application development framework and meet DevSecOps requirements using GitLab technology. As a **result**, GitLab’s partnership with both Stratascale and legacy SHI experienced significant growth in 2023.\n\n### Emerging Partner of the Year: NextLink Labs\n_NextLink Labs is a DevOps, custom software development and cybersecurity consultancy._\n\nNextLink Labs is GitLab’s first Emerging Partner of the Year. NextLink Labs scales their impact to prospects and customers by leading with partnership best practices and **collaboration**. They provide value stream assessments, work with GitLab to create market awareness for our joint support, and help customers create paths to leverage the full value of GitLab’s leading DevSecOps platform. \n\n### Public Sector Partner of the Year: Flywheel Data\n_Flywheel Data is a value added reseller whose goal is to provide clients with the right tools, products, and technologies to accelerate mission success._\n\nFor the second year in a row, Flywheel Data is GitLab’s Public Sector Partner of the Year. Flywheel Data works with GitLab to deliver a single platform for DevSecOps to the U.S. government markets. Together, Flywheel and GitLab deliver immediate value to joint clients by simplifying the way their development, security, IT and ops teams collaborate to build software and manage infrastructure. This leads to a more **efficient** workflow for joint clients.\n\n### Public Sector Distributor of the Year: Carahsoft\n_Carahsoft is a public sector IT solutions provider, supporting federal, state, and local government agencies as well as education and healthcare organizations._\n\nCarahsoft earned Public Sector Distributor of the Year as a result of their complete alignment and execution of CREDIT values. Carahsoft demonstrates **collaboration** through dedicated resources and integrated alignment with the GitLab team, which enables Carahsoft and the reseller community to invest in the partnership while accelerating the public sector's ability to achieve digital transformation initiatives and mission success.\n\n### Public Sector Services Partner of the Year: Sirius Federal – A CDW Company\n_Sirius Federal, A CDW Company, helps customers design, orchestrate and manage technologies that drive business and government agency success._\n\nSirius Federal **iterated** on their processes over the last year to introduce new resources, such as “This Sirius Federal GitLab Adoption Workshop.” Sirius Federal offers best practice solutions that help Public Sector agencies achieve optimal outcomes and meet compliance guidelines. Their new offering increased engagement, set a vision for growth, and helped customers who had been stalled in their DevSecOps Platform adoption.\n\nOur heartfelt congratulations to all the winners! We look forward to further collaboration in the year to come. \n\n*Learn more about [GitLab’s Partner Program](https://partners.gitlab.com/).*\n",[283,1203,9],{"slug":3550,"featured":6,"template":698},"meet-the-2023-gitlab-partner-of-the-year-award-winners","content:en-us:blog:meet-the-2023-gitlab-partner-of-the-year-award-winners.yml","Meet The 2023 Gitlab Partner Of The Year Award Winners","en-us/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners.yml","en-us/blog/meet-the-2023-gitlab-partner-of-the-year-award-winners",{"_path":3556,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3557,"content":3563,"config":3569,"_id":3571,"_type":13,"title":3572,"_source":15,"_file":3573,"_stem":3574,"_extension":18},"/en-us/blog/merge-request-reviewers",{"title":3558,"description":3559,"ogTitle":3558,"ogDescription":3559,"noIndex":6,"ogImage":3560,"ogUrl":3561,"ogSiteName":685,"ogType":686,"canonicalUrls":3561,"schema":3562},"Code review made easier thanks to merge request reviewers in GitLab 13.7","Code review is a critically important part of the software development, but it can be hard – and time consuming – to arrange. That's where our new merge request reviewers feature comes in. Here's what to look for in our 13.7 release.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681664/Blog/Hero%20Images/merge_request_reviewers.jpg","https://about.gitlab.com/blog/merge-request-reviewers","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Code review made easier thanks to merge request reviewers in GitLab 13.7\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Gruesso\"}],\n \"datePublished\": \"2020-10-13\",\n }",{"title":3558,"description":3559,"authors":3564,"heroImage":3560,"date":3566,"body":3567,"category":1203,"tags":3568},[3565],"Daniel Gruesso","2020-10-13","\n\nEdit: This feature was originally planned for the 13.5 release but has now been rescheduled to the 13.7 release in order to address some performance improvements.\n{: .alert .alert-info .note}\n\nRequesting a code review is an important part of contributing code to any software project. However, deciding _who_ should review your code and asking for a review are no easy tasks. Historically, teams making use of [merge requests](/solutions/continuous-integration/) for their code review needs have used the \"assignee\" field for both authors and reviewers but this makes it hard for others to determine who's doing what on a merge request; for example, consider a merge request with a single author and 2 reviewers. If all parties are on the “assignee” field at once, it is hard for an external user to find out who to reach out for something specific.\n\nThe back-and-forth between authors and reviewers causes the author to go through MR history to find the original reviewer as well as unnecessary assigning back and forth from everyone. Peers who are coming on to assist cannot easily find relevant players for this merge request. Lastly, the merge request author does not know if a reviewer has reviewed but not approved the changes, or if more work is needed from them.\n\n## GitLab code reviews\n\nWhether or not code is good quality can’t be taken on faith; code quality needs to be checked. GitLab makes it easy to collaborate on code reviews within a merge request.\nIn GitLab, users can assign one or more code reviewers to a source project. Collaboration in merge requests with GitLab reviewers helps deployments go more smoothly. The code reviewer option in GitLab is available on GitLab Premium and GitLab Ultimate.\n\n## Merge requests and code reviews\nThe merge request Reviewers feature in GitLab allows for a review of your work and to see the critique progress status. The “suggest changes” feature lets a colleague suggest alterations that the original author can choose to accept or not, just with the click of a button. And, of course, every change made to a block of code can be reviewed before it goes live.\n\n### Feature branches and code reviews\nCreating a new feature branch or new code automatically kicks off a merge request, and that is the place to request a code review. In the MR, inline code reviews can be performed either on a single line or multiple lines of code, and a reviewer can leave comments. A feature branch allows for changes to be made to the codebase without them moving onto the main default branch.\n\nAfter the merge request and code review are complete, feature branches can be deleted to keep the source code repository clean as possible. It’s also possible to add time tracking to an MR to discern how long the process, including the code review, takes from beginning to end.\n\nThe merge request widget helps delete these feature branches once a merge request and code review are done. This can be set up to happen as you create the initial MR by choosing the “delete source branch when merge request accepted” selection. That way, the branch gets deleted after the MR is merged.\n\n### Improving code reviews\n\nTo bridge these gaps, GitLab 13.7 introduces merge request \"reviewers,\" which easily allows authors to request a review as well as see the status of the review. By simply selecting one or more users from the \"reviewers\" field, the assigned reviewers will receive a notification of the request to review the merge request. This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer.\n\n![Merge request reviewers](https://about.gitlab.com/images/blogimages/reviewers_sidebar.png){: .shadow.center}\nScreenshot from upcoming GitLab 13.7 release\n{: .note.text-center}\n\n### What's next\n\nFuture improvements include [suggesting the most relevant reviewers](https://gitlab.com/gitlab-org/gitlab/-/issues/195781) as well as [streamlining the approval rules](https://gitlab.com/gitlab-org/gitlab/-/issues/231244) experience when paired with reviewers.\n\nWe are excited to see this feature ship soon to GitLab.com and for self-managed users on October 22nd. As always, we encourage you to participate in the conversation by visiting the related [reviewers epic](https://gitlab.com/groups/gitlab-org/-/epics/1823) in the GitLab project.\n\nCover image by [Kevin Ku](https://unsplash.com/@ikukevk) on [Unsplash](https://unsplash.com/photos/w7ZyuGYNpRQ)\n{: .note}\n",[1264,9],{"slug":3570,"featured":6,"template":698},"merge-request-reviewers","content:en-us:blog:merge-request-reviewers.yml","Merge Request Reviewers","en-us/blog/merge-request-reviewers.yml","en-us/blog/merge-request-reviewers",{"_path":3576,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3577,"content":3583,"config":3588,"_id":3590,"_type":13,"title":3591,"_source":15,"_file":3592,"_stem":3593,"_extension":18},"/en-us/blog/migrating-your-version-control-to-git",{"title":3578,"description":3579,"ogTitle":3578,"ogDescription":3579,"noIndex":6,"ogImage":3580,"ogUrl":3581,"ogSiteName":685,"ogType":686,"canonicalUrls":3581,"schema":3582},"Migrating your version control to Git? Here’s what you need to know","Change is hard, but moving to Git doesn’t have to be if you read these tips.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681731/Blog/Hero%20Images/migrategit.jpg","https://about.gitlab.com/blog/migrating-your-version-control-to-git","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Migrating your version control to Git? Here’s what you need to know\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2020-11-12\",\n }",{"title":3578,"description":3579,"authors":3584,"heroImage":3580,"date":3585,"body":3586,"category":693,"tags":3587},[951],"2020-11-12","\n\nDeciding to make sweeping changes that’ll affect your entire organization is a nerve-wracking experience, because until you see the change in action, you don’t know whether it’ll be a success or a disaster. Migrating from one [version control](/topics/version-control/) to Git is just that type of change that can make team members and leaders feel overwhelmed. However, advanced knowledge helps teams prepare and transition more smoothly. Here are a few tips to help you make the change.\n\n## Keep your previous version control system\n\nIf you perform a tip migration and copy over only the most recent commits, teams will still need access to the previous version control to consult project history. Set the old version control system to read-only and place a breadcrumb trail in Git to help developers find the information they need in the previous version control. Retaining the old version control preserves history and enables new team members to find important information, which may be lost as veteran contributors move to different roles or forget code specifics.\n\n## Clone your previous version control\n\nBefore making a sudden shift to a new version control, create a mirror of your previous system to test out whether your current processes work with Git or you need to make adjustments. Continuous integration, code review, security testing, and release processes should all be tested with the clone so that the complications can be remedied before the entire workflow breaks down.\n\n## Invest in learning Git\n\nAlthough Git is the most popular and widely-used version control, it’s also known for its initial degree of difficulty. Developers who are new to Git may struggle with the command line and find [branching](https://learngitbranching.js.org/) tedious and confusing. Despite Git’s learning curve, its positive impact on productivity and code quality is worth the trouble, and teams can cope with these challenges by investing in training or identifying Git experts within the team to coach others. Team members may find it easier to work with a [GUI](https://git-scm.com/downloads/guis) rather than the command line, so using a strong tool could help ease the transition.\n\n## Identify a branching strategy\n\n![A diagram of colorful blocks representing code with connecting lines to represent branches and the flow](https://about.gitlab.com/images/blogimages/illustration_feature-branches.png){: .shadow.small.left.wrap-text}\n\nBefore [migrating to Git](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git), it’s imperative to select a branching strategy and train the team on its specifics. Git is a distributed version control system and offers unparalleled workflow flexibility, which can either streamline or convolute development depending on whether a team identifies a single branching strategy. Without a strategy, team members could interfere with each other’s work and ship unfinished features. Collaborating through a single workflow keeps the codebase clean and helps team members maintain velocity. Git enables teams to approach software development through a variety of workflows to meet specific needs. Some branching strategies, such as [GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html), are more straightforward than others, so it’s important to research your team’s needs before deciding.\n\n## Read more about Git\n\nAccording to the [2020 DevSecOps Survey](/developer-survey/), Git is the choice for source control for 92% of the survey takers, with just 2% using no source control and even smaller percentages using Azure DevOps Server and Subversion. Here are few additional posts to help you get the most out of Git.\n\n- [15 Git tips to improve workflow](/blog/15-git-tips-improve-workflow/)\n- [How Git Partial Clone lets you fetch only the large file you need](/blog/partial-clone-for-massive-repositories/)\n- [A guide to Git for beginners](/blog/beginner-git-guide/) \n\nCover image by [Belinda Fewings](https://unsplash.com/@bel2000a?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/1Spvd7ktFX4)\n{: .note}\n",[1242,912,9],{"slug":3589,"featured":6,"template":698},"migrating-your-version-control-to-git","content:en-us:blog:migrating-your-version-control-to-git.yml","Migrating Your Version Control To Git","en-us/blog/migrating-your-version-control-to-git.yml","en-us/blog/migrating-your-version-control-to-git",{"_path":3595,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3596,"content":3602,"config":3608,"_id":3610,"_type":13,"title":3611,"_source":15,"_file":3612,"_stem":3613,"_extension":18},"/en-us/blog/monitor-application-performance-with-distributed-tracing",{"title":3597,"description":3598,"ogTitle":3597,"ogDescription":3598,"noIndex":6,"ogImage":3599,"ogUrl":3600,"ogSiteName":685,"ogType":686,"canonicalUrls":3600,"schema":3601},"Monitor application performance with Distributed Tracing","Learn how Distributed Tracing helps troubleshoot application performance issues by providing end-to-end visibility and seamless collaboration across your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098000/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5x6kH5vwjz8cwKgSBh1w11_1750098000511.png","https://about.gitlab.com/blog/monitor-application-performance-with-distributed-tracing","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Monitor application performance with Distributed Tracing\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sacha Guyon\"}],\n \"datePublished\": \"2024-06-13\",\n }",{"title":3597,"description":3598,"authors":3603,"heroImage":3599,"date":3605,"body":3606,"category":1388,"tags":3607},[3604],"Sacha Guyon","2024-06-13","Downtime due to application defects or performance issues can have devastating financial consequences for businesses. An hour of downtime is estimated to cost firms $301,000 or more, according to [Information Technology Intelligence Consulting's 2022 Global Server Hardware and Server OS Reliability Survey](https://itic-corp.com/server-and-application-by-the-numbers-understanding-the-nines/). These issues often originate from human-introduced changes, such as code or configuration changes.\n\nResolving such incidents requires development and operations teams to collaborate closely, investigating the various components of the system to find the root cause change, and promptly restore the system back to normal operation. However, these teams commonly use separate tools to build, manage, and monitor their application services and infrastructure. This approach leads to siloed data, fragmented communication, and inefficient context switching, increasing the time spent to detect and resolve incidents.\n\nGitLab aims to address this challenge by combining software delivery and monitoring functionalities within the same platform. Last year, we released [Error Tracking](https://docs.gitlab.com/ee/operations/error_tracking.html) as a general availability feature in [GitLab 16.0](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#error-tracking-is-now-generally-available). Now, we're excited to announce the [Beta release of Distributed Tracing](https://docs.gitlab.com/ee/operations/tracing), the next step toward a comprehensive observability offering seamlessly integrated into the GitLab DevSecOps platform.\n\n## A new era of efficiency: GitLab Observability\n\nGitLab Observability empowers development and operations teams to visualize and analyze errors, traces, logs, and metrics from their applications and infrastructure. By integrating application performance monitoring into existing software delivery workflows, context switching is minimized and productivity is increased, keeping teams focused and collaborative on a unified platform.\n\nAdditionally, GitLab Observability bridges the gap between development and operations by providing insights into application performance in production. This enhances transparency, information sharing, and communication between teams. Consequently, they can detect and resolve bugs and performance issues arising from new code or configuration changes sooner and more effectively, preventing those issues from escalating into major incidents that could negatively impact the business.\n\n## What is Distributed Tracing?\n\nWith Distributed Tracing, engineers can identify the source of application performance issues. A trace represents a single user request that moves through different services and systems. Engineers are able to analyze the timing of each operation and any errors as they occur.\n\nEach trace is composed of one or more spans, which represent individual operations or units of work. Spans contain metadata like the name, timestamps, status, and relevant tags or logs. By examining the relationships between spans, developers can understand the request flow, identify performance bottlenecks, and pinpoint issues.\n\nDistributed Tracing is especially valuable for [microservices architecture](https://about.gitlab.com/topics/microservices/), where a single request may involve numerous service calls across a complex system. Tracing provides visibility into this interaction, empowering teams to quickly diagnose and resolve problems.\n\n![tracing example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098009139.png)\n\nFor example, this trace illustrates a how a user request flows through difference services to fetch product recommendations on a e-commerce website:\n\n- `User Action`: This indicates the user's initial action, such as clicking a button to request product recommendations on a product page.\n- `Web front-end`: The web front-end sends a request to the recommendation service to retrieve product recommendations.\n- `Recommendation service`: The request from the web front-end is handled by the recommendation service, which processes the request to generate a list of recommended products.\n- `Catalog service`: The recommendation service calls the catalog service to fetch details of the recommended products. An alert icon suggests an issue or delay at this stage, such as a slow response or error in fetching product details.\n- `Database`: The catalog service queries the database to retrieve the actual product details. This span shows the SQL query in the database.\n\nBy visualizing this end-to-end trace, developers can identify performance issues – here, an error in the Catalog service – and quickly diagnose and resolve issues across the distributed system.\n\n![End-to-end trace](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098009140.png)\n\n## How Distributed Tracing works\n\nHere is a breakdown of how Distributed Tracing works.\n\n### Collect data from any application with OpenTelemetry\n\nTraces and spans can be collected using [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/), an open-source observability framework that supports a wide array of SDKs and libraries across [major programming languages and frameworks](https://opentelemetry.io/docs/languages/). This framework offers a vendor-neutral approach for collecting and exporting telemetry data, enabling developers to avoid vendor lock-in and choose the tools that best fit their needs.\n\nThis means that if you are already using OpenTelemetry with another vendor, you can send data to us simply by adding our endpoint to your configuration file, making it very easy to try out our features!\n\n![Distributed tracing workflow diagram](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098009141.png)\n\n### Ingest and retain data at scale with fast, real-time queries\n\nObservability requires the storage and querying of vast amounts of data while maintaining low latency for real-time analytics. To meet these needs, we developed a horizontally scalable, long-term storage solution using ClickHouse and Kubernetes, based on our [acquisition of Opstrace](https://about.gitlab.com/press/releases/2021-12-14-gitlab-acquires-opstrace-to-expand-its-devops-platform-with-open-source-observability-solution/). This [open-source platform](https://gitlab.com/gitlab-org/opstrace/opstrace) ensures rapid query performance and enterprise-grade scalability, all while minimizing costs.\n\n### Explore and analyze traces effortlessly\nAn advanced, native-level user interface is crucial for effective data exploration. We built such an interface from the ground up, starting with our Trace Explorer, which allows users to examine traces and understand their application's performance:\n- __Advanced filtering:__ Filter by services, operation names, status, and time range. Autocomplete helps simplify querying.\n- __Error highlighting:__ Easily identify error spans in search results.\n- __RED metrics:__ Visualize the Requests rate, Errors rate, and average Duration as a time-series chart for any search in real-time.\n- __Timeline view:__ Individual traces are displayed as a waterfall diagram, providing a complete view of a request distributed across different services and operations.\n- __Historical data:__ Users can query traces up to 30 days in the past.\n\n![Distributed Tracing - image 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098009141.png)\n\n## How we use Distributed Tracing at GitLab\n[Dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is a core value and practice at GitLab. We've been already using early versions of Distributed Tracing for our engineering and operations needs. Here are a couple example use cases from our teams:\n\n### 1. Debug errors and performance Issues in GitLab Agent for Kubernetes\n\nThe [Environments group](https://handbook.gitlab.com/handbook/engineering/development/ops/deploy/environments/) has been using Distributed Tracing to troubleshoot and resolve issues with the [GitLab Agent for Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent), such as timeouts or high latency issues. The Trace List and Trace Timeline views offer valuable insights for the team to address these concerns efficiently. These traces are shared and discussed in the [related GitLab issues](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/386#note_1576431796), where the team collaborates on resolution.\n\n\u003Ccenter>\u003Ci>\"The Distributed Tracing feature has been invaluable in pinpointing where latency issues are occurring, allowing us to focus on the root cause and resolve it faster.\" - Mikhail, GitLab Engineer\u003C/i>\u003C/center>\u003Cp>\n\n### 2. Optimize GitLab’s build pipeline duration by identifying performance bottlenecks\n\nSlow deployments of GitLab source code can significantly impact the productivity of the whole company, as well as our compute spending. Our main repository runs [over 100,000 pipelines every month](https://gitlab.com/gitlab-org/gitlab/-/pipelines/charts). If the time it takes for these pipelines to run changes by just one minute, it can add or remove more than 2,000 hours of work time. That's 87 extra days!\n\nTo optimize pipeline execution time, GitLab's [platform engineering teams](https://handbook.gitlab.com/handbook/engineering/infrastructure/) utilize a [custom-built tool](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace) that converts GitLab deployment pipelines into traces.\n\nThe Trace Timeline view allows them to visualize the detailed execution timeline of complex pipelines and pinpoint which jobs are part of the critical path and slowing down the entire process. By identifying these bottlenecks, they can optimize job execution – for example, making the job fail faster, or running more jobs in parallel – to improve overall pipeline efficiency.\n\n![Distributed Tracing - image 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098009143.gif)\n\n[The script is freely available](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace), so you can adapt it for your own pipelines.\n\n\u003Ccenter>\u003Ci>\"Using Distributed Tracing for our deployment pipelines has been a game-changer. It's helped us quickly identify and eliminate bottlenecks, significantly reducing our deployment times.\"- Reuben, GitLab Engineer\u003C/i>\u003C/center>\u003Cp>\n\n## What's coming next?\n\nThis release is just the start: In the next few months, we'll continue to expand our observability and monitoring features with the upcoming Metrics and Logging releases. Check out [our Observability direction page](https://about.gitlab.com/direction/monitor/platform-insights/) for more info, and keep an eye out for updates!\n\n## Join the private Beta\n\nInterested in being part of this exciting journey? [Sign up to enroll in the private Beta](https://docs.gitlab.com/operations/observability/) and try out our features. Your contribution can help shape the future of observability within GitLab, ensuring our tools are perfectly aligned with your needs and challenges.\n\n> Help shape the future of GitLab Observability. [Join the Distributed Tracing Beta.](https://docs.gitlab.com/operations/observability/)",[2402,829,1203,495,9],{"slug":3609,"featured":90,"template":698},"monitor-application-performance-with-distributed-tracing","content:en-us:blog:monitor-application-performance-with-distributed-tracing.yml","Monitor Application Performance With Distributed Tracing","en-us/blog/monitor-application-performance-with-distributed-tracing.yml","en-us/blog/monitor-application-performance-with-distributed-tracing",{"_path":3615,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3616,"content":3622,"config":3628,"_id":3630,"_type":13,"title":3631,"_source":15,"_file":3632,"_stem":3633,"_extension":18},"/en-us/blog/move-to-distributed-vcs",{"title":3617,"description":3618,"ogTitle":3617,"ogDescription":3618,"noIndex":6,"ogImage":3619,"ogUrl":3620,"ogSiteName":685,"ogType":686,"canonicalUrls":3620,"schema":3621},"Why you should switch to distributed version control","We share a few reasons why high-performing software development teams use distributed version control systems over centralized version control.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681766/Blog/Hero%20Images/distributedvcs.jpg","https://about.gitlab.com/blog/move-to-distributed-vcs","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why you should move from centralized version control to distributed version control\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2020-11-19\",\n }",{"title":3623,"description":3618,"authors":3624,"heroImage":3619,"date":3625,"body":3626,"category":693,"tags":3627},"Why you should move from centralized version control to distributed version control",[951],"2020-11-19","\n\nDistributed version control has the power to increase collaboration and streamline development, but many teams are still using a centralized [version control system](/topics/version-control/) that prevents them from reaching their full development potential. If your team uses a centralized version control system, velocity, code quality, and collaboration aren’t at the same levels of high-performing teams that consistently deliver valuable products at rapid speeds. Using a [version control](/topics/version-control/) system isn’t enough to stay competitive in today’s market - you have to use the best tools available.\n\n## What is version control?\n\nVersion control lets software development teams build up communication and collaboration while continuously making and tracking changes to source code. Sometimes called code revision control, version control exists as a safety net to protect the source code while giving the development team the flexibility to experiment without worrying about causing damage or creating code conflicts. A version control system can be local, centralized, or distributed based on organizational needs.\n\n## Centralized version control: A relic from the past\n\nA centralized version control system relies on a central server where developers commit changes. Users like centralized systems, because they’re simple to set up and provide admins with workflow controls. Centralized vcs, like Subversion, CVS, and Perforce, solve the age-old problem of manually storing multiple copies on a hard drive, but the few benefits don’t outweigh what’s at risk from relying on a [single server](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control).\n\nIf the only copy of a project becomes corrupted or goes down, developers are unable to access the code or retrieve previous versions. Also, remote commits are extremely slow, because users must commit through a network to the central repository, which can slow down systems. Users must also be in network to push changes, limiting where and when developers can commit. Merging and branching are also difficult and confusing, since contributors have to track merges and branch as a single check-in.\n\n## Distributed version control: The key to rapid software development\n\nUnlike a centralized version control system, a distributed version control doesn’t have a single point of failure, because developers clone repositories on their distributed version control workstations, creating multiple backup copies. If the [source code](/solutions/source-code-management/) is corrupted, teams can use any developer’s clone as a backup, increasing security since there’s little risk of losing a project’s entire history. \n\nAlso, because there are local copies, developers can commit offline, which offers flexibility in their personal workflow and prevents having to commit as a giant changeset. Distributed version control, such as Git, Bazaar, and Mercurial, offers fast [branching](/topics/version-control/what-is-git-workflow/), because there’s no communication with a remote server - everything is done on a local drive.\n\nAre you ready for a quick look at Git, the most popular distributed version control system? [Brendan O’Leary](/company/team/#brendan), senior developer evangelist, explains Git basics to help teams get started in the video below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/9oDNBuive-g\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nThe biggest challenge to switching to a distributed version control system is the learning curve. Teams will be able to ship higher quality code at new speeds using a distributed version control.\n\n## Core benefits of a distributed version control system\n\nA [distributed version control system](/topics/version-control/benefits-distributed-version-control-system/) is like each team member having a second set of hands to catch problems, introduce fast fixes, and execute fast merging with fewer conflicts. Additionally, it makes the collaboration process hyper-efficient, thereby letting DevOps teams work asynchronously. Version control empowers teams to collaborate and streamline software development to resolve pain points and create a centralized location for code.\n\n## Popular distributed version control systems (e.g. Git)\n\nThe three most well-known options are Git, SVN, and Mercurial. The most popular of these options is Git, which is an open-source distributed system that is used for any size software project. \n\nGit offers tons of features and benefits, including:\n\n* Strong support for non-linear development.\n\n* Works with popular protocols/systems including HTTP, FTP, and SSH.\n\n* Offers GIT GUI, which allows for fast re-scan, state change, sign off, commit & push the code quickly with low friction.\n\n* It can handle any size project.\n\n* Can function across platforms.\n\n* Toolkit-based design.\n\n* Rapid and efficient performance.\n\n* Code changes are easily tracked and managed.\n\nWhen choosing a version control system, make sure to evaluate all options to find the best fit for your team.\n\nCover image by [Hans-Peter Gauster](https://unsplash.com/@sloppyperfectionist?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/3y1zF4hIPCg)\n{: .note}\n",[1242,912,9],{"slug":3629,"featured":6,"template":698},"move-to-distributed-vcs","content:en-us:blog:move-to-distributed-vcs.yml","Move To Distributed Vcs","en-us/blog/move-to-distributed-vcs.yml","en-us/blog/move-to-distributed-vcs",{"_path":3635,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3636,"content":3641,"config":3647,"_id":3649,"_type":13,"title":3650,"_source":15,"_file":3651,"_stem":3652,"_extension":18},"/en-us/blog/open-sourcing-the-gitter-mobile-apps",{"title":3637,"description":3638,"ogTitle":3637,"ogDescription":3638,"noIndex":6,"ogImage":3154,"ogUrl":3639,"ogSiteName":685,"ogType":686,"canonicalUrls":3639,"schema":3640},"Open-sourcing the Gitter mobile apps","Learn how we open sourced the Android and iOS Gitter apps.","https://about.gitlab.com/blog/open-sourcing-the-gitter-mobile-apps","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Open-sourcing the Gitter mobile apps\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Eastwood\"}],\n \"datePublished\": \"2019-11-22\",\n }",{"title":3637,"description":3638,"authors":3642,"heroImage":3154,"date":3644,"body":3645,"category":1053,"tags":3646},[3643],"Eric Eastwood","2019-11-22","Before we acquired Gitter most every part of Gitter was\nprivate/closed-source. The main\n[webapp](https://gitlab.com/gitlab-org/gitter/webapp) was open-sourced in\nJune 2017 and got both mobile\n[Android](https://gitlab.com/gitlab-org/gitter/gitter-android-app)/[iOS](https://gitlab.com/gitlab-org/gitter/gitter-ios-app)\napps open sourced in September 2018. If you would like to come help out,\nfeel free to send us a merge request! This blog post will go over some the\ntechnical details of making the projects available for anyone to contribute.\n\n\nHere is the basic overview:\n\n\n1. Find secrets in the current state of the project (don't worry about the\ncommit history) and move to some config that isn't tracked in the repo.\n\n1. Find/remove secrets throughout the whole repo commit history.\n\n1. Make the project public 🎉\n\n1. Caveats:\n - Because we are rewriting the git history, I don't know of a way to keep merge requests/pull requests because the MRs reference the old commit hashes.\n\nQuick navigation:\n\n\n- [Jump to open sourcing Android](#android)\n\n- [Jump to open sourcing iOS](#ios)\n\n\n## Android\n\n\nIf you want to check out the full project and final result, you can check\nout the [project on\nGitLab](https://gitlab.com/gitlab-org/gitter/gitter-android-app)\n([open-sourced\n2018-8-8](https://twitter.com/gitchat/status/1027293167471812611)).\n\n\nTo start out, we used the [GitHub to GitLab project\nimport](https://docs.gitlab.com/ee/user/project/import/github.html) to move\nthe private GitHub project over to GitLab. We named it `gitter-android-app2`\nso that later on we could create the actual clean public project without any\nof the orphaned git references that may potentially leak.\n\n\n### Finding secrets\n\n\n[`truffleHog`](https://github.com/dxa4481/truffleHog) will search for high\nentropy strings (like tokens/passwords) through the entire git repo history.\nIt's also useful to find all the potential areas where secrets may still\nexist in the current state of the project. Some sticky points we encountered\nwhile using include:\n\n\n- \"I wish we could just search the current state of the project instead of\nall git history (the `--max_depth=2` argument will just make it search the\ndiff of the latest commit)\"\n[dxa4481/truffleHog#92](https://github.com/dxa4481/truffleHog/issues/92).\n\n- \"The output will show the entire diff for the triggered commit which is a\nbit burdensome to see exactly what is wrong. The JSON output `--json` is\nsometimes easier to understand\"\n[https://github.com/dxa4481/truffleHog/issues/58](https://github.com/dxa4481/truffleHog/issues/58)\nor\n[dxa4481/truffleHog#102](https://github.com/dxa4481/truffleHog/issues/102).\n\n\n### Moving secrets to untracked config\n\n\nOnce we figure out where all of the secrets are we need a config/variable\nsolution that isn't tracked by git but still lets them be available when\nbuilding. We also wanted the solution to work in GitLab CI for some sanity\nbuilds/testing. There are lots of good articles on this topic:\n\n\n- [Remove private signing information from your\nproject](https://developer.android.com/studio/build/gradle-tips#remove-private-signing-information-from-your-project)\n\n- [Keeping Your Android Project’s Secrets\nSecret](https://medium.com/@geocohn/keeping-your-android-projects-secrets-secret-393b8855765d)\n\n- [Hiding Secrets in Android\nApps](https://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/)\n\n- [Keeping secrets in an Android\nApplication](https://joshmcarthur.com/2014/02/16/keeping-secrets-in-an-android-application.html)\n\n- [Android: Loading API Keys and other secrets from properties file using\ngradle](https://gist.github.com/curioustechizen/9f7d745f9f5f51355bd6)\n\n- [How can I keep API keys out of source\ncontrol?](https://arstechnica.com/information-technology/2013/12/how-can-i-keep-api-keys-out-of-source-control/)\n\n\nOur solution is completely based on the information in these articles. We\nchose to go the route of defining things in a `secrets.properties` file\nwhich can easily be read in the Gradle build script which handles the build\neven when using Android Studio. If the `secrets.properties` file doesn't\nexist (like in CI), it will try to read the secrets from [environment\nvariables which can easily be supplied in the project\nsettings](https://docs.gitlab.com/ee/ci/variables/).\n\n\n`secerts.properties`\n\n\n```properties\n\n# Visit https://developer.gitter.im/apps (sign in) and create a new app\n\n# Name: my-gitter-android-app (can be anything)\n\n# Redirect URL: https://gitter.im/login/oauth/callback\n\noauth_client_id=\"...\"\n\noauth_client_secret=\"...\"\n\noauth_redirect_uri=\"https://gitter.im/login/oauth/callback\"\n\n```\n\n\n`build.gradle`\n\n\n```gradle\n\napply plugin: 'com.android.application'\n\n\n// Try reading secrets from file\n\ndef secretsPropertiesFile = rootProject.file(\"secrets.properties\")\n\ndef secretProperties = new Properties()\n\nif (secretsPropertiesFile.exists()) {\n secretProperties.load(new FileInputStream(secretsPropertiesFile))\n}\n\n// Otherwise read from environment variables, this happens in CI\n\nelse {\n secretProperties.setProperty(\"oauth_client_id\", \"\\\"${System.getenv('oauth_client_id')}\\\"\")\n secretProperties.setProperty(\"oauth_client_secret\", \"\\\"${System.getenv('oauth_client_secret')}\\\"\")\n secretProperties.setProperty(\"oauth_redirect_uri\", \"\\\"${System.getenv('oauth_redirect_uri')}\\\"\")\n}\n\n\nandroid {\n ...\n\n defaultConfig {\n ...\n\n buildConfigField(\"String\", \"oauth_client_id\", \"${secretProperties['oauth_client_id']}\")\n buildConfigField(\"String\", \"oauth_client_secret\", \"${secretProperties['oauth_client_secret']}\")\n buildConfigField(\"String\", \"oauth_redirect_uri\", \"${secretProperties['oauth_redirect_uri']}\")\n }\n ...\n}\n\n```\n\n\nUse the config variables in the Java app:\n\n\n```java\n\nimport im.gitter.gitter.BuildConfig;\n\n\nBuildConfig.oauth_client_id;\n\nBuildConfig.oauth_client_secret;\n\nBuildConfig.oauth_redirect_uri;\n\n```\n\n\n#### Removing compiled assets\n\n\nWe use a `WebView` to display the HTML markdown messages in the chat room.\nThis view uses assets built from the main [`webapp`\nproject](https://gitlab.com/gitlab-org/gitter/webapp). Because these assets\nhad some inlined production\n[`webapp`](https://gitlab.com/gitlab-org/gitter/webapp) secrets that whole\ndirectory needed to be removed.\n\n\nInitially, we opted to have the developer build these assets with their own\nsecrets and symlink the build output directory. The [community made this\neven\nsimpler](https://gitlab.com/gitlab-org/gitter/gitter-android-app/merge_requests/113),\nso now there is just a Gradle task to run which fetches the latest build we\nhave available from the `webapp` GitLab CI.\n\n\n### Removing secrets from the repo history\n\n\nFrom your `truffleHog` results earlier, you should know where secrets were\nstored throughout the history. We can use [BFG\nRepo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/) to remove and\nrewrite the repo history quickly.\n\n\nWhen using BFG, I wanted just to rewrite all of the sensitive values in\n`app/src/main/res/values/settings.xml` instead of completely removing them,\nbut rewriting isn't an option with BFG so I went ahead with deleting it and\nrecreated it in a commit afterwards. 🤷\n\n\nFor the Android app, here are the BFG commands I used,\n\n\n- Remove `app/src/main/assets/www/`\n - `java -jar \"bfg.jar\" --delete-folders www`\n- Remove `app/src/main/res/values/settings.xml`\n - `java -jar \"bfg.jar\" --delete-files settings.xml`\n- Remove sensitive strings where we can't just remove the whole file\n(collected from `truffleHog` results)\n - `java -jar \"bfg.jar\" --replace-text \"gitter-android-bad-words.txt\"`\n\nAfter you think you removed all the secrets, it's best to run `truffleHog`\nagain just to make sure no secrets are leftover. 😉\n\n\n### Make it public\n\n\nNow it's time to update your `readme` with some setup instruction so the\ncommunity knows how to contribute.\n\n\nThis is the scary part 😅. Go to **Project settings** > **General** >\n**Permissions** > set **Project visibility** as **Public**. You can [read\nmore about project access\nhere](https://docs.gitlab.com/ee/public_access/public_access.html).\n\n\nCurious about how to setup builds in GitLab CI? [Learn more from this blog\npost](/blog/setting-up-gitlab-ci-for-android-projects/), which was what we\nused to set it up for our projects.\n\n\nYou can even learn how we [automated the release process so we can publish\nstraight to the Google Play Store from GitLab CI via fastlane\n🚀](/blog/android-publishing-with-gitlab-and-fastlane/).\n\n\n## iOS\n\n\nIf you want to see the full project and final result, you can check out the\n[project on GitLab](https://gitlab.com/gitlab-org/gitter/gitter-ios-app)\n([open-sourced\n2018-9-18](https://twitter.com/gitchat/status/1041795909103898625)).\n\n\nThe same concepts apply from the Android section. We create a separate\nprivate project, `gitter-ios-app2`, where we can work and later on, we can\ncreate the actual clean public project(`gitter-ios-app`) without any of the\norphaned git references that could leak.\n\n\n### Finding secrets\n\n\n`truffleHog` didn't work well in the iOS project because there was a bunch\nof generated XCode files that had file hashes (high entropy strings which\ntruffleHog looks for) – which meant every commit was listed. 🤦‍ Instead of\ntrying to find something to filter the results down or get another tool, I\ndecided just search manually. Here is the list of things we looked for:\n\n\n- `token`\n\n- `secret`\n\n- `key`\n\n- `cert`\n\n- `api`\n\n- `pw`\n\n- `password`\n\n\nI used this directory filter when `Ctrl + f` those strings above to avoid\nfinding things outside of the repo itself (copy-paste for Atom editor):\n`!Common/,!Libraries,!Gitter/www,!Pods/,!xctool`\n\n\n### Moving secrets to untracked config\n\n\nThe iOS app uses a few git sub-modules which we also had to check for\nsecrets before making them public. It turned out only one of the sub-modules\n–\n[`troupeobjccommon`](https://gitlab.com/gitlab-org/gitter/troupeobjccommon)\n– had secrets of it's own so I ran through the same secret removal process.\n\n\nWe had the same OAuth secrets in the main part of the iOS app, but since\n`troupeobjccommon` was also trying to handle OAuth secret settings, we opted\nfor putting the new logic in `troupeobjccommon` to avoid having to refactor\nwhatever other downstream code that uses the same submodule (like the macOS\ndesktop app).\n\n\nHere are some articles around handling secrets in an iOS project,\n\n\n- [Secret variables in Xcode AND your CI for fun and profit\n💌](https://medium.com/flawless-app-stories/secret-variables-in-xcode-and-your-ci-for-fun-and-profit-d387a50475d7)\n\n- [Secrets Management in iOS\nApplications](https://medium.com/@jules2689/secrets-management-in-ios-applications-52795c254ec1)\n\n\nSince iOS apps can only be built on macOS and we don't have any macOS GitLab\nCI runners, our solution doesn't have to be CI compatible. You can track\n[this issue for shared macOS GitLab CI\nrunners](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5720).\n\n\n`Gitter/GitterSecrets-Dev.plist`\n\n\n```xml\n\n\u003C?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\n\u003C!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\"\n\"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">\n\n\u003Cplist version=\"1.0\">\n\n\u003Cdict>\n \u003C!--\n Visit https://developer.gitter.im/apps (sign in) and create a new app\n Name: my-gitter-ios-app (can be anything)\n Redirect URL: https://gitter.im/login/oauth/callback\n -->\n \u003Ckey>OAuthClientId\u003C/key>\n \u003Cstring>\u003C/string>\n \u003Ckey>OAuthClientSecret\u003C/key>\n \u003Cstring>\u003C/string>\n \u003Ckey>OAuthCallback\u003C/key>\n \u003Cstring>https://gitter.im/login/oauth/callback\u003C/string>\n\u003C/dict>\n\n\u003C/plist>\n\n```\n\n\n[`troupeobjccommon`](https://gitlab.com/gitlab-org/gitter/troupeobjccommon)\nis in Objective-C\n\n\n`TRAppSettings.h`\n\n\n```h\n\n#import \u003CFoundation/Foundation.h>\n\n\n@interface TRAppSettings : NSObject\n\n\n+ (TRAppSettings *) sharedInstance;\n\n\n- (NSString *) clientID;\n\n\n- (NSString *) clientSecret;\n\n\n- (NSString *) oauthScope;\n\n\n@end\n\n```\n\n\n`TRAppSettings.m`\n\n\n```objc\n\n@interface TRAppSettings ()\n\n\n@property (strong, nonatomic) NSUserDefaults *secrets;\n\n\n@end\n\n\nstatic TRAppSettings *sharedAppSettingsSingleton;\n\n\n@implementation TRAppSettings {\n int firstRunPostUpdate;\n}\n\n\n+ (void)initialize\n\n{\n static BOOL initialized = NO;\n if(!initialized)\n {\n initialized = YES;\n sharedAppSettingsSingleton = [[TRAppSettings alloc] init];\n }\n\n NSLog(@\"Pulling secrets from SECRETS_PLIST = %@.plist\", SECRETS_PLIST);\n}\n\n\n+ (TRAppSettings *) sharedInstance\n\n{\n return sharedAppSettingsSingleton;\n}\n\n\n- (id)init {\n NSString *troupeSecretsPath = [[NSBundle mainBundle] pathForResource:\"GitterSecrets-Dev\" ofType:@\"plist\"];\n if(troupeSecretsPath == nil) {\n NSString *failureReason = [NSString stringWithFormat:@\"Gitter secrets file not found in bundle: %@.plist. You probably need to add it to the `Gitter/Supporting Files` in Xcode navigator\", SECRETS_PLIST];\n NSException* exception = [NSException\n exceptionWithName:@\"FileNotFoundException\"\n reason:failureReason\n userInfo:nil];\n\n NSLog(@\"%@\", failureReason);\n\n [exception raise];\n }\n NSDictionary *troupeSecrets = [NSDictionary dictionaryWithContentsOfFile:troupeSecretsPath];\n\n self.secrets = [NSUserDefaults standardUserDefaults];\n [self.secrets registerDefaults:troupeSecrets];\n}\n\n\n- (NSString *) clientID {\n return [self.secrets stringForKey:@\"OAuthClientId\"];\n}\n\n\n- (NSString *) clientSecret {\n return [self.secrets stringForKey:@\"OAuthClientSecret\"];\n}\n\n\n- (NSString *)oauthScope {\n return [self.secrets stringForKey:@\"OAuthCallback\"];\n}\n\n```\n\n\nUsage in the Swift app:\n\n\n```swift\n\nprivate let appSettings = TRAppSettings.sharedInstance()\n\n\nappSettings!.clientID()\n\nappSettings!.clientSecret()\n\nappSettings!.oauthScope()\n\n```\n\n\n### Adding in GitLab CI\n\n\nIf you're interested in setting up automated builds and publish releases to\nthe Apple App Store from GitLab CI, you can learn how [blog post about using\nfastlane](/blog/ios-publishing-with-gitlab-and-fastlane/).\n\n\n### Removing secrets from the repo history\n\n\nWe didn't have a complete picture of what to remove because `truffleHog`\ndidn't work well, so we didn't use BFG Repo-Cleaner. To remove secrets from\nthe git repo history, we just squashed all of the history into a single\ncommit.\n\n\n## Life after open sourcing apps\n\n\nWe have some [thoughts of deprecating the Android/iOS\napps](https://gitlab.com/gitlab-org/gitter/webapp/issues/2281) but the\ncommunity has been great to keep the apps alive so far. We released a couple\nversions of each app including [dark\ntheme](https://gitlab.com/gitlab-org/gitter/gitter-android-app/merge_requests/2)\nand [GitLab\nsign-in](https://gitlab.com/gitlab-org/gitter/gitter-android-app/merge_requests/112)\nfor Android and a bunch of technical debt and fixes for iOS, including\nremoving the deprecated\n[`SlackTextViewController`](https://gitlab.com/gitlab-org/gitter/gitter-ios-app/merge_requests/8)\n(and we are intensely working on incorporating the new\n[`SlackWysiwygInputController`](https://goo.gl/7NDM3x) 😜).\n\n\nThe\n[Android](https://gitlab.com/gitlab-org/gitter/gitter-android-app)/[iOS](https://gitlab.com/gitlab-org/gitter/gitter-ios-app)\napps could benefit from a lot of polish and fixes, so if you see anything\nparticularly annoying, we would love to review and merge your updates!\n\n\nCover image by [Nate Johnston](https://unsplash.com/@natejohnston) on\n[Unsplash](https://unsplash.com/photos/DkCydKeaLV8).\n\n{: .note}\n",[787,9,1285,108],{"slug":3648,"featured":6,"template":698},"open-sourcing-the-gitter-mobile-apps","content:en-us:blog:open-sourcing-the-gitter-mobile-apps.yml","Open Sourcing The Gitter Mobile Apps","en-us/blog/open-sourcing-the-gitter-mobile-apps.yml","en-us/blog/open-sourcing-the-gitter-mobile-apps",{"_path":3654,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3655,"content":3661,"config":3667,"_id":3669,"_type":13,"title":3670,"_source":15,"_file":3671,"_stem":3672,"_extension":18},"/en-us/blog/people-ops-using-gitlab",{"title":3656,"description":3657,"ogTitle":3656,"ogDescription":3657,"noIndex":6,"ogImage":3658,"ogUrl":3659,"ogSiteName":685,"ogType":686,"canonicalUrls":3659,"schema":3660},"GitLab People Ops: Getting drunk on our own wine","How our People Ops team uses GitLab day to day: from onboarding new GitLab team-members to keeping our handbook up to date.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678697/Blog/Hero%20Images/how-people-ops-uses-gitlab.jpg","https://about.gitlab.com/blog/people-ops-using-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab People Ops: Getting drunk on our own wine\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Chloe Whitestone\"}],\n \"datePublished\": \"2018-05-25\",\n }",{"title":3656,"description":3657,"authors":3662,"heroImage":3658,"date":3664,"body":3665,"category":910,"tags":3666},[3663],"Chloe Whitestone","2018-05-25","\nWe’ve heard people say \"[every company is a software company](https://www.forbes.com/sites/techonomy/2011/11/30/now-every-company-is-a-software-company/#5761b57cf3b1),\" but what about the people who work there? At GitLab, we [drink our own wine](/company/culture/), and that means all of our team members, in some way or another, are technical because we use GitLab ourselves. In [People Ops and recruiting](/handbook/people-group/), I use GitLab every day; just take a look at my [activity chart](https://gitlab.com/chloe)!\n\n![Chloe's GitLab Activity Chart](https://about.gitlab.com/images/blogimages/gitlab-chloe.png){: .shadow.medium.center}\n\nThese blue squares represent contributions I’ve made across the GitLab project (and the white ones prove that work/life balance exists!).\n\n## Getting started with issues\n\nA good portion of those blue squares are dedicated towards issues, specifically pre-established template issues, such as [the onboarding issue](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/onboarding.md). This is the \"first look\" our new hires have into GitLab and our workflow, and it’s a fantastic way to get them using issues, and thus GitLab the product, right away. One of the tasks in this issue is \"add yourself to the [team page](/company/team/),\" so within the first week at GitLab, all team members submit a merge request, even if they’ve never coded before. Another task is to \"make an improvement to the handbook,\" which both encourages new hires to submit another merge request and to explore our handbook and adopt our ethos of \"everyone can contribute.\"\n\n>within the first week at GitLab, all team members submit a merge request, even if they’ve never coded before\n\nOther issue templates we have and use regularly are [offboarding](https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/offboarding.md) and [opening new vacancies](https://gitlab.com/gitlab-com/people-ops/vacancy/blob/master/.gitlab/issue_templates/vacancy.md). People Ops uses these issue templates to maintain version control, enable everyone to contribute, and allow us to continually iterate and improve on how we onboard our new hires, all of which promote the GitLab [values](https://handbook.gitlab.com/handbook/values/).\n\nWe constantly iterate on all of our issue templates, predominantly the onboarding issue template mentioned above. You can view its [history](https://gitlab.com/gitlab-com/people-ops/employment/commits/master/.gitlab/issue_templates/onboarding.md) and see how everyone at the company iterates on our onboarding issue – not just People Ops, but also new hires and seasoned GitLab team-members. You can also view some of the ideas we’re working through in the [\"Overhaul onboarding for Ta-NEW-kis\" issue](https://gitlab.com/gitlab-com/people-ops/General/issues/105), and feel free to contribute your own ideas!\n\n## Transparent by default\n\nPeople Ops and HR departments are not typically considered transparent at most companies, but here at GitLab we try our best to be as transparent as possible. The only times we keep things confidential are when we are legally required to, or to protect someone’s privacy. Everything else is fair game! Some great examples in our handbook are our [identity data](/company/culture/inclusion/identity-data/), [internal feedback](/company/culture/internal-feedback/), and the questions we ask in our [screening calls with candidates](/handbook/hiring/interviewing/#screening-call). We make it a point to keep this data, as well as other handbook pages dedicated to People Ops and recruiting, up to date and accurate.\n\n## Everyone can contribute\n\nWe encourage our team members and the wider GitLab community to contribute and give us their ideas because they will have a fresh look and unique perspective, which can only improve our own understanding.\n\nI remember when I joined GitLab a year ago, I interviewed with [Sid Sijbrandij](/company/team/#sytses), our CEO, and he asked me what I wanted to accomplish within my first month at GitLab. I told him I wanted to become proficient in Git so that I could properly contribute, and he was surprised! But I was steadfast, and within my first two weeks, I’d already started contributing via my local machine. Sure, I’m not a developer by any means, but I use Git every day, have figured out quite a few things both on my own, and with the help of our #git-help Slack channel, was even granted merge powers last year! Here at GitLab, everyone can contribute, no matter what your background is.\n\nPhoto by [Maxime Le Conte des Floris](https://unsplash.com/) on Unsplash\n{: .note}\n",[934,9,912],{"slug":3668,"featured":6,"template":698},"people-ops-using-gitlab","content:en-us:blog:people-ops-using-gitlab.yml","People Ops Using Gitlab","en-us/blog/people-ops-using-gitlab.yml","en-us/blog/people-ops-using-gitlab",{"_path":3674,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3675,"content":3681,"config":3688,"_id":3690,"_type":13,"title":3691,"_source":15,"_file":3692,"_stem":3693,"_extension":18},"/en-us/blog/pick-your-brain-interview-kwan-lee",{"title":3676,"description":3677,"ogTitle":3676,"ogDescription":3677,"noIndex":6,"ogImage":3678,"ogUrl":3679,"ogSiteName":685,"ogType":686,"canonicalUrls":3679,"schema":3680},"GitLab CEO interview: Building the best distributed Dev team","FineTune CTO Kwan Lee sits down for a 'pick your brain' meeting with GitLab CEO Sid Sijbrandij.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680355/Blog/Hero%20Images/pyb-kwan-lee.jpg","https://about.gitlab.com/blog/pick-your-brain-interview-kwan-lee","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to become the best distributed software development team? My interview with GitLab's CEO\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Kwan Lee\"}],\n \"datePublished\": \"2017-09-15\",\n }",{"title":3682,"description":3677,"authors":3683,"heroImage":3678,"date":3685,"body":3686,"category":910,"tags":3687},"How to become the best distributed software development team? My interview with GitLab's CEO",[3684],"Kwan Lee","2017-09-15","\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab._\n\nIt was great to find the time for us to pick Sid’s brain and learn from the history and the organizational challenges that GitLab had overcome so that we may reference them for building a better organization. There were some cultural elements, tactical organizational elements and software development process-related elements that were valuable pointers.\n\n\u003C!-- more -->\n\n## Lessons in remote work\n\nHaving 178 people in 38 countries was quite an impressive distribution of employees across different geographies. Sponsoring travel to work with fellow members of the company was a great program that they have to bridge the distributed nature of the company. We are also a very distributed company and we want to grow a company where a distributed team can scale and collaborate actively while continuously increasing the motivation to build higher quality software at higher velocity for our customers.\n\nOne of the challenges of being remote is that, although we are part of one company, it is tricky for us to interact in a casual manner as we do in a physical co-working environment. GitLab promotes virtual coffee breaks and all-team meetings to promote these. People can arrange coffee breaks with others at their will to catch up. During all-team meetings, they go around introducing personal updates about themselves. The team being remote requires everybody to still feel part of one company. In order to feel part of the company, it requires participation from everybody and their willingness to share their personal lives.\n\n>In order to feel part of the company, it requires participation from everybody and their willingness to share their personal lives.\n\nAt [FineTune](https://www.finetunelearning.com/), we are not used to taking coffee breaks during the day with coworkers, but we try to have regular meetings where we try to catch up personally for the first five minutes. Our weekly company meetings have been a little bit informal and did not give opportunity for each of the members to speak. We plan to keep encouraging people to share more as we want to grow a culture of sharing more as we grow and scale.\n\nSid also described various rooms for social interaction in the company. Some more interesting venues for social interaction that were suggested by Sid were:\n\n* Team call four times a week (20 minutes)\n* Summit: every nine months they fly everybody to one place, for interactions that are less organized with scheduled activities and forbidden to have team meetings ('unconference')\n* Asynchronous discussions via merge requests, while they sometimes get on video call to summarize what has been concluded or decided\n\nWriting things down is important due to the remote nature of the company. We have been pretty bad at keeping consistent standards on documentation and keeping them up to date. It also hinders communication flow, making it difficult to discover and share knowledge when we do not have such consistency. We are working on ways to improve this nowadays.\n\n>Writing things down is important due to the remote nature of the company\n\n## Lessons in organization\n\nWhen it comes to organization and growth, what we got most out of it was that we need to find the gaps in our team and try to fill in those parts we lack when we hire new members. Currently, we have a gap in frontend tech lead, and by thinking through what gaps exist in our development and future of our company we found that we would like to find a tech lead who has extensive experience modularizing frontend software components and has worked with complex microservice APIs that would facilitate the flow of communication between frontend and backend members.\n\nSome other organizational lessons learned from growing from 15 to 50 was that:\n* Sid was the only Sales (non-development) team member\n* Get things done on time and having well defined tasks are very important\n* One boss to give approvals\n* No project managers\n\nWe want to organize ourselves so that we are making decisions quickly and moving fast. I believe that as long as the priority framework for decision-making is clear, everybody should feel free to make the decisions that move the company forward.\n\n## Lessons in the development process\n\nIn terms of development process, we realized we needed to shorten the time to release and try to keep shipping. Importance of fast iteration was emphasized by Sid and shipping fast by cutting scope. We should not fall into the trap of building the car and not shipping when the bicycle is ready. We also need more discipline to maintain good, coherent design documentations that allows us to be all on the same page.\n\nIt was interesting to see the scale of work that the distributed team worked on. When a new sprint starts, product and UX team already had designed and product team had schedules for release. Ad hoc dev teams get formed for big features (every release has around five big features and 100s of small issues), making a chat channel, discussing issue descriptions, figuring out when you hand off from backend to the frontend team.\n\n>\"always finish the flow first\"\n\nGitLab's approach of \"always finish the flow first\" (breadth vs depth) to take care of coordination resonated strongly since that involves more people and requires people to be on the same page to further dive in deeper. Also, the \"building better a experience\" and \"releasing a more integrated experience\" brings a lot of emergent benefits.\n\nSome mistakes seen were people having hard time iterating and sometimes over engineering implementation which risks release deadline. Everyone can contribute, but at the end person doing the work makes the decision.\n\n## Lessons in leadership\n\nAs a final question, we asked what prevents a software company from growing. The answer we got was the lack of ambition. We as the founders or development team may not be as ambitious as we should be. Our company has been in the ed tech industry for 10 years and had not seen much growth. What we realized was that our goals and bars were set too low. We have a lot of strong design and engineering capability that we have built up over the last six months and now it is our time to think and act with more ambitious goals. There is a lot of value in helping people to write better and measure the quality of written content since most communication nowadays is done via writing.\n\nWe want to become an important company that helps with not only K-12, higher-ed education in EdTech industry, but also with professional development and employability across any industry that requires written communication to succeed. We have a long way to go, but the invaluable discussion we had with Sid informed us some of the good practices to follow and a trajectory to aim for around our next growth path.\n\n[Cover image](https://unsplash.com/@blakeconnally?photo=B3l0g6HLxr8) by [Blake Connally](https://unsplash.com/@blakeconnally) on Unsplash\n{: .note}\n",[3045,1097,9],{"slug":3689,"featured":6,"template":698},"pick-your-brain-interview-kwan-lee","content:en-us:blog:pick-your-brain-interview-kwan-lee.yml","Pick Your Brain Interview Kwan Lee","en-us/blog/pick-your-brain-interview-kwan-lee.yml","en-us/blog/pick-your-brain-interview-kwan-lee",{"_path":3695,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3696,"content":3702,"config":3710,"_id":3712,"_type":13,"title":3713,"_source":15,"_file":3714,"_stem":3715,"_extension":18},"/en-us/blog/play-reviewer-roulette",{"title":3697,"description":3698,"ogTitle":3697,"ogDescription":3698,"noIndex":6,"ogImage":3699,"ogUrl":3700,"ogSiteName":685,"ogType":686,"canonicalUrls":3700,"schema":3701},"Reviewer roulette: Easy way to find merge request reviewers","Finding the right reviewer for a merge request can be tough. Reviewer Roulette makes the decision easier – by making it random!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672195/Blog/Hero%20Images/play-reviewer-roulette.jpg","https://about.gitlab.com/blog/play-reviewer-roulette","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Let's play Reviewer Roulette! An easy way to find a reviewer for your merge request\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Dennis Tang\"}],\n \"datePublished\": \"2018-06-28\",\n }",{"title":3703,"description":3698,"authors":3704,"heroImage":3699,"date":3706,"body":3707,"category":1053,"tags":3708},"Let's play Reviewer Roulette! An easy way to find a reviewer for your merge request",[3705],"Dennis Tang","2018-06-28","\n\nGitLab is [growing quickly], and [constantly looking for more talented people] to join the team. While exciting, it can be tough to keep track of who's who, especially when you're new to the company.\n\nSo how do you know who to contact if you need a pair of eyes on your merge request?\n\n## Meet Reviewer Roulette!\n\nReviewer Roulette is a Slack slash command to help GitLab team-members randomly select a person from a given team, which can be especially useful as multiple teams work together to deliver features in a single merge request.\n\n![Demo of /reviewerroulette](https://about.gitlab.com/images/blogimages/play-reviewer-roulette/demo.gif){: .shadow.center.medium}\n\n---\n\n## The idea\n\nIt's quite common to find that your issue or merge request will have multiple labels to associate different feature areas and teams that are contributing to them. As someone who's recently joined GitLab, I'm still getting to know [all the different teams and people] that work at GitLab. That said, I'm working on a feature with the [CI/CD](/topics/ci-cd/) or discussion team, who should I reach out to if I have questions or need a review of my work?\n\n![Various labels on Merge Requests in gitlab-ce](https://about.gitlab.com/images/blogimages/play-reviewer-roulette/labels.png){: .shadow.center.medium}\n\nThe idea arose from the [frontend team weekly call] where [Tim Zallmann] reminded us that, \"Everyone on the frontend team is a reviewer.\" The team previously had a microservice built by [Luke Bennett] for this, however, it's no longer online. Beyond that, wouldn't it be convenient to simply type a command in Slack to be suggested someone to ping for a review?\n\nI can say with confidence that GitLab is a company that truly exemplifies its values, and I was empowered by the value of [collaboration] to build something that could help our team (and others!) find reviewers. I couldn't be the only one who had this problem!\n\n> **Do it yourself** Our collaboration value is about helping each other when we have questions, need critique, or need help. No need to brainstorm, wait for consensus, or do with two what you can do yourself.\n\nI quickly went to work to (hastily) put together a proof-of-concept to see if it would something that people would want to use.\n\n## Decision fatigue, be gone!\n\n![Screenshot of /reviewerroulette](https://about.gitlab.com/images/blogimages/play-reviewer-roulette/screenshot.png){: .shadow.right.small.wrap-text}\n\nIt was presented to the frontend team and received warmly, and many people were keen to contribute and also [suggest ideas] that would make it even more useful!\n\nAlthough it was originally intended for the frontend group, since I was building it from scratch, it was very easy to make the decision to have it work for all engineering teams.\n\nWith Reviewer Roulette, I don't have to ping entire Slack channels or guess from our team page to try to find _someone_ to talk to.\n\nAdditionally, it provides a number of other benefits such as:\n\n1. It promotes a more balanced distribution of reviewers amongst the team.\n * Less experienced reviewers have more opportunities to do code reviews\n * More experienced reviewers are not as heavily relied on\n1. It allows more team members to learn more about parts of the codebase they may not be as familiar with, increasing the knowledge of the team overall\n1. It provides more opportunities to apply our [code review guidelines] or [frontend style guides] to all team members\n1. It reduces bias towards reviewers that you may unconsciously prefer to select\n\nOf course, we have our various subject matter experts such as our [frontend domain experts] and [gitlab-ce maintainers] who may provide the best insight for a given topic, but it's good to randomly select reviewers by default!\n\n## How it's made\n\nWhen it came to thinking about how to build Reviewer Roulette, it wasn't so much about the tech, than it being about being enabled to create something that will benefit the team.\n\nEmbracing our value of [efficiency], the solution is very much a boring one. It's a simple Node.js application utilizing `js-yaml` and `express` to be able to search our [team structure file] and respond to Slack's slash command requests properly.\n\n## What's next\n\nReviewer Roulette is seeing regular usage, and has [plenty of features planned] to hopefully increase its usefulness.\n\nWhile originally intended for engineering, it can [help the entire company] out. In addition to our [Coffee Break calls], we also have [a step in our onboarding process] to meet five different people across different teams and countries. That's something that Reviewer Roulette could easily help with!\n\nWe also plan on moving it to the frontend [GKE] cluster, and activating [Auto DevOps] to make builds and deployments painless.\n\nIf you're interested in checking it out, feel free to take a look at the [project]! Perhaps it might be useful to you and your team?\n\n## Share your thoughts!\n\nIf there's interest in using Reviewer Roulette for your community contribution to GitLab projects, let us know in the comments and we can release it on Slack for everyone to use!\n\nWhat do you think of Reviewer Roulette? Is this something you would use for your team? How do you pick people for reviewing?\n\n[Photo](https://unsplash.com/photos/w6OniVDCfn0?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by Krissia Cruz on [Unsplash](https://unsplash.com/search/photos/roulette?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n\n[growing quickly]: /company/okrs/#ceo-great-team-active-recruiting-for-all-vacancies-number-of-diverse-per-vacancy-real-time-dashboard\n[constantly looking for more talented people]: /jobs/\n[all the different teams and people]: /company/team/\n[frontend domain experts]: /handbook/engineering/frontend/#frontend-domain-experts\n[gitlab-ce maintainers]: /handbook/engineering/projects/#gitlab-ce\n[frontend team weekly call]: /handbook/engineering/frontend/#frontend-group-calls\n[Tim Zallmann]: /company/team/#tpmtim\n[Luke Bennett]: /company/team/#__lukebennett\n[suggest ideas]: https://gitlab.com/dennis/reviewer-roulette/issues/\n[plenty of features planned]: https://gitlab.com/dennis/reviewer-roulette/issues/\n[efficiency]: https://handbook.gitlab.com/handbook/values/#efficiency\n[team structure file]: https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml\n[auto devops]: https://docs.gitlab.com/ee/topics/autodevops/\n[coffee break calls]: /company/culture/all-remote/tips/#coffee-chats\n[a step in our onboarding process]: https://gitlab.com/gitlab-com/people-group/employment-templates/-/blob/main/.gitlab/issue_templates/onboarding.md#day-4-morning-social\n[help the entire company]: https://gitlab.com/dennis/reviewer-roulette/issues/12\n[gke]: /partners/technology-partners/google-cloud-platform/\n[project]: https://gitlab.com/dennis/reviewer-roulette/\n[collaboration]: https://handbook.gitlab.com/handbook/values/#collaboration\n[code review guidelines]: https://docs.gitlab.com/ee/development/code_review.html\n[Frontend style guides]: https://docs.gitlab.com/ee/development/fe_guide/index.html#style-guides\n",[934,9,3709],"frontend",{"slug":3711,"featured":6,"template":698},"play-reviewer-roulette","content:en-us:blog:play-reviewer-roulette.yml","Play Reviewer Roulette","en-us/blog/play-reviewer-roulette.yml","en-us/blog/play-reviewer-roulette",{"_path":3717,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3718,"content":3724,"config":3729,"_id":3731,"_type":13,"title":3732,"_source":15,"_file":3733,"_stem":3734,"_extension":18},"/en-us/blog/power-of-iteration",{"title":3719,"description":3720,"ogTitle":3719,"ogDescription":3720,"noIndex":6,"ogImage":3721,"ogUrl":3722,"ogSiteName":685,"ogType":686,"canonicalUrls":3722,"schema":3723},"How iteration helps build our product and improve our work lives","One of GitLab’s core values, iteration permeates everything we do from UX design to product development. And when it comes to our work lives, iteration is a game changer.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681060/Blog/Hero%20Images/iteration.jpg","https://about.gitlab.com/blog/power-of-iteration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How iteration helps build our product and improve our work lives\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2020-02-04\",\n }",{"title":3719,"description":3720,"authors":3725,"heroImage":3721,"date":3726,"body":3727,"category":910,"tags":3728},[846],"2020-02-04","\n\n*it-er-a-tion*\n\n_/ˌidəˈrāSH(ə)n/_\n\n_noun_\n\n_the repetition of a process or utterance._\n\n_repetition of a mathematical or computational procedure applied to the result of a previous application, typically as a means of obtaining successively closer approximations to the solution of a problem._ – Oxford Dictionary via Lexico\n\nAt GitLab iteration is simply what we do – with everything. CEO [Sid Sijbrandij](/company/team/#sytses) explains that even in the very early stages of GitLab, when the company was in the [Y Combinator](https://www.ycombinator.com) \"incubator,” he knew iteration was the right choice because even though it seems contradictory, you can go faster by breaking things down into smaller pieces. \"There were people, even at the time, who suggested that we should slow down. The response from GitLab has always been, 'No, we'll get the most we can get done. The smaller we split things up, the smaller the steps we take, the faster we can go.'\"\n\nIt’s not surprising that iteration is one of GitLab’s [six core values](https://handbook.gitlab.com/handbook/values/), and you don’t have to look too closely to see how it steers our product development. When we wanted to make our [error tracking feature](/blog/iteration-on-error-tracking/) stronger, we \"scoped” the project down and made small changes more quickly.\n\nOur user experience team took the same approach when [trying to improve usability](/blog/how-ux-research-impacts-product-decisions/), and [when we migrated](/blog/gitlab-journey-from-azure-to-gcp/) from Microsoft’s Azure to the Google Cloud Platform we used iteration to guide our process.\n\nBut perhaps where iteration shines brightest at GitLab is at the individual level where the ability to take small steps frees employees to take risks and be creative. This is something that’s obvious even if you’re a [brand new employee](/blog/agile-iteration-unique-onboarding-experience/).\n\nWe asked six team members to explain the impact of iteration on their work lives.\n\n[Heather Simpson](/company/team/#hsimpson), senior external communications analyst:\n\"Honestly, the ability to throw something out there without being judged because it’s not completely formed and polished is new and refreshing for me. I know I’ve got teammates ready to collaborate and help me strengthen my ideas and the end result.”\n\n[Ashish Kuthiala](/company/team/#kuthiala), senior director of Product Marketing:\n\"It helps us create a culture and organization that learns very fast and creates a self-learning and always improving organization. We cannot and do not always get things right but we learn and improve really rapidly.”\n\n[Emily Kyle](/company/team/#Emily), manager, Corporate Events and Branding:\n\"It allows me to be a bit bolder and braver in coming up with out of the box solutions and in my decision making. Small steps make change so much easier to achieve.”\n\n[Tina Sturgis](/company/team/#TinaS), manager, Partner and Channel Marketing:\n\"Iteration for me is a game changer at GitLab. Gone are the days of getting everyone's buy-in prior to rolling out messaging. Put it out there and people will iterate on it making it better. If my messaging was off, no worries – iterate on what it is NOT and keep driving to results.\"\n\n[Lorie Whitaker](/company/team/#loriewhitaker), senior UX researcher: \"To a UX researcher iteration means something different to me than other people. The value of iteration should encourage people to change directions when they find answers to their questions. Iteration should be a stop-gap measure to say ‘This is not the right solution. We will stop and reassess and rethink what is the right solution to this problem.’”\n\n[Lee Matos](/company/team/#lbot), Support engineering manager:\n\"Iteration is hard because at first it feels unnatural, but once you learn how to really iterate, it's liberating. You can keep being nimble which is huge.\"\n\nCover image by Eryk on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[9,934,737],{"slug":3730,"featured":6,"template":698},"power-of-iteration","content:en-us:blog:power-of-iteration.yml","Power Of Iteration","en-us/blog/power-of-iteration.yml","en-us/blog/power-of-iteration",{"_path":3736,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3737,"content":3742,"config":3747,"_id":3749,"_type":13,"title":3750,"_source":15,"_file":3751,"_stem":3752,"_extension":18},"/en-us/blog/project-management-using-gitlab-platform",{"title":3738,"description":3739,"ogTitle":3738,"ogDescription":3739,"noIndex":6,"ogImage":2257,"ogUrl":3740,"ogSiteName":685,"ogType":686,"canonicalUrls":3740,"schema":3741},"Can DevOps and project management co-exist? Yes, on the daily at GitLab","Stay agile by using GitLab for DevOps project management","https://about.gitlab.com/blog/project-management-using-gitlab-platform","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Can DevOps and project management co-exist? Yes, on the daily at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vick Kelkar\"}],\n \"datePublished\": \"2021-05-11\",\n }",{"title":3738,"description":3739,"authors":3743,"heroImage":2257,"date":3744,"body":3745,"category":1053,"tags":3746},[907],"2021-05-11","\n\nGitLab is best known as an all-in-one DevOps platform, but it is also an effective tool for project management. Non-technical teams at GitLab, such as [the Marketing team](/blog/gitlab-for-project-management-one/), use the GitLab DevOps platform for project management, and recently the Alliances team learned that DevOps and project management work well for our purposes.\n\n## About the IBM partnership\n\n[GitLab recently launched a partnership with IBM](/press/releases/2021-01-14-gitlab-IBM-to-support-acceleration-of-devops-automation.html) to help the organization automate their DevOps platform. Since I work on the Alliances team, I needed an efficient, compatible, and high-performance project management application to manage the many moving parts of the GitLab and IBM partnership as well as other projects related to our partnerships.\n\nMy very first instinct was to test a few of the project management web applications on the market, but this would involve a tedious process of convincing my colleagues to join me on this journey to explore a sprawling new set of tools. Then I thought why not explore our own Gitlab DevOps platform as a project management tool? The beauty of GitLab is that it is a [DevOps platform](https://www.youtube.com/watch?v=wChaqniv3HI) delivered as a single easy-to-use application.\n\nSome of my early questions were:\n\n- Can the GitLab DevOps platform work as a project management tool for the strategic Alliance team?\n- Can GitLab manage and track business activities over a period of time?\n- Can team members collaborate and manage various projects using a single application?\n\nIn the end, the journey to adopting GitLab as a DevOps platform and project management tool was similar to the journey many of our customers experience. In this blog post, I will dive deeper into how the Alliance team uses GitLab for project management, explain how we used GitLab to onboard a new strategic partner, and launched support of [GitLab Ultimate for IBM Cloud Paks](https://www.ibm.com/products/gitlab-ultimate). All the pre- and post-onboarding activities in particular required collaboration and contributions from various teams across the organization.\n\n## Applying DevOps features to project management\n\n### About epics and roadmaps\n\nWhy organize work into a hierarchy? I began the strategic partnership effort by organizing the work into multi-level epics. The [idea behind epics is to aggregate similar work](https://docs.gitlab.com/ee/user/group/epics/#epics) (or issues) into epics and manage delivery of work. In the example below, you'll see the top-level epic was called \"IBM cloud paks\" which contained three child epics.\n\n![An example of a multi-level epics from the IBM cloud paks project](https://about.gitlab.com/images/blogimages/proj-mgmt-epic.png){: .shadow.medium.center}\nWork is divided into three time-bound levels for the IBM cloud paks project: Pre-launch, 0-90 days, and 90-180 days.\n{: .note.text-center}\n\nAnother way to represent the epics is through a [roadmap view](https://docs.gitlab.com/ee/user/group/roadmap/#roadmap). The main advantage of this feature is that it allows the collaborators on epics and issues to monitor project progress using a calendar timeline view.\n\n![An example of a project management timeline for the IBM cloud paks project using the epics roadmap view](https://about.gitlab.com/images/blogimages/proj-mgmt-timeline.png){: .shadow.medium.center}\nThe same IBM cloud paks project epic is depicted using the Roadmap view, which adopts a timeline view.\n{: .note.text-center}\n\n### How issues are used to capture work\n\nClick into any of the epics to find a set of issues that make up the epic. I use [issues as the basic unit of work](https://docs.gitlab.com/ee/user/project/issues/). Contained within the \"IBM cloud paks: Pre-launch\" epic are 33 issues.\n\n![The list view shows inside the \"IBM cloud paks: Pre-launch\" epic are 33 issues](https://about.gitlab.com/images/blogimages/proj-mgmt-issue.png){: .shadow.medium.center}\nInside the \"IBM cloud paks: Pre-launch\" epic are 33 issues\n{: .note.text-center}\n\nOne thing to note is that an issue can have a single assignee or owner, or it can have multiple assignees.\n\n### How to use issue boards\n\nAn [agile board](/blog/gitlab-for-agile-portfolio-planning-project-management/) can help a user visualize work and manage all the open threads in a given epic and/or project. The board can help you move issues efficiently through various phases of work. On the Alliances team, we are always iterating on how to better track the status of issues. [Here is more information about the current status flows for the Alliances team](/handbook/alliances/#status-alliance---status--status).\n\nThe screenshot below shows how an [issue board can be applied as a Kanban board by filtering for the \"IBM\" label](https://docs.gitlab.com/ee/user/project/issue_board.html#issue-boards). To see transitions between work stages, use [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels), which are mutually exclusive and represent transitions between various workflow statuses, such as \"status::1\" and \"status::2\"\n\n![Kanban board showing how labels can be used to organize issues into work stages](https://about.gitlab.com/images/blogimages/proj-mgmt-board.png){: .shadow.medium.center}\nHow we use boards for the IBM cloud paks project.\n{: .note.text-center}\n\n### Milestones help time-box events\n\nWhile an epic is a collection of related issues, [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), and sub-epics and is generally used to scope a long-running initiative or program (e.g., a marketing campaign or a new product category) epics can also contain smaller, more discrete and timeboxed events, such as monthly releases or calendar quarters. These [timeboxes are represented as Milestones](https://docs.gitlab.com/ee/user/project/milestones/), which roll up issues and merge requests in the same way as higher-level epics. Apply the \"Milestone view\" to track progress on the smaller deliverables within an epic.\n\n![Milestone view showing Alliances team projects](https://about.gitlab.com/images/blogimages/proj-mgmt-milestone.png){: .shadow.medium.center}\nHow milestones can be used to track work progress within a specific time frame.\n{: .note.text-center}\n\n### How Milestone burnup and burndown charts chart progress\n\n[Burnup and burndown charts are used by project managers to measure progress](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html). Burndown charts analyze how much work is left in a project before it can be finished successfully. Burnup charts measure the work that has been done against the total work for the project. Both types of charts are available in the GitLab DevOps platform. I relied mostly on epics and milestones to track work progress for the IBM partnership.\n\n![burndown](https://about.gitlab.com/images/blogimages/proj-mgmt-burndown.png){: .shadow.medium.center}\nThe burdown and burnup charts for the IBM cloud paks partnership project.\n{: .note.text-center}\n\n### Inside analytics and insights project management tools\n\nMost project management tools are great at capturing project details, and can help answer questions such as \"where does the project stand on actual vs. planned activities?\" or can help track progress using milestones and due dates. [Project analytics and insights dashboards](https://docs.gitlab.com/ee/user/analytics/#project-level-analytics) are built into the GitLab DevOps platform. There are many built-in analytics dashboards, such as CI/CD, code review, merge requests, and issues. For the IBM partnership project, I used the [issues dashboard analytics](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html) to see how many issues were opened compared to how many issues were closed. This tool helped me manage the team capacity and identify any bottlenecks in the project.\n\n![The insights dashboard shows how many issues were opened and closed](https://about.gitlab.com/images/blogimages/proj-mgmt-insights.png){: .shadow.medium.center}\nThe insights dashboard shows many issues were opened vs. how many issues were closed each month.\n{: .note.text-center}\n\n[Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) is a particularly unique feature of GitLab's analytics suite. Since GitLab is a complete DevOps platform with a single data store, GitLab can automatically generate reports to not only identify high-level metrics and blockers, but also drill down into those blockers and improve value flow with just a few clicks.\n\n![Showing recent project activity: 32 new issues and 19 commits](https://about.gitlab.com/images/blogimages/proj-mgmt-analysis.png){: .shadow.medium.center}\nAnalytics showing recent project activity.\n{: .note.text-center}\n\nThe Value Stream Analytics provides a high-level view into common stages of the SDLC out-of-the-box, making it easier to monitor the overall workflow from discussion to code changes, through review and collaboration, and out to production – with no additional work required. And since the code changes and collaboration are happening within GitLab, just one click on an item will take you to the blocked issue or merge request, so you can comment, reassign, or contribute to move things along.\n\nSince all the necessary data is already in GitLab's system, customizing Value Stream Analytics can be completed in just a few clicks: Hiding and reordering stages and even creating your own with simple drop-down menus.\n\n![The customized value stream shows the average amount of time spent in the selected stage for each item](https://about.gitlab.com/images/blogimages/proj-mgmt-valuestream.png){: .shadow.medium.center}\nThe custom value stream above shows the number of days to completion.\n{: .note.text-center}\n\n## DevOps platform and project management in one\n\nThere are many project management tools in the marketplace and solutions for managing the SDLC of a project. The GitLab DevOps platform and project management tool satisfied my need to track partnership-related activities while also managing the technical demos and workshops developed for the IBM partnership. I look forward to continuing to explore the constantly-evolving GitLab platform to grow and manage our strategic partnerships on the Alliances team.\n\nCover image by [Martin Sanchez](https://unsplash.com/@martinsanchez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/MD6E2Sv__iA)\n{: .note.text-center}\n",[891,9,829,1097,912],{"slug":3748,"featured":6,"template":698},"project-management-using-gitlab-platform","content:en-us:blog:project-management-using-gitlab-platform.yml","Project Management Using Gitlab Platform","en-us/blog/project-management-using-gitlab-platform.yml","en-us/blog/project-management-using-gitlab-platform",{"_path":3754,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3755,"content":3760,"config":3765,"_id":3767,"_type":13,"title":3768,"_source":15,"_file":3769,"_stem":3770,"_extension":18},"/en-us/blog/q1-hackathon-announcement",{"title":3756,"description":3757,"ogTitle":3756,"ogDescription":3757,"noIndex":6,"ogImage":1462,"ogUrl":3758,"ogSiteName":685,"ogType":686,"canonicalUrls":3758,"schema":3759},"Get ready for the Q1'2019 GitLab Hackathon","The first Hackathon in 2019 for the GitLab community will take place on February 12-13.","https://about.gitlab.com/blog/q1-hackathon-announcement","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Get ready for the Q1'2019 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-01-14\",\n }",{"title":3756,"description":3757,"authors":3761,"heroImage":1462,"date":3762,"body":3763,"category":784,"tags":3764},[1281],"2019-01-14","\n\nFirst of all, I want to wish a Happy New Year to everyone in the GitLab community! I'm certainly looking forward to continued collaboration with everyone in 2019. Following successful [Hackathons in 2018](/community/hackathon/past-events/), I'm excited to announce that the first Hackathon this year will take place on Feb. 12-13.\n\n## What's the deal?\n\nThis is a virtual event where community members get together to work on merge requests (MRs) and also to welcome and help new contributors. We will be adding more details on [the Hackathon landing page](/community/hackathon/), as we get closer to the event, including prizes for everyone who has MRs merged within 10 days of the conclusion of the Hackathon.\n\n## What else is taking place?\n\nWe are again planning tutorial sessions where community experts will lead presentations plus Q&A sessions on a variety of topics. As speakers get confirmed, you will see tutorial sessions added on [the Hackathon landing page](/community/hackathon/). All the tutorial sessions will be recorded and added to the [GitLab Hackathon playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh). If you missed tutorials from past Hackathons, I encourage you to check out videos from the playlist.\n\n![Hackthon playlist](https://about.gitlab.com/images/blogimages/hackathon-playlist.png){: .shadow.medium.center}\n*\u003Csmall>Tutorial videos on the Hackathon playlist\u003C/small>*\n\nFor the upcoming Hackathon, we will also be highlighting issues from different [GitLab product categories](https://handbook.gitlab.com/handbook/product/categories/) that we want to encourage community members to work on. There will be additional prizes for community members who work on these issues and have MRs merged.\n\n## Where can I find help during the Hackathon?\n\nFor communications during the Hackathon, we will again use the [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community). This is a channel designed to have community-related discussions and for community members to help each other as people have questions when contributing to GitLab. This is open to everyone, so please [join the room](https://gitter.im/gitlabhq/community) if you are not part of it already.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel)\n{: .note}\n",[268,9,787,278],{"slug":3766,"featured":6,"template":698},"q1-hackathon-announcement","content:en-us:blog:q1-hackathon-announcement.yml","Q1 Hackathon Announcement","en-us/blog/q1-hackathon-announcement.yml","en-us/blog/q1-hackathon-announcement",{"_path":3772,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3773,"content":3778,"config":3783,"_id":3785,"_type":13,"title":3786,"_source":15,"_file":3787,"_stem":3788,"_extension":18},"/en-us/blog/q1-hackathon-recap",{"title":3774,"description":3775,"ogTitle":3774,"ogDescription":3775,"noIndex":6,"ogImage":1462,"ogUrl":3776,"ogSiteName":685,"ogType":686,"canonicalUrls":3776,"schema":3777},"What went down at the Q1'2020 GitLab Hackathon","A recap of GitLab community's accomplishments during another record-setting Hackathon on February 12-13.","https://about.gitlab.com/blog/q1-hackathon-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What went down at the Q1'2020 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2020-03-25\",\n }",{"title":3774,"description":3775,"authors":3779,"heroImage":1462,"date":3780,"body":3781,"category":716,"tags":3782},[1281],"2020-03-25","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nThe GitLab community gathered on February 12-13 for the Q1 Hackathon and this is almost becoming a cliche, but the GitLab Community again set an impressive Hackathon record with [almost 150 MRs](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/31)!\n\n## What did we accomplish?\n\nI'm not sure how many readers remember the first Hackathon in Q3'2018, but I remember being excited about [22 MRs](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/4) submitted during the inaugural event. If someone told me we would see 147 MRs in a single Hackathon someday, I don't think I would have believed it. Again, I have to give big kudos to wider community members and reviewers who helped make our Hackathon such a fun and exciting event. \n\nI would like to highlight a few things from the Hackathon. First, just like in Q4 we had frontend Epics that resulted in many community contributions. One was [Replacing Underscore with Lodash](https://gitlab.com/groups/gitlab-org/-/epics/2412) created by [Scott Stern](https://gitlab.com/sstern) and the other was to [Migrate .fa-spinner to .spinner](https://gitlab.com/groups/gitlab-org/-/epics/956) that was created by [Brandon Labuschagne](https://gitlab.com/blabuschagne) before the Hackathon. Amazingly, both Scott and Brandon were able to review and provide feedback on over 50 MRs related to these Epics that turned out to be goldmines. \n\nAlso during this Hackathon, there were MRs across more than 20 GitLab projects demonstrating the breadth of contributions (to go along with the volume). Not suprisingly, many people usually think of the [`gitlab` project](https://gitlab.com/gitlab-org/gitlab), but wider community members contributed to projects like [Charts](https://gitlab.com/gitlab-org/charts/gitlab), [Gitaly](https://gitlab.com/gitlab-org/gitaly/), [GitLab SVGs](https://gitlab.com/gitlab-org/gitlab-svgs), [Gitter](https://gitlab.com/gitlab-org/gitter), [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/), [Pajama Design System](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/), [Runner](https://gitlab.com/gitlab-org/gitlab-runner/), [Secure](https://gitlab.com/gitlab-org/security-products), [www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com), and others during the event. \n\nFinally, the [GitLab Meetup Group in Hamburg](https://www.meetup.com/GitLab-Meetup-Hamburg/) had their [meetup](https://www.meetup.com/GitLab-Meetup-Hamburg/events/268054258/) to coincide with the Hackathon, so [David Planella](https://gitlab.com/dplanella), [John Coghlan](https://gitlab.com/johncoghlan), and [I](https://gitlab.com/rpaik) were able to join the Hamburg meetup remotely to talk about the Hackathon and how to contribute to GitLab. We had a great time participating in the meetup and I want to thank [Philipp Westphalen](https://gitlab.com/Phil404) for not only inviting us, but also flawlessly working the conferencing tool and the audio/video equipments. If there are other GitLab meetup organizers who are interested in organizing your meetup around a Hackathon, please let me know! \n\n![Hamburg meetup](https://about.gitlab.com/images/blogimages/hackathon-blogpost/Hamburg-meetup.png){: .shadow.medium.center}\n\n## Hackathon prizes\n\nFor this Hackathon, we have a packable duffle for everyone who had their MRs merged by February 25th and [34 people](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/33) will be receiving the GitLab branded duffle bag. This sets another record for the number of people with MRs merged during the Hackathon. As we did in the past several quarters, we have a prize for second place and [Raihan Kabir](https://gitlab.com/rk4bir) is the winner with 7 MRs merged. For the grand prize, I want to award two contributors [Takuya Noguchi](https://gitlab.com/tnir) with 13 MRs merged and [Rajendra Kadam](https://gitlab.com/raju249) with 17 MRs merged. Thanks and congratulatations to everyone!\n\n![Hackathon prizes](https://about.gitlab.com/images/blogimages/hackathon-blogpost/q12020-hackathon.prizes.png){: .shadow.medium.center}\n\n## When is the next Hackathon?\n\nI'm happy to announce that the Q2 Hackathon will take place on May 13-14, 2020. It is already advertised on [the Hackathon page](/community/hackathon/) with a new countdown clock. Please look out for more announcements as we get closer to the next Hackathon date. Also, if you have any suggestions for the Q2 Hackathon please feel free to suggest them on [the GitLab Contributors Gitter](https://gitter.im/gitlabhq/contributors).\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at `rpaik@gitlab.com`.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,9,787],{"slug":3784,"featured":6,"template":698},"q1-hackathon-recap","content:en-us:blog:q1-hackathon-recap.yml","Q1 Hackathon Recap","en-us/blog/q1-hackathon-recap.yml","en-us/blog/q1-hackathon-recap",{"_path":3790,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3791,"content":3796,"config":3801,"_id":3803,"_type":13,"title":3804,"_source":15,"_file":3805,"_stem":3806,"_extension":18},"/en-us/blog/q2-hackathon-recap",{"title":3792,"description":3793,"ogTitle":3792,"ogDescription":3793,"noIndex":6,"ogImage":1462,"ogUrl":3794,"ogSiteName":685,"ogType":686,"canonicalUrls":3794,"schema":3795},"What went down at the Q2'2019 GitLab Hackathon","Here's a recap of GitLab community accomplishments during the Hackathon on May 29-30.","https://about.gitlab.com/blog/q2-hackathon-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What went down at the Q2'2019 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-06-24\",\n }",{"title":3792,"description":3793,"authors":3797,"heroImage":1462,"date":3798,"body":3799,"category":784,"tags":3800},[1281],"2019-06-24","\n\nThe GitLab community gathered on May 29-30 for the Q2 Hackathon, and I was again excited to see new contributors participating. We also had more people joining the tutorial sessions and watching the recordings on [the Hackathon playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh). I was surprised when one of the community members told me he joined the kickoff session when it was past 1am his time!\n\n![Hackathon playlist](https://about.gitlab.com/images/blogimages/Hackathon_playlist.png){: .shadow.medium.center}\n\n## So what did we accomplish?\n\nEven though the Hackathon was during a holiday week in many countries, [44 merge requests (MRs)](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/18) were submitted and more than 30 of these MRs were merged within two weeks of the event. One of the things we did during this recent Hackathon was to maintain [a list of suggested issues](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/17#suggested-issues-list), and one of the issues was picked up shortly after it was discussed during [the GitLab Monitor tutorial session](https://www.youtube.com/watch?v=mm_8wVjn808&list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh&index=3&t=0s). Now, that's what I call just-in-time hacking.\n\n## Hackathon prizes\n\nSimilar to past events, everyone who had MRs merged will receive a token of our appreciation for their contribution. During the Q2 Hackathon, [18 people](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/20) had their MRs merged and we decided to award a second place prize along with the grand prize based on the number of MRs merged. I'm happy to announce that we have a tie for the second place with [Michel Engelen](https://gitlab.com/michel.engelen) and [Marc Schwede](https://gitlab.com/schwedenmut) who both had three MRs merged. The grand prize winner goes to [Marcel Amirault](https://gitlab.com/Ravlen) (a former [MVP](/community/mvp/)), with nine merged MRs.\n\nThanks and congratulations to everyone!\n\n## When is the next Hackathon?\n\nSome of the feedback I received was a suggestion to release future Hackathon dates earlier, so I'm happy to announce that the Q3 Hackathon will take place on August 28-29. It is already advertised on [the Hackathon page](/community/hackathon/) with a new countdown clock. Please look out for more announcements as we get closer to the next Hackathon date. Also, if you have any suggestions for the Q3 Hackathon please feel free to bring them to [the GitLab Contributors Gitter](https://gitter.im/gitlabhq/contributors).\n\n![Q3 Hackathon date](https://about.gitlab.com/images/blogimages/Q3_hackathon_date.png){: .shadow.medium.center}\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,9,787],{"slug":3802,"featured":6,"template":698},"q2-hackathon-recap","content:en-us:blog:q2-hackathon-recap.yml","Q2 Hackathon Recap","en-us/blog/q2-hackathon-recap.yml","en-us/blog/q2-hackathon-recap",{"_path":3808,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3809,"content":3814,"config":3819,"_id":3821,"_type":13,"title":3822,"_source":15,"_file":3823,"_stem":3824,"_extension":18},"/en-us/blog/q3-hackathon-recap",{"title":3810,"description":3811,"ogTitle":3810,"ogDescription":3811,"noIndex":6,"ogImage":1462,"ogUrl":3812,"ogSiteName":685,"ogType":686,"canonicalUrls":3812,"schema":3813},"What went down at the Q3'2020 GitLab Hackathon","A recap of community's accomplishments during another record-setting Hackathon on September 2-3.","https://about.gitlab.com/blog/q3-hackathon-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What went down at the Q3'2020 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2020-09-30\",\n }",{"title":3810,"description":3811,"authors":3815,"heroImage":1462,"date":3816,"body":3817,"category":300,"tags":3818},[1281],"2020-09-30","\n{::options parse_block_html=\"true\" /}\n\nThe GitLab community gathered on September 2-3 for the Q3 Hackathon and once again the GitLab Community set an impressive Hackathon record with [313 MRs](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/41) submitted!\n\n## What did we accomplish?\n\nThis opening line almost needs to be a place holder for Hackathon recaps, but the GitLab community is setting new heights with each iteration. I love seeing the chart below that shows an impressive growth in wider community contributions especially over the past 4 Hackathons. \n![hackathon chart](https://about.gitlab.com/images/blogimages/hackathon-blogpost/q3-2020-hackathon-stats.png){: .shadow.medium.center}\n\nOnce again, there were a lot of frontend/UX related epics that wider community members contributed to. A good example was for migration of [Pajamas](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com) components and the Hackathon helped chip away at more than 1,000 issues related to this migration. One of the feedback from the previous Hackathon was to also have a plenty of backend-related issues for the Hackathon, and I want to thank many GitLab team members who helped populate the list of [suggested Hackathon issues](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/41#suggested-epicsissues-for-the-hackathon) with backend items. \n\nI believe we had the most number of office hour/tutorial sessions during this Hackathon and it's great to see 100+ views of many of these sessions within 24 hours of the recordings being posted on [the Hackathon playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh). If you're interested in making a further dent in 1,000+ issues related to Pajamas components migration, you should watch the [Pajamas tutorial session](https://www.youtube.com/watch?v=cbZADXJh8fg&list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh&index=5&t=1s). You will see that it only takes 5-10 minutes to submit an MR for these issues.\n\n## Hackathon prizes\n\nFor this Hackathon, we have a laptop sleeve for everyone who had their MRs merged by September 15th and [30 people](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/42) will be receiving the prize celebrating the 2nd anniversary of the Hackathon. As we did in the past several quarters, we have a prize for second place and want to recorgnize [Gilang Gumilar](https://gitlab.com/gilangmlr), [Kev](https://gitlab.com/KevSlashNull), and [Takuya Noguchi](https://gitlab.com/tnir) who all had more than 20 MRs merged. For the grand prize, I want to award two contributors [Rajendra Kadam](https://gitlab.com/raju249) with 54 MRs [Jonston Chan](https://gitlab.com/JonstonChan) with 45 MRs merged! Thanks and congratulatations to everyone!\n\n![Hackathon prizes](https://about.gitlab.com/images/blogimages/hackathon-blogpost/q3-2020-hackathon-prizes.png){: .shadow.medium.center}\n## When is the next Hackathon?\n\nThe next Hackathon will take place on December 2-3, 2020. It is already advertised on [the Hackathon page](/community/hackathon/) with a new countdown clock. Please look out for more announcements as we get closer to the next Hackathon date. Also, if you have any suggestions for the Q4 Hackathon please feel free to suggest them on [the GitLab Contributors Gitter](https://gitter.im/gitlabhq/contributors).\n\n## Community challenge\n\nYou may have noticed when you scroll through the Hackathon page that we have a new prize under the [Missed the last Hackathon?](https://about.gitlab.com/community/hackathon/#community-challenge) section. GitLab team members added the `Community challenge` label to a number [issues](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Community%20challenge) that we want to encourage the wider community to work on. If you submit an MR for these issues and they get merged, you will receive a custom merchadise with the \"Community challenge achieved\" message. If you love coffee or tea, I think you will enjoy this cannister for your coffee beans or tea leaves. \n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, UX design, and **project templates**. The [project templates](https://docs.gitlab.com/ee/development/project_templates.html) help developers get started with new languages and frameworks on GitLab. You can improve [existing built-in project templates](https://docs.gitlab.com/ee/user/project/working_with_projects.html#built-in-templates) or start a new template to be distributed with GitLab.\n",[268,9,787],{"slug":3820,"featured":6,"template":698},"q3-hackathon-recap","content:en-us:blog:q3-hackathon-recap.yml","Q3 Hackathon Recap","en-us/blog/q3-hackathon-recap.yml","en-us/blog/q3-hackathon-recap",{"_path":3826,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3827,"content":3832,"config":3837,"_id":3839,"_type":13,"title":3840,"_source":15,"_file":3841,"_stem":3842,"_extension":18},"/en-us/blog/q4-hackathon-announcement",{"title":3828,"description":3829,"ogTitle":3828,"ogDescription":3829,"noIndex":6,"ogImage":1462,"ogUrl":3830,"ogSiteName":685,"ogType":686,"canonicalUrls":3830,"schema":3831},"Get ready for the Q4'2018 GitLab Hackathon","The Q4 Hackathon for the GitLab community will take place on November 14-15.","https://about.gitlab.com/blog/q4-hackathon-announcement","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Get ready for the Q4'2018 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-10-23\",\n }",{"title":3828,"description":3829,"authors":3833,"heroImage":1462,"date":3834,"body":3835,"category":784,"tags":3836},[1281],"2018-10-23","\n\nFollowing the success of [our inaugural event](/blog/hackathon-recap/), the next quarterly Hackathon will take place on November 14-15. We're looking forward to another opportunity for collaboration and meeting with new community members!\n\n## What's the deal?\n\nThis is a virtual event where community members get together to work on merge requests (MRs) and also to welcome and help new contributors. We now have a new [Hackathon landing page](/community/hackathon/), where you will be able to find more details as we get closer to the event. Again, we will have an exciting prize for everyone who has MRs merged within 10 days of the Hackathon:\n\n![GitLab slippers](https://about.gitlab.com/images/blogimages/q4-hackathon-blog/Slippers.JPG){: .shadow.medium.center}\n*\u003Csmall>GitLab slippers for everyone with merged MRs\u003C/small>*\n\nThe person with the most MRs merged during the Hackathon will be able to show off their grand prize around the neighborhood or at a nearby skate park!\n\n![GitLab skateboard](https://about.gitlab.com/images/blogimages/q4-hackathon-blog/Skateboard_-_Gitlab.png){: .shadow.medium.center}\n*\u003Csmall>GitLab skateboard for the grand prize winner\u003C/small>*\n\n## What else is taking place?\n\nIn addition to hacking, we plan to invite community experts for quick presentations plus Q&A sessions on various topics such as getting started as a new contributor, [Meltano](https://gitlab.com/meltano), issue triage, etc. over the two days. These sessions will also be recorded and available on [GitLab YouTube channel](https://www.youtube.com/gitlab). If you want to see materials/recordings from the last Hackathon, you can find them in [the Q3 Hackathon wiki page](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-hackathon/q3-2018-hackathon/wikis/Q3-2018-Hackathon#links-to-presentations-recordings).\n\n## Where can I find help during the Hackathon?\n\nFor communications during the Hackathon, we will use the [GitLab Community room in Gitter](https://gitter.im/gitlabhq/community). This is a channel designed to have community-related discussions and for community members to help each other as people have questions while contributing to GitLab. This is open to everyone, so please [join the room](https://gitter.im/gitlabhq/community) if you are not part of it already.\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\nCover image: [\"Gitlab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel).\n{: .note}\n",[268,9,787,278],{"slug":3838,"featured":6,"template":698},"q4-hackathon-announcement","content:en-us:blog:q4-hackathon-announcement.yml","Q4 Hackathon Announcement","en-us/blog/q4-hackathon-announcement.yml","en-us/blog/q4-hackathon-announcement",{"_path":3844,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3845,"content":3850,"config":3855,"_id":3857,"_type":13,"title":3858,"_source":15,"_file":3859,"_stem":3860,"_extension":18},"/en-us/blog/q4-hackathon-recap",{"title":3846,"description":3847,"ogTitle":3846,"ogDescription":3847,"noIndex":6,"ogImage":1462,"ogUrl":3848,"ogSiteName":685,"ogType":686,"canonicalUrls":3848,"schema":3849},"What went down at the Q4'2019 GitLab Hackathon","A recap of GitLab community's accomplishments during annother record-setting Hackathon on November 13-14.","https://about.gitlab.com/blog/q4-hackathon-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What went down at the Q4'2019 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-12-12\",\n }",{"title":3846,"description":3847,"authors":3851,"heroImage":1462,"date":3852,"body":3853,"category":716,"tags":3854},[1281],"2019-12-12","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nThe GitLab community gathered on November 13-14 for the Q4 Hackathon, and I never get tired of saying that we again set a new record for the number of [MRs submitted (109)](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/28#merge-request-list). It was great to see many new community members join with their first MRs and also follow the tutorial sessions. If you missed any of the tutorial sessions, you can find recordings on [the Hackathon playlist](https://www.youtube.com/playlist?list=PLFGfElNsQthapq-CyXBTVnT2yKqg1JrNh). Also, if you have any suggestions for tutorial topics at future Hackathons you should definitely let me know in the comments section below!\n\n## What did we accomplish?\n\nI mentioned during the kickoff session that it'd be nice to cross the 100 mark for the Hackathon MRs and we saw over 70 MRs on the first day alone. Out of the 109 Hackathon MRs, 79 of these were merged by November 25th, so again big kudos to wider community members and reviewers who made all this possible.\n\nThere are a few things I think deserve special mention. First is [this Epic](https://gitlab.com/groups/gitlab-org/-/epics/2197) that was created by Gitlab's Senior Frontend Enginner [Winnie Hellmann](https://gitlab.com/winh) before the Hackathon. The Epic had \"bite-sized\" issues that contributors were able to tackle during the event and led to almost 30 MRs during the Hackathon. I think this is a great template that we can use for future Hackathons to make it easier for participants to find issues that they can work on. Winnie was also active in providing timely reviews of these MRs and this was certainly appreciated by the wider community.\n\nThe second highlight was [this MR](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/34822) from [Utkarsh Gupta](https://gitlab.com/utkarsh2102) as he helped make sure gender-neutral pronouns are used in our [handbook](https://handbook.gitlab.com/handbook/). MRs like this help make sure that we continue to have a great community at GitLab in addition to having a great software and documentation. As you can see in the next section, Utkarsh made a lot of contributions during the Hackathon, but this MR made me feel proud to be a part of the GitLab community.\n\n![Hackathon stats](https://about.gitlab.com/images/blogimages/hackathon-blogpost/q4-hackathon-stats-chart.png){: .shadow.medium.center}\n\n## Hackathon prizes\n\nFor this Hackathon, we created a tech organizer for everyone who had their MRs merged by November 25th and [18 people](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/issues/29) will be receiving the GitLab branded organizer. As we did in the past few quarters, we have a prize for second place and [Lee Tickett](https://gitlab.com/leetickett) is the winner with 15 MRs merged. The grand prize goes to [Utkarsh Gupta](https://gitlab.com/utkarsh2102) with 28 MRs merged, which is another record for the grand prize (the previous record was 13 MRs). Thanks and congratulatations to everyone!\n\n![Hackathon prizes](https://about.gitlab.com/images/blogimages/hackathon-blogpost/q4-hackathon-prizes.png){: .shadow.medium.center}\n\n## When is the next Hackathon?\n\nI'm happy to announce that the Q1 Hackathon will take place on February 12-13, 2020. It is already advertised on [the Hackathon page](/community/hackathon/) with a new countdown clock. Please look out for more announcements as we get closer to the next Hackathon date. Also, if you have any suggestions for the Q1 Hackathon please feel free to suggest them on [the GitLab Contributors Gitter](https://gitter.im/gitlabhq/contributors).\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,9,787],{"slug":3856,"featured":6,"template":698},"q4-hackathon-recap","content:en-us:blog:q4-hackathon-recap.yml","Q4 Hackathon Recap","en-us/blog/q4-hackathon-recap.yml","en-us/blog/q4-hackathon-recap",{"_path":3862,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3863,"content":3868,"config":3874,"_id":3876,"_type":13,"title":3877,"_source":15,"_file":3878,"_stem":3879,"_extension":18},"/en-us/blog/q42020-hackathon-recap",{"title":3864,"description":3865,"ogTitle":3864,"ogDescription":3865,"noIndex":6,"ogImage":1462,"ogUrl":3866,"ogSiteName":685,"ogType":686,"canonicalUrls":3866,"schema":3867},"What happened at the Q4'2020 GitLab Hackathon","Here's a recap of GitLab community accomplishments during the Hackathon on Jan 6-7th of 2021.","https://about.gitlab.com/blog/q42020-hackathon-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What happened at the Q4'2020 GitLab Hackathon\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Christos Bacharakis\"}],\n \"datePublished\": \"2021-02-08\",\n }",{"title":3864,"description":3865,"authors":3869,"heroImage":1462,"date":3871,"body":3872,"category":784,"tags":3873},[3870],"Christos Bacharakis","2021-02-08","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nDisclaimer: Due to a [bug in our metrics platform](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/general/-/issues/59), that was identified a month after the release of this blogpost, we updated the post with accurate information about the number of MRs submitted, MRs merged, and the winners. In addition, we are not going to take into account the 15th of January as the date the MRs had to be merged to qualify, since we noticed a significant amount of delays in reviewing the MRs.\n  \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\nAnother GitLab hackathon is completed, and I would like to begin by celebrating our community contributions! Congratulations to everyone who participated and contributed to GitLab.\n\nThis time, participants managed to land 167 Merge Request, where 139 (83%) of them have already been merged across eight projects such as: GitLab, Omnibus, GitLab Development Kit, CNG, Runner and more.\n\n![Hackathon playlist](https://about.gitlab.com/images/blogimages/Hackathon_playlist.png){: .shadow.medium.center}\n\nDuring the Hackathon, a number of GitLab Team members ran a series of tutorial sessions around various GitLab Products, stages and groups like Runner, Release Stage, GitLab Pajamas, and Package Group. All of these sessions that are a resource for future contributions were recorded and can be found on our [YouTube Channel](https://www.youtube.com/playlist?list=PL05JrBw4t0KrqGydhkV_BUPrI-DBiDKfm).\n\nSomething unique about this Hackathon is that it happened two times. Originally it was scheduled to take place in December, around the time my onboarding was going to be completed; thus, we had to move it to the beginning of January. Our Tokyo community had already made arrangements for these dates, and with the lead of our Core Team member [Takuya Noguchi](https://gitlab.com/tnir), they successfully organized a [regional GitLab hackathon](https://gitlab-jp.connpass.com/event/189496/). \n\n\n## Hackathon prizes\n\nLike past events, everyone who had MRs merged will receive a token of our appreciation for their contribution. This time, [thirty seven people](https://gitlab.biterg.io/goto/2c0b5d1d60893bcec44dbfd11a16d947) had their MRs merged, where three of them had more than 10 MRs merged, which will receive the Second Prize.\n\nThe grand prize will go to both [Kev](https://gitlab.com/KevSlashNull) and [Jonston Chan](https://gitlab.com/JonstonChan) who had the highest number of merged MRs.\n\nBelow is a list of the top five contributors for this Hackathon, and all the MRs in the [Winder Community Hackathon MRs issue](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/44#related-merge-requests).\n\n- Grand Prize: [Kev](https://gitlab.com/KevSlashNull), with 31 MRs merged\n- Grand Prize: [Jonston Chan](https://gitlab.com/JonstonChan), with 30 MRs merged\n- Second Prize: [Yogi](https://gitlab.com/yo), with 16 MRs merged\n- Second Prize: [Takuya Noguchi](https://gitlab.com/tnir), with 12 MRs merged\n- Second Prize: [Marvin Karegyeya](https://gitlab.com/nuwe1), with 10 MRs merged\n\n\n![Hackathon playlist](https://about.gitlab.com/images/blogimages/q4-hackathon-details.png){: .shadow.medium.center}\n\n## When is the next Hackathon?\n\nThe next Hackathon will occur on March 31st - April 1st, 2021 (yes, it's true!), and all the necessary information will be posted on the [Hackathon page by March 1st](/community/hackathon/).\n\n## How do I get started with contributing?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at cbacharakis@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,9,787],{"slug":3875,"featured":6,"template":698},"q42020-hackathon-recap","content:en-us:blog:q42020-hackathon-recap.yml","Q42020 Hackathon Recap","en-us/blog/q42020-hackathon-recap.yml","en-us/blog/q42020-hackathon-recap",{"_path":3881,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3882,"content":3888,"config":3894,"_id":3896,"_type":13,"title":3897,"_source":15,"_file":3898,"_stem":3899,"_extension":18},"/en-us/blog/quickly-onboarding-engineers-successfully",{"title":3883,"description":3884,"ogTitle":3883,"ogDescription":3884,"noIndex":6,"ogImage":3885,"ogUrl":3886,"ogSiteName":685,"ogType":686,"canonicalUrls":3886,"schema":3887},"How to quickly (and successfully) onboard engineers","It's a tough hiring market today. Here's how GitLab gets engineers onboard fast and sets them up for success.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670635/Blog/Hero%20Images/kubernetesterms.jpg","https://about.gitlab.com/blog/quickly-onboarding-engineers-successfully","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to quickly (and successfully) onboard engineers\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n \"datePublished\": \"2022-07-21\",\n }",{"title":3883,"description":3884,"authors":3889,"heroImage":3885,"date":3891,"body":3892,"category":1053,"tags":3893},[3890],"David O'Regan","2022-07-21","No one ever said hiring was easy. As a matter of fact, talent hiring and\nretention are some of the hardest aspects to get right for any software\ncompany.\n\n\nAccording to [a recent article at Developer\nPitstop](https://developerpitstop.com/how-long-do-software-engineers-stay-at-a-job/)\nthe average engineer will only stay at a job for an average of two years\nbefore moving on, and this tenure is shrinking as time goes on.\n\n\nWhen we look at the average timeline for engineers in a new role we usually\nsee something like:\n\n\n> - Learning and adaptation (3 / 6 months):\n\n> Coming to grips with the new company, team, and their processes.\n\n>\n\n> - Creating value for the organization (6 / 12 months):\n\n> Adding value to the business by becoming a functioning member of the\nteam.\n\n>\n\n> - Becoming a role expert (6 / 18 months):\n\n> Owning the role completely and helping to shape the direction of the\nteam.\n\n\n## Software engineer onboarding\n\n\nAt GitLab we pride ourselves on an outstanding onboarding process to reduce\nthe amount of time an engineer will spend in the `learning and adaptation`\nbracket and accelerate their evolution into the `creating value for the\norganization` bracket. We do this for two main reasons:\n\n\n- **Quicker integration**: We aim to have engineers ship production code in\nless than one week, and fully onboard them in less than three months.\n\n- **Reduce turnover**: Engineers who have an awesome onboarding experience\ntend to stay with the same company longer.\n\n\n**The bottom line is that with these benefits, investing in an amazing\nonboarding process gives you the highest ROI on your hiring initiatives.**\n\n\nSo, now that we know **why** we need to ensure we onboard quickly and\ncorrectly, let's talk about **how** we do it at GitLab.\n\n\n## Software engineer onboarding process: An overview\n\n\n- 💯 Before day one\n\n- 💥 It's all about the onboarding issue\n\n- 🥂 Pick the right onboarding buddy\n\n- 👌 Pair, pair, and more pairing\n\n- 🖐 All the coffee chats\n\n- 🤘 Tailor the experience to the role\n\n- 🚢 Ship some code in a week or less\n\n- 💬 Let's get (and give) some feedback\n\n\n![onboarding](https://about.gitlab.com/images/blogimages/onboarding.png){:\n.shadow}\n\n\n## 💯 Before day one\n\n\nThe best processes for onboarding software engineers start as soon as the\ncandidate has officially accepted the offer. This is done in a few ways:\n\n\n- An onboarding issue is created with tasks for the hiring manager, their\nbuddy, and People Experience (HR).\n\n- The hiring manager selects the right onboarding buddy for the engineer and\ncommunicates expectations (more on this later).\n\n- The engineer's accounts (Email, GitLab account, Okta, etc) are created and\ntheir hardware is shipped.\n\n- GitLab reaches out via email to let the candidate know what the onboarding\nprocess looks like.\n\n- The hiring manager reaches out to the engineer via email to set up a\ncoffee chat on Day 1 as the initial process might seem overwhelming.\n\n\nFor us, the most important aspect is communication with the engineer to\nensure they are set up for success. We provide them with access to their\nonboarding issue, helpful video guides for getting started, and a primer on\nhow to navigate our [handbook like a\npro](https://about.gitlab.com/handbook/people-group/general-onboarding/).\nThe reason this is so important is that we know if we stop communicating\nwith the engineer after signing, we are at risk of creating uncertainty,\nintroducing inefficiency, or even losing them to another offer during that\ntime.\n\n\n## 💥 It's all about the onboarding issue\n\n\nAt GitLab, our [onboarding\nissue](https://about.gitlab.com/handbook/people-group/general-onboarding/#onboarding-issue-template-links)\nis the most effective tool we have for successfully onboarding a new\nengineer quickly. Hiring managers use this issue almost exclusively, both\nfor building momentum and for following our value of transparency. We use\nthis issue, instead of Slack or email, to create a single source of truth\nfor everyone during the process and to prevent fragmented communication. For\nanyone new at GitLab, the first few weeks can seem like a lot to get on top\nof, so the hiring manger wants to be mindful of opportunities to consolidate\ncommunication and reduce context switching.\n\n\nOur onboarding issues are confidential because they contain sensitive\naccount information, but the templates of the issue are\n[public](https://about.gitlab.com/handbook/people-group/general-onboarding/#onboarding-issue-template-links)\nand they look something like this:\n\n\n```\n\n- Accounts and access\n\n- Day 1: Getting started: Accounts and paperwork\n\n- Day 2: Remote working and our values\n\n- Day 3: Security & compliance\n\n- Day 4: Social & benefits\n\n- Day 5: Git & push some code\n\n- Weeks 2 - 4: Explore\n\n- Job-specific tasks\n\n```\n\n\nAs a hiring manager, you want to ensure that you have fleshed out the `job\nspecific tasks` ahead of time with things that are important for the\nspecific role the engineer will be working in. This will generally include\nthings like ensuring they have database access, pointing them to the working\ngroups that will support their work, and letting them know the right Slack\nchannels to support their development.\n\n\n## 🥂 Pick the right onboarding buddy\n\n\nThe advantages of the buddy system have been [well documented for\nyears](https://www.pmi.org/learning/library/implementing-buddy-system-workplace-9376).\nAt GitLab we lean heavily on the onboarding buddy\n[model](https://about.gitlab.com/handbook/people-group/general-onboarding/onboarding-buddies/)\nand rather than having multiple people support the new engineer, it will\ngenerally be the hiring manager and a single buddy.\n\n\nThe advantages of an onboarding buddy at GitLab are several:\n\n\n- **Domain expert**: A onboarding buddy knows the domain the new engineer is\ngoing to be working in. They have already written, reviewed, and merged code\ninto production in the same way we want the new engineer to. They know the\nprocess, pitfalls, and gotchas of the domain.\n\n- **Single context / Accountabilibuddy**: A single onboarding buddy\ndrastically reduces context switching and \"paralysis by analysis.\" They know\nthey always have someone to ask and this creates a psychologically safe\nspace for them. GitLab can often be a scary environment to navigate when you\nare new due to impostor syndrome and we want to curb that.\n\n- **GitLabisms**: At GitLab, we have code and then we have \"GitLabisms.\"\nThese are things that are specific to GitLab, be it workflows or custom\ntooling. These are often more complicated to become familiar with than the\ncode itself. The onboarding buddy should have experience with these already\nand be able to point the engineer in the right direction when they are\nstuck.\n\n- **Mentor**: Mentoring is one of the single best things an engineer can do\nto grow themselves and become more sure of their own skills. By being an\nonboarding buddy, they are given a growth opportunity to cover their own\nblindspots and upskill.\n\n\nAs a rule of thumb, the onboarding buddy should ideally be someone from the\nengineer's new team who is working in the same domain, i.e. a senior\nfrontend engineer mentors a new intermediate frontend engineer, both of\nwhich are from the same team. While this rule is not set in stone, it is\noften less effective to have an onboarding buddy be cross-team due to a lack\nof domain expertise.\n\n\n## 👌 Pair, pair, and more pairing\n\n\nPairing when programming and when working on tasks is a very effective way\nto help new engineers build up their knowledge without needing to pour\nthrough documentation.\n\n\nIn general, we would recommend that the engineer pair with their onboarding\nbuddy on their first few merge requests to get used to the workflow and\npitfalls of working with the GitLab Development Kit. But this is not where\nit should stop. We encourage pairing across the board at GitLab either via\nopen pairing sessions such as our Frontend Pairing office hours, having a\nmanager pair with an engineer, or pairing with a stable counterpart such as\nyour team's UX designer.\n\n\nWhen it comes to onboarding, pairing is helpful. We do this because we want\nto:\n\n\n- **Create psychological safety**: We all feel impostor syndrome. This is\nworse when you're new to a job and don't know the ecosystem yet. Regular\npairing helps to undo that worry as you see people are just people and even\nstaff/principal engineers forget the closing brace!\n\n- **Create relationships/network**: In an all-remote company, it becomes\nimportant to know who to reach out to in moments of need. Regular pairing\nhelps to foster these relationships and creates a safety net with your\npeers.\n\n- **Demonstrate our values**: We believe in [CREDIT](https://handbook.gitlab.com/handbook/values/) at\nGitLab. Regular pairing supports all our core values and helps to encourage\nus to be mindful of them when working.\n\n- **Give and get real-time feedback**: When pairing, we can get real-time\nfeedback on our process and how we're approaching solutions. This is\nextremely important for new engineers who might not be familiar with core\nGitLab concepts such as\n[iteration](https://handbook.gitlab.com/handbook/values/#iteration) (\"How can\nwe break this down?\").\n\n\n## 🖐 All the coffee chats\n\n\nBeing distributed means we do communication differently at GitLab. One key\nto successfully onboarding a new engineer is to get them comfortable with\nour communication style.\n\n\nTo do this, we encourage regular [coffee\nchats](https://about.gitlab.com/company/culture/all-remote/informal-communication/#coffee-chats)\nand a culture of zero shame about it.\n\n\nEncourage your new hire to set up regular coffee chats with people across\nthe company to help build rapport and become comfortable with GitLab as a\nwhole.\n\n\nTo help empower new hires, have them ask the following question in their\ninitial 10 - 15 chats:\n\n\n> What is the one thing I can do to be successful at GitLab?\n\n\n## 🤘 Tailor the experience to the role\n\n\nAs a hiring manger, you need to understand that people learn and grow in\ndifferent ways. No single method will work for everyone and it is your job\nto ensure your new hire feels supported in how they want to learn.\n\n\nDuring the onboarding, observe your new hire and touch base with them in\nyour weekly 1:1 for what they are and **are not** enjoying about the\nexperience so far. Once you have this information, iterate on it and tailor\ntheir onboarding to include more of what they prefer.\n\n\nAsk constructive questions that can have actionable tasks each week to\nensure a better process for them:\n\n\n> Do you want to pair more? Do you want more alone time? Are there\nparticular areas you need more guidance in? Are there things I can do to\nbetter support you?\n\n\nYou should aim to strike a balance during their onboarding for a mixture of\npractical work and time dedicated to studying. Work with the direct report\nto establish the best balance for them as an individual.\n\n\n## 🚢 Ship some code in a week or less\n\n\nThis is arguably the most important aspect of successfully onboarding an\nengineer and setting them up for success. The sooner they can push code to\nproduction, the sooner they can begin to refine their skills and work\neffectively with the team.\n\n\nThe best software companies in the world set a timeline of shipping code in\na week. At GitLab, this is not a hard-and-fast rule, but in the **Create**\nstage is what we strive for.\n\n\nTo ensure an engineer can ship code within a week, we need to ensure they\nare supported in a few ways:\n\n\n- **Tooling**: At GitLab we have a fantastic [local development\nkit](https://gitlab.com/gitlab-org/gitlab-development-kit) which sets up an\nengineer to begin delivering code. We support this kit heavily as a\nfirst-class citizen and are constantly refining the tooling and\n[docs](https://gitlab.com/gitlab-org/gitlab-development-kit/-/tree/main/doc)\nto ensure everyone can contribute. For a new hire, consider having their\nfirst pairing session to be setting up their GDK – this will get them one\nstep closer to shipping quality code.\n\n- **Dev process**: At GitLab, we always strike to [break down work into its\nsmallest\ndeliverable](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)\nthat can be picked up by an engineer without deep contextual understanding.\nWe do this to support the open source community as much as our own\nengineers.\n\n\n## 💬 Let's get some feedback\n\n\nAs a hiring manager, you want to ensure you build a stable feedback loop\ninto your processes and this includes onboarding. During your 1:1s you\nshould include a weekly feedback cycle for both **you** and your direct\nreport.\n\n\nThese feedback cycles should take the form of:\n\n\n- **Appreciation (Collaboration / Results / Diversity / Iteration /\nTransparency)**: A moment of appreciation for something positive that is\nhighlighted inline with our values.\n\n- **Coaching (Collaboration / Results / Diversity / Iteration /\nTransparency)**: A growth opportunity that is highlighted inline with our\nvalues.\n\n\nThese weekly feedback loops allow the engineer to highlight things that\ncould be done better in both the context of the onboarding and their\nday-to-day experience.\n\n\nLastly, it is optional but encouraged to hold an onboarding retrospective\nwhen the initial onboarding issue is closed with the following points to\ntalk through:\n\n\n- What went well?\n\n- What didn't go so well?\n\n- What could be improved?\n\n- Action items\n\n\n## 💾 TL;DR\n\n\nThe most successful software companies have a solidified onboarding process\nand continue to expand on it, setting up both the company and engineers for\nlong-term success. The above methods are how we do it at GitLab.\n\n\n## 💻 Remote development and the developer experience\n\n\nAt GitLab we have recently been hiring for our [Remote Development\neffort](https://about.gitlab.com/direction/create/ide/remote_development/)\nand many of these items are in play with the engineers we are bringing into\nthe company. We want to improve these processes to make onboarding even\neasier, mitigating the need for even setting up a specific local development\ntoolchain to be able to ship production code.\n\n\nIf you think you might be interested in a role at GitLab working on Remote\nDevelopment, check out our open listings\n[here](https://boards.greenhouse.io/gitlab/jobs/6201785002).\n\n\nRead more about [leading endingeering\nteams](/blog/cadence-is-everything-10x-engineering-organizations-for-10x-engineers/).\n",[695,1055,9],{"slug":3895,"featured":6,"template":698},"quickly-onboarding-engineers-successfully","content:en-us:blog:quickly-onboarding-engineers-successfully.yml","Quickly Onboarding Engineers Successfully","en-us/blog/quickly-onboarding-engineers-successfully.yml","en-us/blog/quickly-onboarding-engineers-successfully",{"_path":3901,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3902,"content":3908,"config":3914,"_id":3916,"_type":13,"title":3917,"_source":15,"_file":3918,"_stem":3919,"_extension":18},"/en-us/blog/remote-enables-innovation",{"title":3903,"description":3904,"ogTitle":3903,"ogDescription":3904,"noIndex":6,"ogImage":3905,"ogUrl":3906,"ogSiteName":685,"ogType":686,"canonicalUrls":3906,"schema":3907},"How remote work enables rapid innovation at GitLab","At GitLab, remote isn’t a business operations risk, it’s a competitive advantage.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678666/Blog/Hero%20Images/paper-lanterns.jpg","https://about.gitlab.com/blog/remote-enables-innovation","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How remote work enables rapid innovation at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"}],\n \"datePublished\": \"2019-02-27\",\n }",{"title":3903,"description":3904,"authors":3909,"heroImage":3905,"date":3910,"body":3911,"category":910,"tags":3912},[1447],"2019-02-27","\nI’m a Product Manager here at GitLab, primarily contributing to the [Plan stage](/direction/plan/)\nof the [DevOps lifecycle](/stages-devops-lifecycle/). I joined in November 2016 and I’ve witnessed incredible\ngrowth in GitLab the product as well as GitLab the team. Many\nnew hires have asked me during [coffee chats](/company/culture/all-remote/#coffee-chats)\nabout GitLab culture and remote work in particular, since we're an [all-remote](/company/culture/all-remote/)\ncompany. My view has evolved over this time and I wanted to share specifically why I think\nremote is _not_ a challenge to overcome, but actually a _competitive advantage_, at least for GitLab.\n\n## A remote journey\n\nWhen I joined GitLab, I thought remote was a challenge to overcome or at least\nto manage. It was a risk to be mitigated. For example, I really wanted daily standup\nmeetings with the engineering team I was working with. Silicon Valley-style tech\ncompanies and product management books tell us that frequent, synchronous, face-to-face\ncommunication is necessary for building successful products efficiently and to win\nin the marketplace. To my dismay at the time, we never had in-sync standups (and\nmy team today still doesn’t have them). But curiously, we nonetheless had immense\ncollaboration and continued to ship product at a high velocity. Something really\nweird and unexpected was going on.\n\nLater on, as I started getting comfortable [doing product the GitLab way](/handbook/product/),\nI started to think that remote wasn’t really a risk, but that there were just a\nfew negatives, and that the overall effect was net positive. See the [advantages and disadvantages of remote](/company/culture/all-remote/#advantages-for-employees).\n\nToday, I realize that even a positive-negative accounting of remote is insufficient\nto articulate what remote means at GitLab. I think that remote\n(along with a few other key crucial GitLab ingredients) gives us a differentiated\nand competitive advantage, in particular allowing us to innovate at a rapid pace\nthat is truly unique. Here's why:\n\n## Interdependent ingredients\n\nThere are a several crucial and interdependent GitLab ingredients that make remote\ntruly work in our favor:\n\n### Async communication\n\nRemote implies geographic diversity (since we hire all over the world),\nand because most folks work during the day, that further implies time zone diversity.\nConsequently, we prefer **[Async communication (primarily with text)](https://handbook.gitlab.com/handbook/communication/)** as we scale our organization in\nspace-time. Async demands everything be written down and that it be clear and concise.\nYou can’t afford a prolonged back-and-forth conversation because every round-trip\ntransaction is possibly 24 hours in the worst case. In particular, we prefer text\nbecause the internet and modern apps (for example [GitLab issues](https://docs.gitlab.com/ee/user/project/issues/)) has allowed text\nto be easily organizable, searchable, and even hyperlinked. Text is easy to parse\nand thus consume. It is a highly efficient form of communication, especially for\ntransactional collaboration.\n\n### Transparency\n\nThe async communication we reference is also digital, making it infinitely\nscalable. Unlike the printed page in a physical office, anybody should\nbe able to access a digital message. So, rather than re-erecting the walls and silos\nthat plague traditional organizations and inevitably block collaboration, we\nmake communications and work **[transparent](https://handbook.gitlab.com/handbook/values/#transparency)** by default.\nAdding a layer of permissions is necessary sometimes, and in those cases it becomes an overhead cost to manage\nand use (for example fixing a security bug.) The transmitter of communications\nneeds to figure out who should receive, and set the appropriate permissions. The\nreceiver themself needs additional work to access the content. It’s more pain. It\nadds up. So we try to avoid it when we can.\n\n>Because you know everything you write down will potentially be viewed by anyone – inside or even outside the company – simply telling the truth is the optimal and most efficient strategy\n\nTransparency also makes it really easy to tell the truth, and disincentivizes dishonesty.\nTelling the truth is simply the right thing to do, but it’s also a great strategy\nto grow a long-term sustainable business. In particular, because you know everything\nyou write down will potentially be viewed by anyone in the company or even outside\nthe company, simply telling the truth is the optimal and most efficient strategy\nand you will thus adopt it with little friction. You don’t have to make up slightly\ndifferent versions for different stakeholders. You don’t have to keep track of all\nthese versions. And you only need a single artifact to document that one source\nof truth, which will never be out of sync, because there’s only one! For\nus, that single source of truth is typically the description in an issue.\n\n### Everyone can contribute\n\nWith a single source of truth that is consumable by anybody, it allows **[everyone to contribute](/company/mission/#mission)**.\nEveryone has information parity. And so anyone is welcome to contribute. In fact,\nremember I mentioned above that the transmitter of information typically has an intended receiver\nin mind? In this case, oftentimes somebody who they didn’t expect can even participate\nand add value. This isn’t possible if there’s no transparency because artificial\nbarriers pre-close the opportunities of potential collaboration. Also, everyone\ncan contribute means future folks can participate too. You may start a conversation\non an idea that turns out to be suboptimal in the current circumstances. But it\nmight end up being just a timing issue. And so posterity might be able to recover\nthe old idea and ship a feature later on, taking advantage of all the discussions\nthat were had and made available publicly.\n\nEveryone can contribute also means that the diversity of ideas skyrockets. And so\nat GitLab, people often cross departments and offer some of the best ideas to solve\nbig challenging problems. But we still have [directly responsible individuals](/handbook/people-group/directly-responsible-individuals/)\nto make decisions in order to avoid analysis paralysis.\n\n### Iteration\n\nFinally, how can all this communication and collaboration truly function if the\nmechanisms are so transactional, distributed, and unstructured? It works because\nit forces us to be **[iterative](https://handbook.gitlab.com/handbook/values/#iteration)**. Most people think they understand iteration (myself\nincluded) before joining GitLab. But I’ve discovered over and over again that new\nfolks are surprised that this concept is taken to an extreme. Product\nand code are shipped in the absolute smallest piece possible in an effort to get\nfeedback and momentum. Implementing programs and processes at GitLab means breaking\noff the smallest chunk and then putting it into action right away. We still make\nbig, bold plans and big bets on the future. But we don’t obsess over extended analysis.\nInstead we find the smallest thing that we can do now and we do it. We believe that\nwaiting until tomorrow is an opportunity cost. Doing something small today is low\nrisk and results in immediate feedback. We have a [bias for action](https://handbook.gitlab.com/handbook/values/#bias-for-action).\n\n>We believe that waiting until tomorrow is an opportunity cost. Doing something small today is low\nrisk and results in immediate feedback.\n\nAnd so if all our communication and collaboration is focused on small iterations,\nthe scope of a typical problem is small and manageable. And it turns out (unsurprisingly)\nmore people are willing to participate in a small problem if it literally takes\nthem a few moments to voluntarily glance at an issue description, instead of being\nforced to attend a two-hour slide presentation explaining a big problem.\nAnd since the problem is made transparent by default, the pool of contributors is\nvery high, as mentioned earlier. Personally, I am actively involved\nin at least 20 to 30 parallel problem conversations on a daily basis. It is impossible\nfor anyone to achieve that level of productivity if all to those conversations required\ndedicated, ongoing, synchronous meetings. This results in an incredible rate of collaboration\nfor myself. Multiply that by all team members at GitLab, and then also all GitLab\ncommunity members further still, and you can see now why GitLab’s pace of innovation\nis ridiculously high.\n\nRemote is not a challenge for GitLab to overcome. It’s a clear business advantage.\n\n## Ending caveat\n\nThe picture I’ve painted here is one of constant messaging and wild ideas. And\nthat’s intentional because it’s true. New folks joining GitLab often are inundated\nby the number of discussions they find themselves involved in after several weeks\nin. This is indeed an ongoing risk for GitLab especially as we scale and the level\nof ideation grows exponentially in relation to headcount (since communication links\ngrow exponentially as nodes in a people network grow). I’ve observed that GitLab\nteam members usually figure out a way to cope soon enough, and typically become\nmore selective in their communications over time. I think this is a good general\nstrategy overall, because good ideas tend to get more attention, and we essentially\nrely on the wisdom of the crowds to surface them. Of course we still have well-defined\nroles and responsibilities that serve as guardrails too, that allow subject matter\nexperts and directly responsible individuals to strategically guide our innovation\nin the right general direction.\n\nHow are you making remote work work? Let us know in the comments or tweet us [@gitlab](https://twitter.com/gitlab).\n\n[Cover image](https://unsplash.com/photos/TaXPogWdzR0) by [amseaman](https://unsplash.com/@amseaman) on Unsplash\n{: .note}\n",[9,934,1097,3913,912],"startups",{"slug":3915,"featured":6,"template":698},"remote-enables-innovation","content:en-us:blog:remote-enables-innovation.yml","Remote Enables Innovation","en-us/blog/remote-enables-innovation.yml","en-us/blog/remote-enables-innovation",{"_path":3921,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3922,"content":3927,"config":3932,"_id":3934,"_type":13,"title":3935,"_source":15,"_file":3936,"_stem":3937,"_extension":18},"/en-us/blog/remote-pair-programming-tips",{"title":3923,"description":3924,"ogTitle":3923,"ogDescription":3924,"noIndex":6,"ogImage":924,"ogUrl":3925,"ogSiteName":685,"ogType":686,"canonicalUrls":3925,"schema":3926},"4 tips for agile remote pair programming","Pair programming is great for remote collaboration. Our remote pairing enthusiasts share how to make the most of it.","https://about.gitlab.com/blog/remote-pair-programming-tips","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"4 tips for agile remote pair programming\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n \"datePublished\": \"2021-02-04\",\n }",{"title":3923,"description":3924,"authors":3928,"heroImage":924,"date":3929,"body":3930,"category":910,"tags":3931},[1158],"2021-02-04","\n\n_This is the second post in our ongoing series about remote work and engineering. Check out our first post, \n[Tips for engineering managers learning to lead remotely](/blog/tips-for-managing-engineering-teams-remotely/)._\n\nAs more companies shift to remote-first or all-remote work, engineers may be feeling the loss \nof their teammates' company. The good news is that unlike other forms of in-person collaboration,\npair programming translates really well to remote work, and in some cases is even more effective. \n\nOur [support engineers](https://handbook.gitlab.com/job-families/engineering/support-engineer/overview/) do regular \npair programming on tickets, and many speak of it as a highlight of their work weeks due to the \nsocial element of the calls, as well as it proving more efficient for some troublesome tickets. \n(We'll dive into why, but feel free to jump to our [tips for effective remote pair programming](#how-to-get-the-most-out-of-remote-pairing)\nif you prefer!)\n\n## What is pair programming?\n\nPair programming (sometimes referred to as paired programming) is an agile, collaborative software development method done between a team of two developers that each take on an individual role. These roles are called the driver and the navigator. The driver works directly at the computer while the navigator concentrates on the overall programming direction.\n\nThe purpose of pair programming is to design, code, and test user stories all on one computer. Although the driver is the primary teammate at the keyboard, this system requires that each developer role have equal time and responsibility to complete their part of the development. The driver writes the code and the navigator reviews it, and these roles can be switched between the two teammates as needed.\n\n## It's more than just work\n\n[Ronald van Zon](/company/team/#rvzon), senior support engineer, explained that pair programming provides an opportunity for team members to chat about their lives outside of work, instead of focusing solely on outstanding tickets. \n\n\"You see someone face to face, so you might ask them, 'Hey, how was Christmas? How are you doing?' \nIf they have something going on in their private life, the next time I see them I will ask about it, so there's a social aspect to it.\"\n\n\"It's a lot of fun. In cases where you're really focused on work and you have a very difficult ticket, it's actually very nice to have someone there just to throw your ideas at.\" \n\n## You see the problem more clearly\n\nInstead of relying solely on your judgment, programming in pairs means your teammate might ask you questions about something, introducing ideas you hadn't necessarily thought of, and identifying gaps you would otherwise miss.\n\n\"For example, we had one very long-running ticket, where we'd tried a hundred thousand things already, \nand weren't sure what to do next,\" Ronald says. \"Just by talking with a group and explaining what the situation \nwas helped me realize what the next steps should be. I could have looked at that ticket the entire \nday and wouldn't have come up with it on my own.\"\n\nSenior support \nengineer [Arihant Godha](/company/team/#arihantar) explains another scenario where pair programming paid off in a big way. \"In one of our pairings we worked \non a complex customer issue related to merge trains, where we did a multi-cross-team pairing \nand identified the crucial issue which was a blocker for one of our biggest customers. \nWe didn't just identify the problem, we also found the workaround for it until our developers \nwere able to deliver a fix.\"\n\n## You can pool your knowledge\n\nAs the saying goes, two heads are better than one. Pair programming allows engineers who may be experts on different things to come together to tackle a single problem. \n\n\"Pairing on tickets is a great way to collaborate on problem solving,\" says [Cynthia Ng](/company/team/#cynthia), \nsenior support engineer. \"It’s especially useful at GitLab, where we have a single product that \ncovers a wide variety of areas, because each person has expertise on different parts. \nSeeing how others approach and solve problems can also greatly inform your own work as well.\"\n\nSupport engineer [Anton Smith](/company/team/#anton) agrees: \"I find that I learn and absorb so much knowledge just from conversing with another support engineer in a pairing call.\"\n\n## You get to the best solution\n\n\"A problem can have multiple solutions and multiple approaches to solve,\" says Arihant. \n\"Sometimes ticket pairing gives you the best approach to solve a ticket. It also helps you in learning \nand sharing knowledge. For example: If you can ask for all the required information in one\n ticket response rather than having lots of back and forth, then it’s a great user experience.\" \n \nCynthia shares a specific example from her past experience with pair programming. \"[Davin Walker](/company/team/#davinwalker) and I paired a couple of times on getting trials \nand their expiry dates showing on the admin side of GitLab’s Customers Portal. \nThe [merge request](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2096) \nis meant to help improve our team’s efficiency in handling SaaS trial-related requests. \nPairing really helped to work out the scope of the issue and what we could ship as the first iteration.\"\n\n## Benefits of pair programming\n\nThe benefit of pair programming is that there are two sets of eyes to help review the code being produced to ensure that it is as good as it possibly can be. This is commonly known as the four-eyes principle. \n\nThis leads to other benefits, like…\n\n* Reducing the number of coding mistakes\n* Becoming a better coder overall\n* Learning from another experienced developer as well as learning from the mistakes made during a project\n* Building better collaboration skills\n\nThis system also breaks up the development project into smaller, specifically defined tasks under the agile project structure. \n\n## Why _remote_ pair programming works\n\nIn speaking to our remote pairing fans, it's clear that pair programming is a form of collaboration that \ndoesn't lose anything by being conducted remotely.\n\n\"It's no different from sitting next to the person. In fact it gives you a better view to look at and \nfind better approaches simultaneously without wasting any time,\" says Arihant.\n\n\"I’ve done pair programming in person and I actually find it easier remote because of screen sharing,\" explains Cynthia. \"You have more control over what you’re looking at and how, whereas in person, often the main thing you’re working on together is on one person’s screen.\"\n\n## How to get the most out of remote pairing\n\n### 1. Know when to pair \n\nWe've focused on tickets so far because our support engineers at GitLab are our biggest remote pairing advocates. \nSupport engineering often involves debugging a customer problem, so it tracks that pairing would be \nuseful (compared to developers who are usually focused on building something). But really, any developer can \nbenefit from pairing when stuck on a problem. \n\nRonald worked as a developer for more than 15 years before joining the Support team at GitLab, \nincluding a year spent as the only developer for an entire company. \"One thing I learned really \nquickly was that if I was stuck on a problem, essentially, I had no one to talk to, which made things difficult.\"\n\nWorking in isolation, without the distractions of the office, is great when you're in the zone. \"It works until you run into a difficult problem to solve,\" says Ronald. \"Spending three days on a problem, before getting to the single line of code that solves it, sucks.\" If you find yourself not making any progress on a challenge, it's probably time to pair.\n\n### 2. Go in with a clear agenda\n\nOut of [respect for everyone's time](https://handbook.gitlab.com/handbook/values/#be-respectful-of-others-time), we recommend that every meeting start with an agenda, and scheduling a pair programming session is no exception.\n\n\"I think it’s important to set expectations or goals for the session. It can be fairly general like, 'explore what options we have,' but the key is to make sure you’re on the same page about what you want to do during the session,\" says Cynthia.\n\nArihant agrees: \"The agenda should be set beforehand so you have enough time to understand the problem statement.\" \nOtherwise you might spend 20 minutes reading through tickets or bug reports before landing on something to work on together. \n\n### 3. Tackle bugs one at a time\n\n\"Take one problem at a time and try to reproduce if you are trying to solve a bug,\" Arihant recommends. It might be tempting to try to solve more than one problem if you think they're connected, but you really won't know that until you fix the first thing. \n\n### 4. Speak up! \n\nThis goes for remote or in-person pairing: speaking freely helps to get to the root of the problem more quickly.\n\"Don’t be afraid to voice your opinion,\" advises Anton. \"Even if something is wrong, it helps eliminate the cause of a problem and it might spark alternative ideas.\" \n\n## How we do remote pairing \n\nAt GitLab, we have a mix of ad hoc and scheduled pairing sessions. \"Pairings are required as \npart of the Support team onboarding, and we also have a support [Donut app](https://www.donut.com/) \nchannel that people can join to decide who to pair with,\" explains Cynthia.\n\nHaving recurring pairing sessions can help engineers stay connected with their teammates, says Anton, but spontaneity can be helpful if you're swamped or get stuck on a problem: \"If I am working in the queue to stop tickets from breaching, sometimes I will publicly post my Zoom room link in Slack and allow anyone to join.\"\n\nArihant says, \"If I want to pair with someone I simply ask them in team chat or simply send them a calendar invite. If it is for a specific topic or group, then I check the [area of focus](https://gitlab-com.gitlab.io/support/team/areas-of-focus.html) or [skills by person](https://gitlab-com.gitlab.io/support/team/skills-by-person.html) pages to find the best person to partner with.\"\n\nWe also have a [dedicated issue tracker for support pairings](https://gitlab.com/gitlab-com/support/support-pairing/-/issues)\nso team members can track who they've paired with and on what.\n\n_Keep an eye out for the next post in our series, where we'll be sharing more remote collaboration practices for engineers._\n",[9,1097],{"slug":3933,"featured":6,"template":698},"remote-pair-programming-tips","content:en-us:blog:remote-pair-programming-tips.yml","Remote Pair Programming Tips","en-us/blog/remote-pair-programming-tips.yml","en-us/blog/remote-pair-programming-tips",{"_path":3939,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3940,"content":3946,"config":3952,"_id":3954,"_type":13,"title":3955,"_source":15,"_file":3956,"_stem":3957,"_extension":18},"/en-us/blog/remote-work-done-right",{"title":3941,"description":3942,"ogTitle":3941,"ogDescription":3942,"noIndex":6,"ogImage":3943,"ogUrl":3944,"ogSiteName":685,"ogType":686,"canonicalUrls":3944,"schema":3945},"Remote work, done right","Guest author Nolan Myers hated conference calls. Here's how we changed his mind.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679812/Blog/Hero%20Images/remote-work-done-right.jpg","https://about.gitlab.com/blog/remote-work-done-right","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Remote work, done right\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nolan Myers\"}],\n \"datePublished\": \"2018-03-16\",\n }",{"title":3941,"description":3942,"authors":3947,"heroImage":3943,"date":3949,"body":3950,"category":910,"tags":3951},[3948],"Nolan Myers","2018-03-16","\n\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab._\n\nI’ve been on many terrible conference calls. The gentle voice telling me to enter my nine-digit pin, followed by the pound sign, feels like disappointment before the call even begins. That’s why I was so surprised to hear that GitLab – a company of over 200 people – runs without an office. How could anything get done when every meeting was remote?\n\n\u003C!-- more -->\n\nSeeing is believing, so I jumped at the opportunity to watch firsthand. What I learned convinced me that remote meetings can be just as good as in person, and maybe even better. Here’s what impressed me:\n\n### Video conference for all\n\nEveryone joined a Zoom call, each from their own computer. Most everyone had their cameras on, which gave enough visual cues to see their mood; sometimes even an understanding of who they are, like seeing a pool table or disassembled motorcycle behind them. The video format helped enforce some good meeting practices. Only one speaker at a time; a singular focus of attention, either a person or a shared screen. Meetings started on time, never having to wait for a previous group to clear a conference room. Having everyone join independently also worked much better than having a few people in a room and a few remotes, which inevitably creates a power-center in the room.\n\n>The video format helped enforce some good meeting practices: only one speaker at a time; a singular focus of attention\n\n### Create a live agenda in a shared document\n\nEach meeting started with an agenda in a shared Google Doc. They coupled this with a “write before you speak” etiquette. Anyone was welcome to speak, and added a brief summary of their question or comment into the shared doc before chiming in. This encouraged the speaker to be deliberate about their point, think about where in the flow it made most sense, and to know they’d get the floor when appropriate. It was kind of a marvel to see bullets and sub-bullets evolve during the meeting. A task owner typed “TODO: follow up” right as they said “I got it.” Even better, they were left with detailed meeting notes for posterity.\n\n>It was kind of a marvel to see bullets and sub-bullets evolve during the meeting. A task owner typed “TODO: follow up” right as they said “I got it.”\n\n### Embrace multitasking\n\nHow often have you heard that you should give a meeting your undivided attention? And how often have you actually believed it? GitLab embraces multitasking. Having everyone together ensures the right people are there for important conversations. But inevitably a packed meeting agenda will have sections more and less relevant to a variety of participants. Unlike in a room, a video call where someone tunes out for a bit doesn’t hamper the effectiveness of those focused on a conversation. The shared agenda let everyone know when they were needed, and each topic had the right people ready to contribute.\n\n### Caveats and considerations\n\nThis process felt like a miniature miracle to watch, but does need the right tools. GitLab relied on Zoom and it worked well. One external call used WebEx, and its longer latency led people accidentally to talk over one another. Google Docs was a must for the shared agenda. Everyone had set up a reasonable workspace with fast internet and a camera.\n\nI’d also add that I saw this work well for both update- and decision-oriented meetings. Would this approach support technical brainstorming meetings too? Sometimes drawing on a whiteboard works much better than typing, especially if you have a diagram. Zoom does have a whiteboard feature; perhaps with a Stylus you could do this as well as in person. I’m curious to see it in practice.\n\nWhen I first heard of GitLab’s remote-only hiring, I immediately saw the benefits of hiring in lower-rent locations and not paying for office space. I assumed that it cost some productivity through effective collaboration. Now I see video calls done right can beat all but the best traditional conference room meetings.\n\n## About the guest author\n\nNolan Myers advises startups on organizational development and customer success, leveraging his executive experience in building high-performing products and teams. He also has passions for classical music, fine cuisine, and urban design. Learn more on his [LinkedIn](https://linkedin.com/in/nolanmyers).\n\nPhoto by [Christin Hume](https://unsplash.com/photos/slbqShqAhEo) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[1097,934,912,9,787],{"slug":3953,"featured":6,"template":698},"remote-work-done-right","content:en-us:blog:remote-work-done-right.yml","Remote Work Done Right","en-us/blog/remote-work-done-right.yml","en-us/blog/remote-work-done-right",{"_path":3959,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3960,"content":3965,"config":3970,"_id":3972,"_type":13,"title":3973,"_source":15,"_file":3974,"_stem":3975,"_extension":18},"/en-us/blog/semyon-pupkov-contributor-post",{"title":3961,"description":3962,"ogTitle":3961,"ogDescription":3962,"noIndex":6,"ogImage":1276,"ogUrl":3963,"ogSiteName":685,"ogType":686,"canonicalUrls":3963,"schema":3964},"GitLab Code Contributor: Semyon Pupkov","Long-time contributor Semyon Pupkov shares why he loves contributing to GitLab.","https://about.gitlab.com/blog/semyon-pupkov-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Semyon Pupkov\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-01-30\",\n }",{"title":3961,"description":3962,"authors":3966,"heroImage":1276,"date":3967,"body":3968,"category":784,"tags":3969},[1281],"2019-01-30","\n\nFor this month's contributor post, I'm excited to introduce [Semyon Pupkov](https://gitlab.com/artofhuman), who's been a consistent contributor to GitLab since 2016. The graph below shows Semyon's merge requests (MRs) since GitLab 8.13. Let's get to know him!\n\n![Semyon's MRs](https://about.gitlab.com/images/blogimages/semyon-blogpost/semyon-mrs.png){: .small.center}\n\n### Can you tell us where you live and a little bit about your area?\n\nI live in a city called [Yekaterinburg](https://www.google.com/maps/place/Yekaterinburg,+Sverdlovsk+Oblast,+Russia/@56.8138122,60.5145089,11z) in the Ural region of Russia. I love the nature here as it's not too hot in the summer and you will find good snow in the winter for snow boarding.\n\n### When did you first contribute to GitLab and why did you decide to contribute?\n\n[My first MR](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6762) about two years ago was a pretty simple one as I removed unnecessary code from tests. I used GitLab Community Edition for my private projects and since I like open source software, I decided to look at the GitLab code base. When I found some areas for improvement mainly in tests, I decided to create my first MR.\n\n### Which areas of GitLab product have you been contributing to over the past two years?\n\nMost of my contributions have been on the backend side where I tried to improve the existing code base.\n\n### Can you tell us what you do professionally?\n\nI am a backend Ruby/Python developer and work at a company called [SKB Kontur](https://kontur.ru/eng/about).\n\n### What do you enjoy doing when you're not working?\n\nI have been a father for about six months, and I try to give as much of my free time to my daughter. I also like playing games on PlayStation 4 and my favorite game right now is FIFA 19. And of course, I like to contribute to open source projects.\n\n![Semyon's family](https://about.gitlab.com/images/blogimages/semyon-blogpost/semyon-family.JPG){: .shadow.small.center}\n\n### What can we do better to help GitLab community contributors?\n\nSometimes in issues/MRs, I find links to Zendesk tickets or Slack discussions that are private, and this can be frustrating for someone not working at GitLab. Also, it would be great if GitLab had a better setup for local development with Docker and Docker Compose. I found the branch in the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) repository with [support for Docker Compose](https://gitlab.com/gitlab-org/gitlab-development-kit/tree/docker-compose), but it probably needs some updating. I recently submitted an [MR to help address this](https://gitlab.com/gitlab-org/gitlab-development-kit/merge_requests/592).\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nJust don't be afraid to get started. If you find places in the code that can be improved, you should make a contribution and in most cases your code will be welcomed and accepted.\n\nContributing to GitLab also allows you to work with a strong professional team. It's a good way to improve your skills while working on a great product.\n\n### Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[268,9,787,1285],{"slug":3971,"featured":6,"template":698},"semyon-pupkov-contributor-post","content:en-us:blog:semyon-pupkov-contributor-post.yml","Semyon Pupkov Contributor Post","en-us/blog/semyon-pupkov-contributor-post.yml","en-us/blog/semyon-pupkov-contributor-post",{"_path":3977,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3978,"content":3984,"config":3991,"_id":3993,"_type":13,"title":3994,"_source":15,"_file":3995,"_stem":3996,"_extension":18},"/en-us/blog/sentry-integration-blog-post",{"title":3979,"description":3980,"ogTitle":3979,"ogDescription":3980,"noIndex":6,"ogImage":3981,"ogUrl":3982,"ogSiteName":685,"ogType":686,"canonicalUrls":3982,"schema":3983},"Sentry's GitLab integration streamlines error remediation","Your code has bugs, my code has bugs, everyone’s code has bugs (probably). Let’s fix that.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679964/Blog/Hero%20Images/sentry-io-blog.jpg","https://about.gitlab.com/blog/sentry-integration-blog-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Streamline and shorten error remediation with Sentry’s new GitLab integration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Eva Sasson\"}],\n \"datePublished\": \"2019-01-25\",\n }",{"title":3985,"description":3980,"authors":3986,"heroImage":3981,"date":3988,"body":3989,"category":784,"tags":3990},"Streamline and shorten error remediation with Sentry’s new GitLab integration",[3987],"Eva Sasson","2019-01-25","\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/KUHk1uuXWhA?rel=0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSentry is open source error tracking that gives visibility across your entire stack and provides the details you need to fix bugs, ASAP. Because the only thing better than visibility and details is more visibility and details, Sentry improved their [GitLab integration](https://docs.sentry.io/workflow/integrations/global-integrations/gitlab/?utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM) by adding [release](https://docs.sentry.io/workflow/releases/?platform=browser&utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM) and [commit](https://docs.sentry.io/workflow/releases/?platform=browser&utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM#link-repository) tracking as well as [suspect commits](https://docs.sentry.io/workflow/releases/?platform=browser&utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM#after-linking-a-repository).\n\n### Streamline your workflow with issue management and creation\n\nWhen you receive an alert about an error, the last thing you want to do is to jump around 20 different tools trying to find out exactly what happened and where. Developers with both Sentry and GitLab in their application lifecycle benefit from issue management and issue creation to their GitLab accounts directly in the Sentry UI, alleviating some of the hassle of back-and-forth tool toggling.\n\n![GitLab account in Sentry](https://about.gitlab.com/images/blogimages/sentry/gitlab-sentry-integration.png){: .shadow.large.center}\n\nOf course, less tool jumping results in a more streamlined triaging process and shortened time to issue resolution – something that benefits the whole team.\n\n![Creating GitLab issue](https://about.gitlab.com/images/blogimages/sentry/create-gitlab-issue.png){: .shadow.medium.center}\n\nHave a GitLab issue that wasn’t created in Sentry? No problem. Existing issues are also easily linked.\n\n![Import GitLab issue](https://about.gitlab.com/images/blogimages/sentry/import-gitlab-issue.png){: .shadow.medium.center}\n\n### Find and fix bugs faster with release and commit tracking\n\nWhy stop at streamlining the triaging process, when we can also make issue resolution more efficient? Sentry’s GitLab integration now utilizes GitLab commits to find and fix bugs faster.\n\nWith the newly added release and commit tracking, an enhanced release overview page uncovers new and resolved issues, files changed, and authors. Developers can also resolve issues via commit messages or merge requests, see suggested assignees for issues, and receive detailed deploy emails.\n\nWant a big flashing arrow that points to an error’s root cause? Sentry’s suspect commits feature exposes the commit that likely introduced an error as well as the developer who wrote the broken code.\n\n![Suspect commits feature](https://about.gitlab.com/images/blogimages/sentry/suspect-commits-feature.png){: .shadow.medium.center}\n\nKeep in mind that this feature is available for Sentry users on “Teams” plans and above.\n{: .note}\n\nCheck out [Sentry’s GitLab integration documentation](https://docs.sentry.io/workflow/integrations/global-integrations/gitlab/?utm_source=GitLab&utm_medium=blog&utm_campaign=GitLab_GTM) to get started.\n\n### What’s next?\n\nAgain, why stop there, when we can do even more? GitLab is currently working to bring Sentry into the GitLab interface. Soon, GitLab and Sentry users will see their Sentry errors listed in their GitLab projects. Read the documentation on [the integration here](https://docs.gitlab.com/ee/operations/error_tracking.html).\n\n### About the guest author\n\nEva Sasson is a Product Marketer at [Sentry.io](https://sentry.io/welcome/), an open source error-tracking tool that gives developers the contextual information they need to resolve issues quickly, and integrates with the other development tools across the stack.\n",[108,9,695,232,787,807,1055,1263,912],{"slug":3992,"featured":6,"template":698},"sentry-integration-blog-post","content:en-us:blog:sentry-integration-blog-post.yml","Sentry Integration Blog Post","en-us/blog/sentry-integration-blog-post.yml","en-us/blog/sentry-integration-blog-post",{"_path":3998,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":3999,"content":4004,"config":4009,"_id":4011,"_type":13,"title":4012,"_source":15,"_file":4013,"_stem":4014,"_extension":18},"/en-us/blog/sharing-slis-across-departments",{"title":4000,"description":4001,"ogTitle":4000,"ogDescription":4001,"noIndex":6,"ogImage":1131,"ogUrl":4002,"ogSiteName":685,"ogType":686,"canonicalUrls":4002,"schema":4003},"How we share SLIs across engineering departments","The Scalability team engages with the Development department for collaborating on SLIs. The first post in this series explains how we made available information accessible for development groups.","https://about.gitlab.com/blog/sharing-slis-across-departments","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we share SLIs across engineering departments\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Bob Van Landuyt\"}],\n \"datePublished\": \"2022-03-10\",\n }",{"title":4000,"description":4001,"authors":4005,"heroImage":1131,"date":3140,"body":4007,"category":1053,"tags":4008},[4006],"Bob Van Landuyt","\nAt GitLab everyone can contribute to GitLab.com's availability. We\nmeasure the availability using several Service Level Indicators (SLIs)\nBut it's not always easy to see how the features you're building are\nperforming. GitLab's features are divided amongst development groups,\nand every group has [their own dashboard](https://docs.gitlab.com/ee/development/stage_group_observability/index.html)\ndisplaying an availability score.\n\n![Stage group availability](https://about.gitlab.com/images/blogimages/2022-02-share-infrastructure-slis/2022-02-23-code_review_availability.png)\n\nWhen a group's availability goes below 99.95%, we work with the group\non figuring out why that is and how we can improve the performance or\nreliability of the features that caused their number to drop. The\n99.95% service level objective (SLO) is the same target the\ninfrastructure department has set for\n[GitLab.com availability](/handbook/engineering/infrastructure/performance-indicators/#gitlabcom-availability).\n\nBy providing specific data about how features perform on our production systems, it has become easier to recognize when it is important to prioritize performance and availability work.\n\n## Service availability on GitLab.com\n\nOur infrastructure is separated into multiple services, handling\ndifferent kinds of traffic but running the same monolithic Rails\napplication. Not all features have a similar usage pattern. For\nexample, on the service handling web requests for GitLab.com we see a\nlot more requests related to `code_review` or `team_planning` than we\ndo related to `source_code_management`. It's important that we\nlook at these in isolation as well as a service aggregate.\n\nThere's nobody who knows better how to interpret these numbers in\nfeature aggregations than the people who build these features.\n\nThis number is sourced by the same SLIs that we use to monitor\nGitLab.com's availability. We calculate this by dividing the number of\nsuccessful measurements by the total number of measurements over the\npast 28 days. A measurement could be several things, most commonly a\nrequest handled by our Rails application or a background job.\n\n## Monitoring feature and service availability\n\nFor monitoring GitLab.com we have Grafana dashboards, generated using\n[Grafonnet](https://grafana.github.io/grafonnet-lib/), that show these\nsource metrics in several dimensions. For example, these are error\nrates of our monolithic Rails application, separated by feature:\n\n![Puma SLI by feature](https://about.gitlab.com/images/blogimages/2022-02-share-infrastructure-slis/2022-02-23-puma_sli_per_feature.png)\n\nWe also generate [multiwindow, multi-burn-rate alerts](https://sre.google/workbook/alerting-on-slos/#short_and_long_windows_for_alerting)\nas defined in Google's SRE workbook.\n\n![Puma SLI error rate and requests per second](https://about.gitlab.com/images/blogimages/2022-02-share-infrastructure-slis/2022-02-23-puma_sli.png)\n\nThe red lines represent alerting thresholds for a burn rate. The\nthin threshold means we'll alert if the SLI has spent more than 5%\nof its monthly error budget in the past 6 hours. The thicker\nthreshold means we'll alert when the SLI has not met SLO for more than\n2% of measurements in the past hour.\n\nBecause both GitLab.com's availability number and the availability\nnumber for development groups are sourced by the same metrics, we\ncan provide similar alerts and graphs tailored to the\ndevelopment groups. Features with a relatively low amount of traffic would not easily show\nproblems in our bigger service aggregations. With this mechanism we can see those problems\nand put them on the radar of the teams building those features.\n\n## Building and adoption\n\nIn upcoming posts, we will talk about how we built this tooling and how we worked with other teams to have this adopted into the product prioritization process.\n\n## Related content\n\n- [Our project to provide more detailed data on the stage group dashboards](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/664)\n- [Development documentation for how to change dashboard content](https://docs.gitlab.com/ee/development/stage_group_observability/index.html)\n",[2325,2402,912,9],{"slug":4010,"featured":6,"template":698},"sharing-slis-across-departments","content:en-us:blog:sharing-slis-across-departments.yml","Sharing Slis Across Departments","en-us/blog/sharing-slis-across-departments.yml","en-us/blog/sharing-slis-across-departments",{"_path":4016,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4017,"content":4023,"config":4029,"_id":4031,"_type":13,"title":4018,"_source":15,"_file":4032,"_stem":4033,"_extension":18},"/en-us/blog/situational-leadership-strategy",{"title":4018,"description":4019,"ogTitle":4018,"ogDescription":4019,"noIndex":6,"ogImage":4020,"ogUrl":4021,"ogSiteName":685,"ogType":686,"canonicalUrls":4021,"schema":4022},"Situational Leadership Strategy","GitLab CEO Sid Sijbrandij shares how he incorporates situational leadership in his management style.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679453/Blog/Hero%20Images/remote-work.png","https://about.gitlab.com/blog/situational-leadership-strategy","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Situational Leadership Strategy\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n \"datePublished\": \"2021-11-19\",\n }",{"title":4018,"description":4019,"authors":4024,"heroImage":4020,"date":4026,"body":4027,"category":693,"tags":4028},[4025],"Sid Sijbrandij","2021-11-19","\n \n[Situational Leadership Theory](https://situational.com/blog/the-four-leadership-styles-of-situational-leadership/) is a model created by Paul Hersey and Ken Blanchard in 1969. It describes a leadership style that is adapted to a direct report depending on the unique individual or situation, with no\none style being better than another.\n \nHersey and Blanchard grouped leadership styles into four behaviors:\n \n* **Telling:** The report lacks the skills required to do the job, but is willing to work at it.\n* **Selling:** The report is capable of performing, but is unwilling to do the task.\n* **Participating:** The report is experienced in performing the task, but not confident.\n* **Delegating:** The report is experienced, confident, and takes ownership of the task.\n \nDepending on the individual and the task at hand, it’s necessary to adapt your leadership approach in order to be\nthe most effective leader possible.\n \nI have built on top of this model as I adapt my leadership style based on specific circumstances.\n \nThe following factors inform my approach to managing an individual in a specific situation:\n \n1. **Experience level**: What is the experience level of the report?\n1. **Skills required**: What skills are required to perform the task?\n1. **My own skill**: What skills do I have to perform the task? Should I delegate my weaknesses or strengths?\n1. **Task importance**: What is the importance and priority of the task?\n1. **Task urgency**: How quickly do we need to complete the task?\n1. **Opportunities to provide feedback**: What opportunities are there to provide feedback? Should the feedback be in a group setting or in a 1-1?\n1. **Learning opportunities**: Are others able to learn from doing the task? Does a group setting or live stream help others learn?\n1. **Reporting relationship**: Are they a direct or indirect report? Are they external to the company?\n1. **Time available**: How much time does the report have to perform the task? What is their capacity?\n1. **Time needed**: How much time would it take me to perform the task?\n1. **Current solution**: What is the shortfall of the current solution?\n1. **My emotion**: How much does the shortfall bother me?\n1. **Feedback effort**: How much effort do I need to invest in order to give the feedback?\n1. **Feedback allocation**: How much time is available to provide feedback?\n1. **Previous feedback**: What feedback have they already received regarding the task? Have I already given feedback?\n1. **Team member’s state of mind**: How is the report feeling?\n1. **Metrics**: What data is available to the report as a means of automatic feedback?\n1. **Relationship duration**: How long do I expect to work with this person?\n1. **Resourcing needed**: What resources does the person need to complete the task? Do they have these resources available?\n \nThese are also not complete tradeoffs. A combination of any number of these factors help determine my approach. For example, I may choose to more heavily weight a team member’s state of mind if I know that they recently experienced a personal hardship and the task does not have great urgency--even if I have a high level of emotional engagement.\n \nIt’s important to note that while this list outlines key considerations that inform my management style, it doesn’t mean that I choose the most effective approach in a particular instance. \n \nFor more information on Situational Leadership and you can adapt your own leadership style, check out the book\n[_Management of Organizational Behavior_](https://www.amazon.com/Management-Organizational-Behavior-10th-Hersey/dp/0132556405) by Paul Hersey, Ken Blanchard, and Dewey Johnson.\n",[737,9,912],{"slug":4030,"featured":6,"template":698},"situational-leadership-strategy","content:en-us:blog:situational-leadership-strategy.yml","en-us/blog/situational-leadership-strategy.yml","en-us/blog/situational-leadership-strategy",{"_path":4035,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4036,"content":4042,"config":4046,"_id":4048,"_type":13,"title":4049,"_source":15,"_file":4050,"_stem":4051,"_extension":18},"/en-us/blog/soft-skills-are-the-key-to-your-devops-career-advancement",{"title":4037,"description":4038,"ogTitle":4037,"ogDescription":4038,"noIndex":6,"ogImage":4039,"ogUrl":4040,"ogSiteName":685,"ogType":686,"canonicalUrls":4040,"schema":4041},"Soft skills are the key to your DevOps career advancement","Learn the top soft skills you should invest time in to get a better salary and achieve your career goals.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668185/Blog/Hero%20Images/Chorus_case_study.png","https://about.gitlab.com/blog/soft-skills-are-the-key-to-your-devops-career-advancement","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Soft skills are the key to your DevOps career advancement\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2021-11-30\",\n }",{"title":4037,"description":4038,"authors":4043,"heroImage":4039,"date":2399,"body":4044,"category":693,"tags":4045},[734],"\nIf work in [DevOps](/topics/devops/) and you want to become a DevOps manager, communicate tech needs effectively with executives in the C-Suite, or boost your salary, it’s time to invest in your soft skills.\n\n\"Soft skills should be a huge focus for anyone looking to further their career,” says [PJ Metz](https://gitlab.com/PjMetz), education evangelist at GitLab. “You may be brilliant at the technical aspects of a job, but if you don’t have good interpersonal relationships, you'll get left behind.”\n\nNow, hold on! Just hear me out. I’m not talking about Kumbaya here. No holding hands and dancing under the full moon. Nope. I’m talking about non-technical, yet critical, skills that will enable you to engage with co-workers, especially executives, so their eyes don’t glaze over when you excitedly talk tech. \n\n“You need more than to know the tech really well. You need good leadership and communication skills,” says [Brendan O’Leary](https://gitlab.com/brendan), a staff developer evangelist, and product and engineering leader at GitLab. \n\nThis is particularly true if you want to be promoted to management. “Managers need to understand people and how they work together and what really motivates - and demotivates - people,” O’Leary says.\n\nMetz points to public speaking as another essential skill. “As virtual becomes a standard for meetings and conventions, being able to speak well means conveying your point well,” he says. “It also solidifies you as a leader who can help others understand complicated topics.”\n\nIf you’re going to help the business side of the company understand how DevOps will enable them to be more competitive and make more money, then you need soft skills. If you want that manager position, you need soft skills. If you even want to work better with your DevOps teammates, you need soft skills. Trust me. Knowing this stuff will help you get your tech and career goals accomplished.\n\n## The soft skills focus list\n\nSo what are we talking about when we say soft skills? Here are some examples:\n \n**Communication skills**, including how to talk to colleagues on the business side without using technical jargon or acronyms \n\n**Business understanding** – what does your company need?\n\n**Leadership**, including people management\n\n**Cool under pressure** – can you work calmly and effectively?\n\n**Problem solving**\n\n**Collaboration**: While DevOps is about collaborating to push out better software, you also need to be able to collaborate with people in other departments, like marketing, finance, sales and legal, to improve the business overall.\n\n## Where do you learn soft skills? \n\nCollege courses, journal articles and conference sessions are always a good place to start to learn soft skills. Here are some additional options:\n \nThere are helpful podcasts out there. For instance, check out the “Humans of DevOps” podcast series from the [DevOps Institute](https://www.devopsinstitute.com/resources/), which features episodes such as “Discussing Qualities of Great Leaders” and “Humans are Hard, Code is Easy.”\n\nYouTube has a lot of instructional videos, including “How to Speak With Confidence”, “Business Communication Essentials”, “Collaborative Problem Solving”, and “How to Speak Like an Executive.”\n\n[Coursera](https://www.coursera.org/) also is worth a look. Founded by Stanford University computer science professors, Coursera works with universities and other organizations to offer online courses, certifications and degrees in a variety of subjects.\n\nDon’t forget us right here at GitLab. For instance, [GitLab Learn](https://about.gitlab.com/learn/) offers classes such as “Effective Communication” and “Mastering Self-Motivation and Self-Advocacy.”\n\nLinkedIn also offers classes on business communication.\n\n## The payoff for improving soft skills\n\nYah, we get it. When you think about [ways to up your salary](/blog/four-tips-to-increase-your-devops-salary/) or focus on [continuous education](/blog/best-advice-for-your-devops-career-keep-on-learning/), you think about so-called hard skills, like mastering new programming languages and learning more about security and automation. You forget about, simply ignore or choose not to “waste” time on the soft skills. Then you wonder why you’re not moving up the career ladder, leading a team or making a presentation to the business execs. \n\nThe [2021 Enterprise DevOps Skills Report](https://learn.gitlab.com/devops-institute/2021-doi-devops-upskilling-report?utm_medium=email&utm_source=marketo&utm_campaign=devopsgtm&utm_content=doi-devops-upskilling-report) showed that people skills now are considered a “must have,” with 69 percent of survey respondents ranking human skills as the second-most valuable. Similarly, 68 percent indicated that a DevOps leader must be skilled in empowering\nand developing others.\n\nThe bottom line is if you invest in your soft skills, including learning to speak the language of business, then you’re more likely to achieve your career goals. \n\n",[737,695,9],{"slug":4047,"featured":6,"template":698},"soft-skills-are-the-key-to-your-devops-career-advancement","content:en-us:blog:soft-skills-are-the-key-to-your-devops-career-advancement.yml","Soft Skills Are The Key To Your Devops Career Advancement","en-us/blog/soft-skills-are-the-key-to-your-devops-career-advancement.yml","en-us/blog/soft-skills-are-the-key-to-your-devops-career-advancement",{"_path":4053,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4054,"content":4060,"config":4065,"_id":4067,"_type":13,"title":4068,"_source":15,"_file":4069,"_stem":4070,"_extension":18},"/en-us/blog/start-contributing-to-gitlab-today",{"title":4055,"description":4056,"ogTitle":4055,"ogDescription":4056,"noIndex":6,"ogImage":4057,"ogUrl":4058,"ogSiteName":685,"ogType":686,"canonicalUrls":4058,"schema":4059},"Start contributing to GitLab today","Learn how to start contributing to GitLab and how GitLab team members are here to help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676361/Blog/Hero%20Images/collaboration.jpg","https://about.gitlab.com/blog/start-contributing-to-gitlab-today","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Start contributing to GitLab today\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rémy Coutable\"}],\n \"datePublished\": \"2020-09-30\",\n }",{"title":4055,"description":4056,"authors":4061,"heroImage":4057,"date":3816,"body":4063,"category":716,"tags":4064},[4062],"Rémy Coutable","\n{::options parse_block_html=\"true\" /}\n\nAt GitLab, [everyone can contribute](https://about.gitlab.com/company/mission/#mission). This has been our mission from day\none, since GitLab started as --and is still-- an open-source project.\n\nWe believe that, when consumers become contributors, it benefits everyone: GitLab the product, GitLab the company, GitLab the community\nas well as all GitLab users all around the world.\n\nWe already merged more than 7,700 [“community contribution”](https://gitlab.com/groups/gitlab-org/-/merge_requests?label_name%5B%5D=Community+contribution&state=merged) merge requests from our wider community (at the `gitlab-org` group level).\n\n![Screenshot showing more than 7,700 merged community MRs](https://about.gitlab.com/images/blogimages/2020-09-30-community-contributions.png){: .shadow.medium.center}\n*\u003Csmall>Merge requests from community members not employed by GitLab (aka from the GitLab wider community)\u003C/small>*\n\n## Contributing tracks\n\nNow, it's your turn to contribute and improve GitLab! Since not everyone share the same interests nor competencies, we\nhave multiple tracks to ensure everyone can contribute:\n\n- [Development (new features, bug fixes, performance improvements)](/community/contribute/development/)\n- [Documentation addition, improvements, and fixes](/community/contribute/documentation/)\n- [Translations](/community/contribute/translation/)\n- [UX design](https://about.gitlab.com/community/contribute/ux-design/)\n- [Project templates](/community/contribute/project-templates/)\n\nWhen you're ready, simply choose the track for you and follow the instructions.\n\n## Start small...\n\nTo get familiar with the merge request workflow, I advise you start small.\n[Fixing a typo](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42447) or\n[adding a comma](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43021) in the documentation are small yet awesome\ncontributions that are usually merged in a matter of hours. These are awesome to gear up and get the ball rolling.\n\nFor more examples, be sure to take a look at the [community merge requests that touched GitLab documentation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?state=merged&label_name[]=documentation&label_name[]=Community%20contribution).\n\nThese kind of changes don't require a lot of time from you, but if you have more time and are ready to tackle bigger challenges,\nyou can start looking for [bugs](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=Accepting+merge+requests&label_name[]=type::bug&scope=all&sort=popularity&state=opened)\nor [feature proposals](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20merge%20requests&label_name[]=feature).\n\n## ...and end up MVP\n\nEvery contribution is a collaborative effort between the merge request author, the reviewer(s), potentially MR coaches, and the maintainer (who gets to merge the MR).\n\nSome contributions are so complex and technical that they take months of collaboration to get accross the finish line!\n\nLet's give you a few examples of great collaborative efforts that happened in the last 12 months:\n\n1. [Cédric Tabin](https://gitlab.com/ctabin) worked for more than 9 months contributing\n [a new CI job keyword allowing interruptible builds](/releases/2019/09/22/gitlab-12-3-released/#interruptible-keyword-to-indicate-if-a-job-can-be-safely-canceled)\n and working with the GitLab teams to get it across the line. The [merge request](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23464) involved 51 people, who posted 405 discussion notes!\n This contribution was released in GitLab 12.3, and allows to save a lot of money by avoiding running redundant pipelines.\n1. [Tuomo Ala-Vannesluoma](https://gitlab.com/tuomoa) worked for 7 months adding support for\n [previewing artifacts that are not public](/releases/2019/10/22/gitlab-12-4-released/#private-project-support-for-online-view-of-html-artifacts), a highly requested feature with almost 300 upvotes!\n The [merge request](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/134) landed in GitLab 12.4, and received two 🍾 emoji votes.\n1. [Roger Meier](https://gitlab.com/bufferoverflow) worked for more than 4 months contributing\n [support for S/MIME Signature Verification of Commits](/releases/2020/02/22/gitlab-12-8-released/#smime-signature-verification-of-commits), an important feature for sensitive projects and in regulated industries.\n Roger's teammate, [Henning Schild](https://gitlab.com/henning-schild), contributed the change upstream to Git and Roger made the change in GitLab.\n The [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17773) involved 42 people, who posted 430 discussion notes, and landed in GitLab 12.8.\n1. [Steve Exley](https://gitlab.com/steve.exley) worked for more than 5 months contributing one of\n [the biggest architectural changes to the Docker executor](/releases/2020/03/22/gitlab-12-9-released/#gitlab-runner-129).\n that solved multiple issues for the Docker executor, including [jobs sharing the same network bridge](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4430),\n [services don't work when `network_mode` is specified](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2699),\n and lastly, services can connect to one another and connect with the build container as well!\n The [merge request](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1569) involved 69 people, who posted 293 discussion notes. It landed in GitLab 12.9, and received five 🔥 emoji votes.\n1. [Jesse Hall](https://gitlab.com/jessehall3) worked for more than 5 months contributing one of\n [the Batch Suggestions feature](/releases/2020/07/22/gitlab-13-2-released/#batch-suggestions) which allows MR reviewers to group all suggestions made to a diff and submit them at once.\n Because each suggestion translates into a Git operation, submitting these individually could take a long time if there were a large number of suggestions. Submitting suggestions in batches has numerous advantages, including time savings, efficient CI resource utilization (only one pipeline for all suggestions), and preventing an overly noisy Git history.\n The [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/22439) involved 38 people, who posted 358 discussion notes. It landed in GitLab 13.2, and received seven 💚 emoji votes.\n\n## Get some help from the GitLab team\n\nIf you need any help while contributing to GitLab, below are some of the resources that are available.\n\n1. Ask questions on the [Contributors Gitter Channel](https://gitter.im/gitlabhq/contributors).\n1. Get in touch with [Merge Request Coaches](https://handbook.gitlab.com/job-families/expert/merge-request-coach/). To find a merge request coach, go to the GitLab Team Page and search for \"Merge Request Coach\".\n You can also mention Merge Request Coaches by typing `@gitlab-org/coaches` in a comment.\n1. Find reviewers & maintainers of Gitlab projects in our [handbook](/handbook/engineering/projects/#gitlab) and [mention](https://docs.gitlab.com/ee/user/group/subgroups/#mentioning-subgroups) them in a comment.\n1. If you have feature ideas/questions, you can search for existing issues or create a new issue if there isn't one already. Feel free to [mention](https://docs.gitlab.com/ee/user/group/subgroups/#mentioning-subgroups) [product team members](https://handbook.gitlab.com/handbook/product/categories/) in the issue.\n\nWait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request.\nYou may also need multiple reviews depending on the size of the change.\nIf you don't hear from anyone in a timely manner, feel free to find reviewers or reach out to Merge Request Coaches.\nPlease don't be shy about [mentioning](https://docs.gitlab.com/ee/user/project/issues/index.html)\nGitLab team members in your merge requests as all team members are expected to be responsive to fellow community members.\n\n## How we stay on top of community contributions\n\nIn Q3 of 2020, several GitLab teams are focusing on improving the experience for community contributors. To achieve this goal,\nwe created a few metrics around community contributions:\n\n* [Community Contribution Mean Time to Merge](/handbook/engineering/quality/performance-indicators/#community-contribution-mean-time-to-merge)\n* [Unique Community Contributors per Month](/handbook/engineering/quality/performance-indicators/#unique-community-contributors-per-month)\n* [Community MR Coaches per Month](/handbook/engineering/quality/performance-indicators/#community-mr-coaches-per-month)\n\nTo make sure the GitLab team is working hand in hand with the wider community in a timely fashion, we've already put a few automations in place:\n\n1. Every hour, wider community contributions are automatically [labelled \"Community contribution\"](/handbook/engineering/quality/triage-operations/#community-contributions).\n1. Every day, a report with the [untriaged](/handbook/engineering/quality/merge-request-triage/) community merge requests is created and assigned to the Merge Request Coaches for triage. This ensures each merge request has a [stage and group](https://handbook.gitlab.com/handbook/product/categories/#hierarchy) labels set.\n1. Every two weeks, a report with unassigned and idle community contributions is created for each [group](https://handbook.gitlab.com/handbook/product/categories/#hierarchy).\n\nThese automations are powered by our [`triage-ops` project](https://gitlab.com/gitlab-org/quality/triage-ops/) and are documented in [Triage Operations](/handbook/engineering/quality/triage-operations/).\n\nI hope this post convinced you to start contributing to GitLab. Keep in mind, any contribution is valuable, and don't worry, we're here to support you.\n\nCover image: [\"Żuki leśne na liściu jesienią\"](https://unsplash.com/photos/5S2xIoNpcGk) by [Krzysztof Niewolny](https://unsplash.com/@epan5).\n{: .note}\n",[9,268,1285,934,787],{"slug":4066,"featured":6,"template":698},"start-contributing-to-gitlab-today","content:en-us:blog:start-contributing-to-gitlab-today.yml","Start Contributing To Gitlab Today","en-us/blog/start-contributing-to-gitlab-today.yml","en-us/blog/start-contributing-to-gitlab-today",{"_path":4072,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4073,"content":4079,"config":4085,"_id":4087,"_type":13,"title":4088,"_source":15,"_file":4089,"_stem":4090,"_extension":18},"/en-us/blog/starting-from-the-start-slippers-design-system",{"title":4074,"description":4075,"ogTitle":4074,"ogDescription":4075,"noIndex":6,"ogImage":4076,"ogUrl":4077,"ogSiteName":685,"ogType":686,"canonicalUrls":4077,"schema":4078},"Why design systems benefit everyone","Learn how the GitLab digital experience team built the Slippers design system for our marketing website.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679537/Blog/Hero%20Images/slippers-sys.jpg","https://about.gitlab.com/blog/starting-from-the-start-slippers-design-system","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why design systems benefit everyone\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Stephen McGuinness\"}],\n \"datePublished\": \"2021-03-05\",\n }",{"title":4074,"description":4075,"authors":4080,"heroImage":4076,"date":4082,"body":4083,"category":1053,"tags":4084},[4081],"Stephen McGuinness","2021-03-05","\n\nThe [Digital Experience team](/handbook/marketing/digital-experience/) is new at GitLab, but we spent the past few months [creating Slippers, a new design system, which is a centralized location for design assets and code](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui). This blog post explains how we managed to build a design system in record time and accounts for how we overcame some of the challenges we encountered along the way.\n\nWe built Slippers because we needed a design system that we could rapidly iterate on and that would scale. We needed to use technologies that offered a single source of truth so our growing team could build on the repo. This process is not without its frustrations – what can work for one team might not work for the entire marketing department. In the past, discrepancies in design would happen because we didn't have a style guide.\n\nFortunately, creating a system that can respond to quick iterations can provide a solution to this complex problem. But \"simple\" in this case is misleading. We needed a new way of thinking and working. It is not enough to create a UI kit of consistent design assets for your designers to work with, doing this alone will fall at the first hurdle if it is not reflected in a coded repo. Designs will produce variations over time. Technical and design debt builds up due to small changes made over time and you end up where you started – with fragmented design and code.\n\nTime and effort as well as a vision are necessary to create a design system solution. This is the place our new team was at near the end of 2020. An already bizarre year for many, this was a great time to create a team to tackle this technical challenge head-on.\n\n## Why design systems are for everyone\n\nA common misconception of a design system is that it is for designers. You create a UI kit, hand it to developers, and you are off to the races. While a UI kit is important to the success of a system, it is just one part of what is a technical and efficient product.\n\nOur goal was to create a reusable library of assets, which included design assets (typestack, colors, spacing, grid, buttons, etc.) along with documentation on usage criteria. This is a big project that requires a lot of effort. First, we aligned around a common vision and product architecture. I want to emphasize \"product\" because this system acts as a product serving multiple teams across GitLab. Next, we rallied our team around a common goal and got to work. Our team established a set of guiding principles that would always act as our anchor for the project. [You can read more about them here](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui).\n\n*\"The more decisions you put off, and the longer you delay them, the more expensive they become.\"*\n\n**―[Craig Villamor](https://www.linkedin.com/in/craigvillamor), senior design director of Google Maps**\n\nWe found this quote from Craig in a [Medium post about the benefits of design systems](https://medium.com/agileactors/7-quotes-about-design-systems-that-will-inspire-you-9a89557fb26f). His remarks describe the dangers of putting off building a design system for too long. The fact is, the longer you design without a clear system and rubric, the more tech and design debt accumulates.\n\n## How we built the design system\n\nProducts exist to solve problems, so we articulated our vision with working sessions. The sessions were a platform for aligning our vision based on what we considered maintainable design and technology.\n\nOnce we aligned on our guiding principles we set about creating a roadmap. Our team decided how we wanted our product to be built, and agreed on tooling, tech stacks, and a cadence of delivery during our working sessions.\n\nWe decided on Figma for design since this was already being used within GitLab. Next, we created our core elements along with some [baseline components such as type, color, and spacing for the design system](https://www.figma.com/file/nWIOpmuMp7RZXmfTj6ujAF/Slippers_foundations?node-id=1292%3A573). We used existing pages as templates to refactor and give us a broader idea of what was and was not working. This process gave our developers time to investigate the best way to code our product and determine what shape it would take.\n\n## The value of a shared language\n\nOur engineering team started working on our tech stack and our designers started to work on what we called our \"foundations\". This can also be referred to as \"elements\". We did this in a way so we could stress-test our foundations package by refactoring existing pages with new styles that gave us an idea of the direction of our design system.\n\nNext, we applied these core elements to a select sample of pages to act as a proof of concept. We chose to edit the [homepage](https://about.gitlab.com/), [enterprise page](/enterprise/), [pricing page](/pricing/), and [entire GitLab Blog section](/blog/). We identified pain points and apply stop-gaps along the way. Since we are [results-driven](https://handbook.gitlab.com/handbook/values/#results), we used local CSS (Cascading Style Sheets) tightly coupled to the site itself. The perk of this approach is that you can deliver results quickly. After doing some UX and UI refinements on these pages, introducing new technology was easier because each of the pages are actively maintained. We used this time to learn and apply this practice to improve the system.\n\n## What's next\n\nThough the Digital Experience team has only been established for four months we've made huge inroads. We are starting to see how the Slippers design system will look once it is implemented across the entire organization.\n\nBuilding the Slippers design system is an example of a research and development (R&D) project. By laying out these foundations, we are set up for large-scale learning and success. The team is continuously gathering data for this R&D project and using it to better inform and refine our design system.\n\nAlso, since GitLab is open source, we are factoring open source values into our Slippers roadmap. We do this through posting our video updates to our partners and [public YouTube videos](https://www.youtube.com/c/GitLabUnfiltered/featured).\n\nThe reality is, this work takes time and investment. There is a herculean effort still left for us to bring the system fully to life. But already we have demonstrated the value of a design system to our leadership by delivering more than 2000 new CMS pages.\n\nEven at this very early stage the Slippers project has been rewarding and provides us with a continuous source of valuable insights. We're encouraged to push the boundaries and take calculated risks in what we learn and what we do.\n\nStay up-to-speed on our progress by checking out our [Slippers project](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui) and [watching our team videos on GitLab Unfiltered](https://www.youtube.com/c/GitLabUnfiltered/featured).\n\nCover photo by [Nihal Demirci](https://unsplash.com/@nihaldemirci?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/0ME-BIUBmUs)\n{: .note}\n",[9,934,1098,1099],{"slug":4086,"featured":6,"template":698},"starting-from-the-start-slippers-design-system","content:en-us:blog:starting-from-the-start-slippers-design-system.yml","Starting From The Start Slippers Design System","en-us/blog/starting-from-the-start-slippers-design-system.yml","en-us/blog/starting-from-the-start-slippers-design-system",{"_path":4092,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4093,"content":4099,"config":4104,"_id":4106,"_type":13,"title":4107,"_source":15,"_file":4108,"_stem":4109,"_extension":18},"/en-us/blog/startup-covid-tracking",{"title":4094,"description":4095,"ogTitle":4094,"ogDescription":4095,"noIndex":6,"ogImage":4096,"ogUrl":4097,"ogSiteName":685,"ogType":686,"canonicalUrls":4097,"schema":4098},"How an analytics software startup took aim at COVID-19","Illumina Consulting Group didn’t just sit idle during the pandemic. Here’s how they developed a COVID-19 assessment and analysis tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681320/Blog/Hero%20Images/startupcovid.jpg","https://about.gitlab.com/blog/startup-covid-tracking","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How an analytics software startup took aim at COVID-19\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2020-05-15\",\n }",{"title":4094,"description":4095,"authors":4100,"heroImage":4096,"date":4101,"body":4102,"category":784,"tags":4103},[846],"2020-05-15","\n\n_In the second of our irregular series on [the intersection of technology and COVID-19](/blog/cobol-programmer-shortage/), here’s a look at how one small software company changed gears to create a tool for symptom tracking._\n\nWe’ve heard a lot about companies around the world moving from [toy production to personal protective equipment](https://sports.yahoo.com/toy-companies-switch-gears-help-022919242.html), or switching gears from [making gin to making hand sanitizer](https://www.bbc.com/worklife/article/20200413-how-factories-change-production-to-quickly-fight-coronavirus).\n\nBut how about companies that have contributed in a more subtle way?\n\n[Illumina Consulting Group](https://icgsolutions.com/) is a Maryland-based data analytics software startup that does most of its work for the intelligence community. Suffice it to say about two months ago the team found themselves with time on their hands, says CEO David Waldrop. \"ICG has a very potent team of developers,\" he explains. \"So when this COVID thing kind of happened, we were sitting around trying to figure out what to do for the next eight weeks or longer sitting at home like groundhog day, with every day the same as the next. How could we help with this COVID thing with our skillset? We build software, that's what we do for a living.\" (For the record ICG is a GitLab customer, but this isn’t a post about that.)\n\nWaldrop’s team defined the requirements and concluded the biggest problem with this very contagious virus is a shortage of primary information. \"Who's really got the disease and how early in the process can we detect them?\" he asks. \"And the answer to that is pretty straightforward. Who's the person who knows if they've got the disease? Every person that's out there that's got a nose and ears and eyes that might have a sniffle and a fever. And so how could we get that information from those people? What if we just asked them?\"\n\nAnd with that simple thought process, a symptom assessment tool, [DoIhaveit.net](https://doihaveit.net/home#home), was born. The tool offers users both a snapshot of COVID-19 in their area (based on zip code) and asks them to take a quick two minute health survey. Using the results of that data, DoIhaveit (or DIHI as they call it) offers advice straight from the Centers for Disease Control. The survey is anonymous – it does not collect personal identifying information or private health data.\n\n![DoIhaveit.net home page](https://about.gitlab.com/images/blogimages/doihaveitscreenshot.png){: .shadow.medium.center.wrap-text}\n\nWaldrop admits the team was skeptical at first about the idea of people being willing to contribute their experiences. But \"everybody's got a mother or a grandmother or an older uncle or somebody,\" he says. \"When that person goes to the hospital, they want there to be a bed and a ventilator and gowns and all that stuff available.\"\n\nTo meet those needs ICG built DoIhaveit with a frontend survey piece and a backend that will aggregate and analyze the data down to the zip code level. \"We made it so the messaging at the assessment and the summary level can be jurisdictionally specific down to the zip code if necessary,\" he says. The team wanted it to be flexible for wherever the cycle takes an area from flattened curve to rising cases and to be modifiable by a public health or safety team that might want to adjust the parameters on the fly.\n\nAnd that’s the real point of DoIhaveit, Waldrop says – to make sure doctors and hospital systems are prepared for a potential onslaught. \"We built this as a public service and it’s ready to go.\" It’s in use in Virginia and the company wants to spread the word across the country. It’s completely free of charge for municipalities and Waldrop stresses ICG isn’t making any money from this. \"We hope to get this into as many hands as possible.\"\n\nCover image by [Centers for Disease Control](https://unsplash.com/@cdc) on [Unsplash](https://unsplash.com)\n{: .note}\n",[9,268,1285],{"slug":4105,"featured":6,"template":698},"startup-covid-tracking","content:en-us:blog:startup-covid-tracking.yml","Startup Covid Tracking","en-us/blog/startup-covid-tracking.yml","en-us/blog/startup-covid-tracking",{"_path":4111,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4112,"content":4118,"config":4123,"_id":4125,"_type":13,"title":4126,"_source":15,"_file":4127,"_stem":4128,"_extension":18},"/en-us/blog/stem-gems-give-girls-role-models",{"title":4113,"description":4114,"ogTitle":4113,"ogDescription":4114,"noIndex":6,"ogImage":4115,"ogUrl":4116,"ogSiteName":685,"ogType":686,"canonicalUrls":4116,"schema":4117},"GitLab + STEM Gems: Giving girls role models in tech","Meet the GitLab team-members working to inspire the next generation to pursue careers in STEM.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672357/Blog/Hero%20Images/stem-gems.png","https://about.gitlab.com/blog/stem-gems-give-girls-role-models","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab + STEM Gems: Giving girls role models in tech\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Stephanie Garza\"}],\n \"datePublished\": \"2018-10-08\",\n }",{"title":4113,"description":4114,"authors":4119,"heroImage":4115,"date":1868,"body":4121,"category":910,"tags":4122},[4120],"Stephanie Garza","\n\nGitLab recently partnered with [STEM Gems](http://stemgemsbook.com/), an organization creating awareness of successful women in STEM, to inspire girls and give them STEM role models. **STEM** (Science, Technology, Engineering, and Mathematics) pervades every aspect of our lives; everything can be tied to technology in some way, shape, or form. Given the constant expansion of technology, career prospects are endless. One would think STEM is the number one pursued career path right?\n\nSurprisingly, according to the US Department of Commerce, in 2017 only 24 percent of women worked in STEM. Another harsh reality is that women who hold STEM degrees are less likely than their male counterparts to pursue a STEM career. In fact, women are more likely to work in education or healthcare.\n\nDriven by the low numbers, STEM Education advocate Stephanie Espy strived to make a change. Espy created STEM Gems, an organization that began as a book filled with inspiring women in STEM. The book was the stepping stone for a greater initiative to create awareness for the successful female powerhouses in STEM, as well as provide girls with role models to look up to.\n\nGirls who have STEM role models are more likely to pursue opportunities outside their traditional realm, and STEM Gems is making it possible for girls to connect with them. Role models, mentors, and career ambassadors inspire and empower girls to achieve their dreams.\n\nAt [our recent summit in South Africa](/blog/gitlab-summit-cape-town-recap/), forty GitLab team-members came together for an epic power hour of delving into each other's professional pathways and identifying challenges. Participants were paired up and asked to interview each other about their individual careers, goals, and accomplishments. This included the significant others of GitLab team-members and men interested in learning more about making GitLab inclusive. Through this event, we were able to strengthen our relationships and identify ways to foster a culture of inclusion. The event also provided greater visibility into the challenges and barriers women in STEM face.\n\nGitLab is building a community where everyone can thrive. We've gathered together the stories and photos of the GitLab team-members that participated in the event. In this post, and in a follow-up post, we will share each of these amazing stories. We want to inspire and encourage girls to set Big Goals and pursue every dream and remember you’ll always have a friend at GitLab!\n\n![Jenny and Molly](https://about.gitlab.com/images/blogimages/stem-gems/jenny.jpg){: .shadow.small.left.wrap-text}\n\n**Name:** [Jenny Nguyen](/company/team/#lankhanh28) (right)\n\n**Role:** Payroll and Payments Lead\n\n**Why is what you do important?**\nI handle payroll and expense reimbursement, making sure all our team members get paid and reimbursed on time.\n\n**What is something you are really proud of?**\n\nI helped save a previous company $2 million by applying technical logic to processes.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nNo, I started my undergrad with Business major and took programming as an elective class. My teacher encouraged me to change my major to Computer Science and Software Engineering, but I didn't have an opportunity to be in a technical position. However, I have applied my technical knowledge and aptitude from school to reduce manual processes within my functions for the past 10 years.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nAs a non-technical person, I want them to know that they don’t have to have a career in technology to have and utilize their own technical skills. Every function needs input from technical and non-technical perspectives.\n\n----\n\n![Ramya](https://about.gitlab.com/images/blogimages/stem-gems/ramya-authappan.png){: .shadow.small.right.wrap-text}\n\n**Name:** [Ramya Authappan](/company/team/#atramya)\n\n**Title:** Senior Test Automation Engineer\n\n**Why is what you do important?**\n\nAt GitLab, I automate tests as much as possible. I design and develop test frameworks. Test automation is the key to Continuous Integration and Delivery, which in turn is essential in minimizing the 'Time to Market' of any new features, thereby achieving customer satisfaction.\n\n**What is something you are really proud of?**\n\nApart from my work at GitLab, I'm also the Director of [Women Who Code](https://www.womenwhocode.com/), Chennai chapter. As part of Women Who Code, I get to meet a lot of female leaders in the technical space. I was recently invited to be a Panelist in a discussion on digital safety help by Google and SheThePeople.tv. I was also [interviewed by a Indian National News channel](https://www.thenewsminute.com/article/women-tech-freshworks-ramya-authappan-importance-mother-friendly-workplaces-78893). I frequently share my knowledge as a conference/meetup speaker. On the whole, I love doing what I do and being who I am!\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nYes! In my school days I had to choose a specialization at the age of 16 years. I chose Computer Science, and I think I made the right choice. I find that I'm interested in software engineering and always wanted to be a software engineer.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\n1. Choose wisely when it comes to specializations.\n2. Keep learning.\n3. Give back to society.\n4. Change the world! The sky is the limit!\n\n----\n\n![Hannah](https://about.gitlab.com/images/blogimages/stem-gems/hannah-schuler.png){: .shadow.left.small.wrap-text}\n\n**Name:** [Hannah Schuler](/company/team/#hannahschuler8)\n\n**Title:** SDR Team Lead – West and APAC\n\n**Why is what you do important?**\n\nI train other SDR team members to identify and create qualified opportunities. I also assist in recruiting team members and also work closely with online marketing managers for targeted ad campaigns. The SDR role is an evangelist role – we get the opportunity to be the first point of contact for people. It's an exciting and challenging role because most often people have never heard of GitLab. Sharing news about a solution that can help people and bring value is exciting.\n\nMy role is important because I facilitate and add structure to the team. I help remove roadblocks and enable us to work more efficiently. I help team members reach their full potential.\n\n**What is something you are really proud of?**\n\nI received a discretionary bonus a few months ago for going above and beyond in my role! Being promoted from an SDR representative to a team lead in nine months was really awesome, I'm very proud of that. I'm a certified SCRUM master and product owner. I am also certified in SAFE (Agile methodology).\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nIt's evolved over time – when I was little I wanted to be a ballerina. I was super shy, an introvert, and dancing was my way to express myself. When I grew older, everything changed and I become super outgoing. I wanted to make an impact in the world and got a degree in International Business Studies because I wanted to work for the UN. My excitement for technology came a lot later in my career. My friend shared excitement about the industry and that's what initially got my foot in the door. I did not have a traditional background in tech.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nYou will have an impact in this field. Companies are looking for you. You will develop lifelong skills and have an impact in this field. Women are trailblazers in this industry. You can dictate your own earning potential and will have the opportunity to mentor other women as well.\n\n----\n\n![Cristine](https://about.gitlab.com/images/blogimages/stem-gems/cristine-marquardt.png){: .shadow.small.right.wrap-text}\n\n**Name:** [Cristine Marquardt](/company/team/#csotomango)\n\n**Title:** Billing Specialist\n\n**Why is what you do important?**\n\nI process invoices for sales-assisted orders, troubleshoot support tickets (mostly related to money and licensing issues), provide sales support, and I wear a lot of hats. Everyone in the company plays an important role to keep GitLab running. When you work at a startup, you have to be game for all the obstacles that are thrown your way. I never imagined how much I would learn and how much I could contribute in my role.\n\n**What is something you are really proud of?**\n\nI'm currently dabbling in .Net framework and I made my first semi-functional calculator. While this sounds like a rather simple task, this is huge to me since my career has been focused in the finance and accounting world.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nI knew that I wanted to work in tech ever since I was a kid. I was fortunate enough to go to a school that had computers in each classroom and there was also a computer lab. I wanted to get into computer engineering when I was in middle/high school, but I never pursued it in college. I'm now pushing myself to learn software development.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nBelieve in yourself and don't be afraid. The only one holding you back is yourself.\n\n----\n\n![Gabriela and Diana](https://about.gitlab.com/images/blogimages/stem-gems/gabriela.jpg){: .shadow.small.right.wrap-text}\n\n**Name:** Gabriela Mena Breña (right)\n\n**Title:** Chemical Engineer (Not at GitLab, I am the significant other of a GitLab team-member)\n\n**Why is what you do important?**\n\nPractical transition from fossil fuels to renewable energy solutions. This will save the planet!\n\n**What is something you are really proud of?**\n\nI led the team that created fiscal terms for the first private investments in Mexican oil and gas resources. This protected the Mexican government's financial stability. We secured $3.1 billion worth of contracts to construct gas pipelines for the Mexican state. I am also proud to have received a full scholarship from the Mexican government to study for a Master's degree in Energy Science.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nYes, I found science and math the most challenging, which made them the most interesting to me.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nDon't let anybody else tell you what you can be. Be true to who you really are and focus on your own goals and desires.\n\n----\n\n![Chloe](https://about.gitlab.com/images/blogimages/stem-gems/chloe-whitestone.jpg){: .shadow.small.left.wrap-text}\n\n**Name:** [Chloe Whitestone](/company/team/#drachanya)\n\n**Title:** Talent Operations Specialist\n\n**Why is what you do important?**\n\nI am part of the recruiting team. I do all of the backend operations for recruiting, such as vendor management, reporting, researching on different tools, and employee branding. In addition, I am also the recruiter for a few roles (customer success, UX designer, data engineer). GitLab cannot be what it is without having great talent and I get to be a part of this exciting journey.\n\n**What is something you are really proud of?**\n\nI've played a critical role in the multiple transitions of GitLab's ATS (application tracking system) which has improved candidate experience, increased efficiency, and given greater visibility for hiring managers to hire the best talent possible. Before I was at GitLab, there weren't any tools for recruiting metrics. Through my efforts, GitLab has recruiting metrics and is now able to analyze how they are doing compared to other industry leaders. This has allowed us to improve the hiring process and enabled applicants to get job offers faster than before.\n\n**Chloe also:**\n\n- Migrated Workable to Lever\n- Migrated Lever to Greenhouse\n- Implemented background checks at GitLab\n- Trained GitLab team-members for Greenhouse\n- Created a vacancy process for GitLab\n- Improved onboarding process and experience\n- Became an assistant manager in six months during her first fulltime job\n- Is proud of every hire she has made\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nGrowing up, I didn't think I would work in Tech. I originally wanted to be president! I was exposed to tech through my high school STEM program. That equipped me to be where I am today.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nStart right away by learning and getting involved in the community. It's harder to start the older you get (IMO). Don't be afraid, no matter how much experience you have or how old you are. You are not alone!\n\n----\n\n![Katherine](https://about.gitlab.com/images/blogimages/stem-gems/katherine-okpara.jpg){: .shadow.small.right.wrap-text}\n\n**Name:** [Katherine Okpara](/company/team/#katokpara)\n\n**Title:** Junior UX Researcher\n\n**Why is what you do important?**\n\nI work with product management and UX designers to understand users' pain points, goals, and needs. My job is to understand where we can improve the product by speaking directly to users. The user experience of a product impacts the customer directly. Positive experiences equal stronger relationships (more feedback) for the product to improve.\n\n**What is something you are really proud of?**\n\nI've received mentorship during my eight months here at GitLab and am now leading studies. I've been able to learn about different features and different aspects of the product at a fast pace. I have helped to build healthy relationships between end users and teams for better product improvements/advancements.\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nNo. I didn't know anything about tech/computers, etc. until college. I took a few programming/data science classes in college and that's when my interest was piqued. I was on more of an academic path at school (psychology). In my last year of college I took a web design class (applying research to products) and felt that I had found my niche. I have been working on those skills ever since through online courses, research, etc.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nThere is a place for you! Whether it's programming or another area, there are still many paths for consideration. If you come from a non-traditional path, there is always a way to link your skills to your desired role. Believe that you can do it, even if you don't currently have the skills (you can build those skills!).\n\n----\n\n![Lucas](https://about.gitlab.com/images/blogimages/stem-gems/lucas.jpg){: .shadow.small.left.wrap-text}\n\n**Name:** Lucas Charles\n\n**Title:** Individual Contributor to Gitlab (significant other to a GitLab team-member)\n\n**Why is what you do important?**\n\nI am an end-user, and GitLab wouldn't be a product without users. It's built on open source technology, which requires everyone to contribute. As a user and contributor, it is powerful to have everything in one place and GitLab is fun to use. It's easier to go to work every day with software you love.\n\nMy significant other works at GitLab, but I would use it every day regardless. I love the product and company. I think GitLab is doing something important and changing the way we build software.\n\n**What is something you are really proud of?**\n\nWhen my significant other was looking for a new job, I realized that GitLab would be a perfect fit for her and encouraged her to apply. I wanted to do everything I could to help her because I care and it's an amazing opportunity to push herself and contribute to a greater tech community full of diverse people, product, and cultures.\n\nI'm incredibly proud of my significant other. She works on GitLab every day, making the world a more interesting place through technology. I'm quite proud to be part of that network. I'm also proud to be one of the first 1,000 contributors to Gitlab. I'm proud that GitLab chose to recognize that by sending me a special sticker!\n\n**Did you know you wanted to work in tech when you were growing up? If not, what did you THINK you wanted to be?**\n\nI've always been a tinkerer and like to take things apart and put them together. Tech enables me to do that quickly and easily. It is an amazing industry that creates something out of nothing but an idea, and has limitless possibilities. We move fast and many truly believe they are changing the world.\n\n**If you could give advice to a girl thinking about a career in tech, what would it be?**\n\nFirst, to just do it, because it's an incredible field and we need more diversity. Diversity is important: we need a range of ideas, perspectives, and to create more opportunities to understand each other. We should build products that work for everyone and address all needs. Challenging ourselves and growing ourselves through different perspectives is critical for both personal growth and a healthy culture.\n",[737,268,9,934,1097],{"slug":4124,"featured":6,"template":698},"stem-gems-give-girls-role-models","content:en-us:blog:stem-gems-give-girls-role-models.yml","Stem Gems Give Girls Role Models","en-us/blog/stem-gems-give-girls-role-models.yml","en-us/blog/stem-gems-give-girls-role-models",{"_path":4130,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4131,"content":4136,"config":4140,"_id":4142,"_type":13,"title":4143,"_source":15,"_file":4144,"_stem":4145,"_extension":18},"/en-us/blog/strategies-to-reduce-cycle-times",{"title":4132,"description":4133,"ogTitle":4132,"ogDescription":4133,"noIndex":6,"ogImage":2997,"ogUrl":4134,"ogSiteName":685,"ogType":686,"canonicalUrls":4134,"schema":4135},"10 strategies for cycle time reduction","Engineering leads share strategies on how to speed up cycle times.","https://about.gitlab.com/blog/strategies-to-reduce-cycle-times","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"10 strategies for cycle time reduction\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n \"datePublished\": \"2018-10-12\",\n }",{"title":4132,"description":4133,"authors":4137,"heroImage":2997,"date":1260,"body":4138,"category":1053,"tags":4139},[951],"\n\nEvery product manager appreciates shorter cycle times. One way to reduce cycle\ntimes is to learn from others, so five of our engineering leads share the greatest\nchallenges their teams have experienced and offer the strategies they developed\nto speed up iteration.\n\n>“The impact of shorter cycle times is that users can see the result of their\ninput quickly. Instead of contributing to the planning process and then waiting\nfor weeks to see the feature start to take shape, they can regularly see changes,\nmaking them happy and keeping them engaged with a team. This also helps reduce\nthe scope creep that happens when a project has been in progress for a while.” – Rachel Nienaber\n\n## What's the average cycle time for development teams?\n\nAccording to the [Accelerate State of DevOps Report](https://www.hatica.io/blog/cycle-time/#:~:text=The%20Accelerate%20State%20of%20DevOps,cycle%20time%20of%206.2%20days), the average cycle time for top-performing teams is about 2 days, with the median for most teams being about 3.5 days. However, some development teams [report their average cycle times](https://linearb.io/blog/how-to-reduce-cycle-time-in-software-delivery/) as being as much as 7 days. Teams can calculate this by evaluating how long several types of fixes take from start to finish.\n\n## What are some cycle time challenges?\n\nEvery team has processes and steps that increase cycle delivery time. A shorter and faster time to market empowers teams to fulfill customer demands and exceed their expectations. Here are a few of\nthe ones we’ve dealt with in recent past.\n\n### Getting it right the first time\n\nWhen developing new features, we want to ensure that things don’t break when it\ngets to a user. Because of our monthly release cycle, users could be stuck with\na broken feature until the following month, causing frustration and decreasing\nthe value that GitLab brings to its users. So, it’s important that we test and\nship with certainty. [Marin Jankovski](/company/team/#maxlazio), Engineering Manager of\nthe Distribution & Release Management teams, and [Sean McGivern](/company/team/#mcgivernsa),\nEngineering Manager of the Plan team, note the importance of testing and shipping features.\n\n\n>“Finding a way to test changes faster can be challenging. With the Distribution\nteam, we have the responsibility of ensuring that the release we ship still\nfunctions after we make our changes and that users can still install and use GitLab.”\n– Marin Jankovski\n\n>“Our release process is a big challenge, if you consider that the cycle ends\nonce customers have the feature available to use. We don’t have CD for\nGitLab.com, but even if we did, for self-managed customers, we only have one\nfeature release a month. So, that’s a hard limit.” – Sean McGivern\n\n### Differentiating the helpful from the unhelpful\n\nEvery workflow has components that can decrease release cycles, including code\nreviews, manual configuration and testing, and hand-offs. Some of these elements\nare necessary, like product manager meetings, but other aspects can unintentionally\ncause problems. [Tommy Morgan](/company/team/#itstommymorgan), Director of Engineering of\nDev Backend, highlights the essential measures that teams need to take to promote\ncollaboration and alignment but may increase cycle times.\n\n\n>“Teams have all these things that are slowing down cycle times, and there could\nbe extra steps or extra involvement that aren’t necessary or beneficial and that\ncould unintentionally add pressure to the team to slow down. One of the biggest\nchallenges is identifying which ones are legitimate and helpful and which ones\nare us giving into the natural urge to add process. Identifying across that fine\nline is where the real challenge comes into play for most teams.”\n\n### Working across teams\n\nCross-collaboration fosters innovative thinking and allows each team to specialize\nin a specific area to maximize contributions. While the benefits of working with\nmultiple teams are abundant, depending on another team’s feedback or assistance\nslows down development, especially when there’s a blocker that can only be resolved\nwith the help of one team. [Rachel Nienaber](/company/team/#rachel-nienaber), Engineering\nManager of the Geo team, and Marin agree that working across teams can have\nsignificant impact on cycle times.\n\n\n>“When other teams implement a new feature that needs some additional work from\nthe Distribution side, getting informed in time is extremely important. We need\nto affect the decision as early as possible, because we have certain limitations\nwhen it comes to distributing GitLab.” – Marin Jankovski\n\n>“One challenge that I see is that there are a lot of dependencies on people\nexternal to the team to ship features. Ordinarily, a quick way to shorten cycle\ntime is to reduce those dependencies, but here at GitLab, that may reduce the\namount of collaboration that happens with each feature. Collaboration is such an\nimportant [value](https://handbook.gitlab.com/handbook/values/#collaboration) that this may have to take\nprecedence in some cases and be more important than the gain in speed.” – Rachel Nienaber\n\n### Asynchronous communication\n\nAt GitLab, we practice [asynchronous communication](https://handbook.gitlab.com/handbook/communication/),\nso we “don’t expect an instantaneous response,” allowing us to focus on our\nindividual workflows. The problem with working asynchronously is that projects\ncan become delayed when working with team members in different time zones and\nresponses don’t trickle in until the following day. Rapid movement might not be\nmade on projects because of time zone differences. [Mek Stittri](/company/team/#mekdev),\nEngineering Manager of the Quality team, and Rachel acknowledge the difficulties\nthat can come with asynchronous communication.\n\n>“My team is spread across so many projects and has someone in almost every time\nzone, meaning communication can be challenging.” – Mek Stittri\n\n>“This is my first role with an asynchronous method of working. I am finding that\nmany practices that work in a synchronous team need some adjustment to be useful here.” – Rachel Nienaber\n\n## What are some solutionsb to reducing cycle times?\n\nAt GitLab, we’re fortunate to have the freedom to experiment and\n[iterate](https://handbook.gitlab.com/handbook/values/#iteration), so we’ve been able to develop a few\nstrategies to help us alleviate the challenges we face when meeting customer demands by reducing cycle times.\n\n### How to get it right the first time\n\n\u003Col start=\"1\">\n \u003Cli>\n \u003Cp>\n \u003Cb>Automate work as much as possible.\u003C/b> Using CI to automatically do releases and investing time in automating\n other manual tasks is crucial for delivery. Manual tasks are both a huge\n drain on morale and prone to errors. It’s much easier to give engineers\n a bug to fix in an automated tool than to ask them to do the same thing\n multiple times.\n \u003C/p>\n \u003C/li>\n \u003Cli>\n \u003Cp>\n \u003Cb>Work with smaller, iterative pieces.\u003C/b> Breaking work into smaller chunks,\n \u003Ca href=\"/handbook/values/#iteration\">iterating\u003C/a> frequently, and\n \u003Ca href=\"https://gitlab.com/gl-retrospectives/plan/issues/10\">indicating priority more clearly\u003C/a>\n within a milestone enables better predictability for what’s going to ship.\n Planning becomes easier, because individual issues are smaller, so it’s\n easy to shuffle issues around if something unexpected interrupts other\n work.\n \u003C/p>\n \u003C/li>\n \u003Cli>\n \u003Cp>\n \u003Cb>Use feature flags.\u003C/b> Rather than using a giant merge request to make\n every change for a feature at once, which is harder to review, update,\n and keep up-to-date with the master branch, consider developing\n more features behind short-lived \u003Ca href=\"https://docs.gitlab.com/ee/development/feature_flags/index.html\">feature flags\u003C/a>.\n \u003C/p>\n \u003C/li>\n\u003C/ol>\n\n### How to differentiate the helpful from the unhelpful\n\n\u003Col start=\"4\">\n \u003Cli>\n \u003Cp>\n \u003Cb>Measure the impact of components.\u003C/b> Measuring impact can help determine\n whether a process either doesn’t help out that much in the end or helps\n out infrequently. In either case, the net benefit can be small, but the\n pain it adds (in terms of how much extra time you spend trying to ship)\n makes the overall impact negative. If you can’t measure impact directly,\n you have to be willing to experiment. Try things, see how they work, and\n decide if you should keep them or not. It’s important to remember that\n experimentation doesn’t mean process creep - the default end state for\n an experiment should be “let’s never do that again,” unless there’s a\n strong sense of value in it.\n \u003C/p>\n \u003C/li>\n\u003C/ol>\n\n\n### How to successfully work across teams\n\n\u003Col start=\"5\">\n \u003Cli>\n \u003Cp>\n \u003Cb>Communicate and automate where possible.\u003C/b> Automating how others get a\n finished product before releasing it (e.g. create a package on click)\n and \u003Ca href=\"/handbook/engineering/development/enablement/systems/distribution/#how-to-work-with-distribution\">broadly communicating\u003C/a>\n how to work with a team can result in better decisions and faster discussions.\n \u003C/p>\n \u003C/li>\n\n \u003Cli>\n \u003Cp>\n \u003Cb>Develop a training program.\u003C/b> Creating a training program to help engineers\n from other teams perform reviews can reduce cycle time for those teams\n that regularly depend on the Database team. This strategy has the added\n benefit of giving the Database team more time to focus on their own work.\n \u003C/p>\n \u003C/li>\n\n \u003Cli>\n \u003Cp>\n \u003Cb>Use project management tooling.\u003C/b> Consistent \u003Ca href=\"/handbook/engineering/quality/project-management/\">project management tooling\u003C/a>\n ensures consistent board configuration that behaves the same at every level,\n meaning that data rolls up to one top level board which contains a\n snapshot of an entire team, ensuring that prioritization is clear and\n workload is transparent.\n\n \u003C/p>\n \u003C/li>\n\n \u003Cli>\n \u003Cp>\n \u003Cb>Spread triaging.\u003C/b> To spread the load of triaging across teams, use \u003Ca href=\"https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=triage-package\">triage-package\u003C/a>.\n Here is a \u003Ca href=\"https://gitlab.com/gitlab-org/gitlab-ce/issues/52024\">recent example\u003C/a>\n of how we used triage-package to lessen the burden on one team.\n\n \u003C/p>\n \u003C/li>\n\n \u003Cli>\n \u003Cp>\n \u003Cb>Have more focused milestones.\u003C/b> Creating focused milestones can reduce\n context switching, since team members can concentrate on specific aspects\n of a feature.\n \u003C/p>\n \u003C/li>\n\u003C/ol>\n\n### How to make asynchronous communication work\n\n\u003Col start=\"10\">\n \u003Cli>\n \u003Cp>\n \u003Cb>Work on multiple items.\u003C/b> Having a list of multiple items to work on\n during each release cycle helps team members easily transition to another\n task rather than remaining blocked when waiting for feedback.\n \u003C/p>\n \u003C/li>\n\u003C/ol>\n\n## Advice\n\nReducing cycle times to meet internal cycle time goals can be a difficult undertaking, requiring the input from\nproduct managers, engineering leads, and developers. It’s a hard task to\nchallenge long-practiced behaviors, especially when the worst case scenario could\nmean features don’t make a release. Here is some advice to help your team's cycle time reduction effort.\n\n### Be thoughtful and considerate\n\n“At GitLab, we want to iterate quickly, but we also want to keep GitLab.com fast\nand stable. That means that we can’t just decide to ship things faster, we need\nto come up with strategies to mitigate any risks to performance and availability,\nbuild tooling and processes around those strategies. This is often work that can\ngo underappreciated, and it can be hard at times, but it’s vital to ensuring\nthat you can safely shorten cycle times.” – Sean McGivern\n\n### Retrospectives for learning\n\n“A successful team is a happy team. Bringing down production cycle time can help a team be\nmore successful because they are shipping value more often, but your team might\nhave more important things that must be addressed first. Using retrospectives\nwill help you to figure out what success means to your team, and what needs to\nbe done to achieve that success.” – Rachel Nienaber\n\n### Experiment\n\n“Make yourself uncomfortable. It’s unnatural to push for shorter cycle time.\nIt’s natural to add steps - it’s not natural to remove them. Try drastic cuts\nand be willing to learn from an experiment.” – Tommy Morgan\n\n### Spotlight your team\n\n“You can’t make product managers happy, so try to make your team happy instead\nby giving them a chance to shine. :P” – Marin Jankovski\n\n",[912,9],{"slug":4141,"featured":6,"template":698},"strategies-to-reduce-cycle-times","content:en-us:blog:strategies-to-reduce-cycle-times.yml","Strategies To Reduce Cycle Times","en-us/blog/strategies-to-reduce-cycle-times.yml","en-us/blog/strategies-to-reduce-cycle-times",{"_path":4147,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4148,"content":4154,"config":4162,"_id":4164,"_type":13,"title":4165,"_source":15,"_file":4166,"_stem":4167,"_extension":18},"/en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"title":4149,"description":4150,"ogTitle":4149,"ogDescription":4150,"noIndex":6,"ogImage":4151,"ogUrl":4152,"ogSiteName":685,"ogType":686,"canonicalUrls":4152,"schema":4153},"Synchronous collaboration as a remote designer at GitLab","Find out how GitLab Designers collaborate synchronously within an all-remote company!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669715/Blog/Hero%20Images/synchronous-collaboration-as-a-remote-designer.jpg","https://about.gitlab.com/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Synchronous collaboration as a remote designer at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Alexis Ginsberg\"},{\"@type\":\"Person\",\"name\":\"Becka Lippert\"},{\"@type\":\"Person\",\"name\":\"Matej Latin\"},{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n \"datePublished\": \"2020-04-01\",\n }",{"title":4149,"description":4150,"authors":4155,"heroImage":4151,"date":4159,"body":4160,"category":716,"tags":4161},[4156,4157,4158,3196],"Alexis Ginsberg","Becka Lippert","Matej Latin","2020-04-01","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nMany designers out there may find themselves new to the remote life within the past couple of months. This post just scratches the surface of how designers collaborate at Gitlab, and some ideas may work a bit differently in a post-COVID world, but hopefully you can find some inspiration for your day-to-day work. \n\nWorking as a designer at GitLab means being a Remote Designer with a capital R. GitLab has no “main” office. We have teammates working from their home office or coworking spaces all around the globe. Some of us don’t even have one home base, preferring to travel the world while working. \n\nAs designers at GitLab, we may not be able to physically get together near the Nespresso machine to chat about our days, or grab a conference room for a quick whiteboard session around the latest design challenge we are solving, but we still find ways to stay in sync. Are you thinking about NSYNC now? Good.\n\nFinding creative ways to collaborate synchronously with all teammates across GitLab is a worthy challenge to be solved, and we are always experimenting and iterating on the best ways to do this! We have found that [synchronous collaboration](/company/culture/all-remote/collaboration-and-whiteboarding/) has to be a bit more intentional, but if time and space is made for it, it can be just as––if not more––fun and productive! Here are some ways the GitLab design team has worked to create that space for synchronous collaboration...\n\n\n## 👯 Pair designers\n\nEvery six months or so, each individual designer is paired with another GitLab designer who is intentionally dedicated to a different[ stage group](https://about.gitlab.com/handbook/product/categories/). We are given the freedom to coordinate how we choose and can collaborate as much or as little as we feel comfortable with. The trend seems to be 30 minutes to an hour either each week or every other week. \n\n**_Alexis:_** I personally look forward to my weekly Zoom meeting with my pair, and we usually aim for an hour but sometimes go over time since we love chatting with each other. We have an agenda of items both of us hope to cover, but also make sure we have time to catch up as people and coworkers, which is especially important to me as a remote designer (sometimes you just want to show off your dog or talk about the latest Netflix show you are binging!).\n\nThe agenda items are usually split evenly between us so that we can dedicate half of the time to a design, research, or process challenge we are working through, and the other half giving feedback. We are encouraged to work in the tools we feel most productive in so sometimes we will be walking through a design in Sketch, Figma, Axure, Mural, or even a quick sketch on paper or iPad.\n\nAs our team grows larger, getting this time to really dive into the design challenges of another stage group is very important. It helps me focus on the holistic journey users have within GitLab, rather than just “my” specific corner of the product. Every designer at GitLab shines in their own way, and this is just another way for us to learn from each other! \n\n\n## ☕ Coffee chats, 1-1s with other designers, and stage specific syncs\n\nWe've already touched on the importance of remembering that although we are remote designers, we have the support of an entire team around the world. In no other place is this more apparent at GitLab than in coffee chats, one-on-one syncs, and syncs with stage specific teams. \n\n**_Alexis:_** We can opt in to random coffee chats with anyone at GitLab, but as a designer magic happens often when just chatting through challenges with other designers. Working remotely means more time to focus, and the formal process of asking to schedule time with others can sometimes feel like you are asking permission to steal focus time away from their day. If all designers agree to set aside time each week that is dedicated to chatting with each other, it helps take that guilty feeling out of the equation and feels more like an informal time to chat and explore designs (that \"turn around in your chair to chat with the coworker next to you\" feeling), rather than another faceless Google Calendar invite.\n\nWe do this in a few ways, either through recurring 1-1s with other designers (including the pair system), recurring small group syncs with other designers in our stage group, and somewhat larger recurring syncs with designers in our [section](https://about.gitlab.com/handbook/product/categories/#hierarchy). They are all useful and full of collaboration to varying degrees.\n\nThe smaller and more specific the syncs get, the more day-to-day-design and feedback-specific the collaboration gets, which is great, because designers in one product area need to be able to support each other frequently on related work. \n\nLarger syncs are perfect for getting a broader understanding of what other designers outside of your stage are up to and for aligning on broader GitLab Design priorities affecting our section.\n\n**_Becka:_** The larger syncs also help discover overlap that you may not know exists, such as similar challenges or new use cases for a component in the [design system](https://design.gitlab.com/).\n\n**_Matej:_** Based on my experience so far, having a recurring 1-1 call with other designers from my stage group can be even better than the option to do it spontaneously in an office environment. And that’s mostly because of how we do it. \n\nThese calls are always at the same time on the same day of the week. We have a Google Doc for the agenda, so we can prepare in advance. Often, when I work on something, I remember that my fellow designer from my group probably knows more about the topic, so I just open that agenda doc and add an item to it so that we talk about it the next time we meet. This way, I don’t interrupt them with Slack messages or ad-hoc calls. \n\nAll this combined, it leads to scheduled, time-boxed calls where participants are prepared in advance and everyone gets so much value out of it. We borrow ideas, prototypes, pieces of UI. We can go into details of why our teams are working on the things that they’re working on. If we relied solely on group status update calls we wouldn’t be able to do that. \n\nIt’s also a great way to socialize and build relationships with other designers, as we often talk about stuff that isn’t work related. We’ve only been doing this for two months in the [Growth](https://about.gitlab.com/handbook/product/categories/#growth-stage) group, but I've already saved hours of wasted time working on things others already did. I also got to know the designers much better, which makes collaboration easier, more likely, and also more enjoyable. \n\nWhen it comes down to it, we are all GitLab Designers and need to not only understand and empathize for each other's work, but also for each other as people who like each other and are working toward the same goals!\n\n\n## 🎬 UX Showcase and UX Weekly\n\nOur largest opportunities for synchronous collaboration are our UX Weekly meeting and the [UX Showcase](https://about.gitlab.com/handbook/product/ux/ux-department-workflow/ux-showcase/). These syncs aim to capture as many designers across time zones as possible, which is a great chance to interact with faces you may not see on your screen often.\n\n**_Alexis:_** Our team has grown substantially over the last year, so having a weekly time to catch up with each other at a department level has also grown more important. The UX Weekly is a time for any and all GitLab designers to discuss any updates they have made to Pajamas (our design system), process changes, OKRs, exciting ideas, or [workshops](https://about.gitlab.com/blog/async-sketching/) designers are tinkering on that they think may benefit others – basically any team updates in general. \n\nGrowth of our department (and GitLab as a whole) has also inspired us to find new ways to stay transparent and visible about the work we are doing. This promotes cross-team collaboration both inside and outside of design. \n\nEvery two weeks product designers are encouraged to dive deeply into problems they are solving at the [UX Showcase](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz), making sure to touch on things like business goals, customer goals, and constraints. Four stage groups present per session for fifteen minutes at a time, giving us an hour to highlight work we are excited about sharing broadly on [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A/videos) for anyone to watch! What we present and the format in which we share is not prescribed, so designers can get creative about how to use that fifteen minutes allotted to their stage group (or at least as creative as sharing a screen on Zoom will allow!).\n\nThe part of the UX Showcase I enjoy the most is understanding the journeys my fellow designers go through and what processes they find most beneficial when creating solutions alongside their teammates in Product and Engineering. I also love the Slacks I get from other GitLabbers after presenting, asking to learn more about the work I am doing because they have feedback or to collaborate on something they are working on that is similar. The most exciting pings I get are from coworkers I am unfamiliar with, because that means we are empowering everyone to learn about and contribute feedback to our user experience!\n\n\n## 🤝 Collaboration with Product Managers \n\nA strong relationship with our partners in Product Management is important for any designer, and this is no different even for those of us who don’t have to walk into an office every day. \n\n**_Alexis:_** One of my favorite weekly meetings is when my team’s product designers and product managers all get together in the middle of the week for a 45-minute sync on Zoom. The first item on our agenda is for each of us to go over our goal of the week. These goals can be very personal or something we are hoping to accomplish professionally that week. I personally really enjoy learning more about what my teammates hopes and dreams are, even if those hopes are just to finish the repairs on their guest bathroom (this seems to be a big priority on our team for some reason!).\n\nWe spend the rest of the time going over our agenda items, such as in-flight research, issues that need collaboration, questions that we need clarification on, and then the good ole’ board walking time (going through our Kanban board of open issues in the current milestone) where we see how prioritized work is going. Usually we don’t get to the last agenda item, because we are busy walking through a design together or collaborating on some research items in Mural. This is fine though, because we have other times set aside to talk about priorities, and this is something that is easy to do asynchronously as well.\n\nA recurring theme I hear from product managers is that working with designers is one of their favorite parts of their jobs, and that they would never want to lose that just because we aren’t co-located. Luckily for all of us, most designers at GitLab are now aligned to one group with one dedicated product manager, so we can really focus on making that working relationship great! \n\nMy product manager and I take an hour out of our busy schedules each week to hop on Zoom and sync up. We use our agenda (are you sensing a theme here?) as our guide to walk through priority design issues that require collaboration or scope clarification. I prefer to drop sketches and mocks into a Mural board that we share, so that I can share my screen and allow him to follow along and make comments as I walk through ideas. Sometimes he will even share sketches with me, which I will then add and build on. This time helps us collaborate and get to know each other outside of regular conversations in Slack and [issues](https://docs.gitlab.com/ee/user/project/issues/). \n\n\n## 💻 Collaboration with Engineering\n\nAnother very important relationship for product designers to nurture is with our friends in Engineering. Designers and engineers at GitLab usually work together asynchronously, often in issues or [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/). Many of the usual touchpoints between these teams - like stand up, retros, brainstorms, and reviews - are effortlessly asynchronous. Instead of distancing us as designers from the engineers we team up with, this just allows us to make the time we do set aside for synchronous work more focused and intentional. Sometimes we may even sneak in a board game or two.\n\n**_Alexis:_** My team has weekly syncs between designers and Engineering Managers to discuss ideas for experience improvements and gather feedback or known constraints around designs. Product managers will also join and help facilitate any pivots or tradeoffs we may need to make while walking through our planned priority work. We also have a larger meeting to discuss big picture updates or retro type items, like processes we think could improve our workflow. \n\nThese (at least) weekly syncs are important in keeping our teams running smoothly, but my favorite engineering syncs are the impromptu one-on-one review and pair sessions I have with teammates. If asynchronous reviews or ideation seem to be going back and forth for a long time, nothing is better for unblocking a teammate than a quick synchronous Zoom call. Usually, what starts with one of us being confused by something the other is working on ends up in us chatting on a call and learning from each other as we share our screens and work through tough challenges together. The best part of these is that if our time zones are very different, we get to say, “Go have some coffee and have a great morning!” and “Get out of the office and have a good night!” at the end of the same meeting.\n\n\n## 🔬 Collaborating with users and the UX Research team\n\nHaving a solid understanding of users and being able to empathize with their frustrations and desires is so important to us. In fact, we even have a team dedicated just to UX Research! As with most organizations, though, GitLab Product Designers also need to have a passion for research and will often wear that “research hat” themselves.\n\n**_Alexis:_** Conducting research as a remote designer has surprisingly not differed as much as I expected from my time as a designer working in an office. Usually we start everything with a synchronous kickoff chat between the person requesting research, the researcher, and anyone else interested in the research project to capture objectives. This is also documented more formally in an issue, so we can iterate together asynchronously and have a single source of truth to refer back to. The planning and scripting can either be done in GitLab itself, or in a Google Document where we collaborate asynchronously.\n\nPrototyping or setting up testing environments is done in GitLab or any tool we feel comfortable will be most effective for the user. We schedule time with participants and conduct the interviews themselves through Zoom, which is something many would be familiar with. Those who join the call take notes and chime in as needed. If anything, this may feel less intimidating to participants, as we are all just friendly faces in a small Zoom box, rather than people staring at them in person. Many times, users will remark on something going on in our home office, and that acts as an icebreaker and takes pressure off of the situation (I always get comments on my yellow chair and terrible wall art for example).\n\nThe synthesis aspect of research is where things get interesting, although I would imagine organizations that aren’t remote are also catching on to some of the remote techniques I am about to describe. We take the insights captured in Google Docs and GitLab issues and map them out in Mural. These synchronous sessions in Mural help us feel like we are all together at a whiteboard doing some good old fashioned affinity mapping - even more so if we are all doing this on a Zoom call and chatting as we work. Add a few stakeholders to the call, and it is a remote research synthesis party!\n\n## ⚖️ Why synchronous vs asynchronous?\n\nThis post highlights and focuses on some of the ways the GitLab team collaborates synchronously across time zones and teams, but the flipside of this is asynchronous collaboration, which is how we Get Things Done™️ a majority of the time. It is even one of our [values](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication). There are of course pros and cons to each way of collaborating!\n\n**_Holly_**: One of the challenges of being a remote organization is that we all simply can’t be available at the same time. In addition to collaboration, inclusion is also one of our values. Asynchronous communication allows us to ensure that [everyone has a chance](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication) to have a say, regardless of their schedule or timezone. \n\nHowever, we recognize that asynchronous communication is not without its challenges. Because async conversations happen in a page or document rather than a real-time setting, they can slip off the radar of participants. This can result in a stall in productivity. We have to be intentional about managing conversations we want and need to be a part of. This may include using [To-Dos](https://docs.gitlab.com/ee/user/todos.html), tagging others when we need feedback, applying group labels, and assigning items to ourselves, so that we are notified when a change occurs.\n\nAsynchronous communication also gives everyone a chance to pause, reflect and respond to ideas proactively, rather than reactively. This is great, particularly for introverts such as myself, but can at times lead to overthinking in discussions. We strongly believe that everyone can contribute and should feel empowered to do so, but we also recognize the need to move the work forward. Some of the ways we manage this are through asking questions and seeking to understand one another’s views, but also setting timelines (as needed) and goals for what we want to accomplish within a certain time frame.\n\nFinally, asynchronous communication allows the history of our collaboration to be preserved. We’ve grown exponentially this past year in a very short period of time. With so many new faces and great ideas coming in, it’s more important than ever for us to be able to refer to the historical conversations surrounding why certain decisions have been made. This enables us to move forward with insights starting from the original idea all the way through to production.\n\nWith all of these great benefits, though, sometimes problems can be particularly complex and need a quick answer or require real-time visual collaboration. We have a rule that if a conversation goes back and forth asynchronously more than 3 times, we move to a synchronous conversation, usually in Zoom or Slack. We record as many of our meetings and video chats as possible, so that others can still have an opportunity to catch up and provide feedback. And we recognize that as human beings, we are social creatures. Sometimes we simply need to hear someone’s voice, see their body language to fully understand a situation, or to just have a human connection. In these cases, we embrace the benefits of synchronous communication.\n\nFor more details on how we collaborate remotely in general, feel free to add [this blog](https://about.gitlab.com/blog/designing-in-an-all-remote-company/) to your reading list!\n\n\n## 💡 Tips and things to keep in mind when meeting\n\nYou may have a friend of a friend who has a horror story about video calls with coworkers. Mishaps can happen to the best of us (especially those of us with cats), and we understand that at GitLab. Here are a few of the things we keep in mind to make synchronous collaboration as seamless an experience as possible:\n\n**_Becka_**: Keep an agenda! One of the coolest things about GitLab meetings is that there’s always an agenda attached, so you can see what will be covered. Anyone on the call is empowered and encouraged to add items to the agenda, whether it’s to draw attention to an issue, invite feedback, or discuss something process oriented as a group. We can always add “Read-only” items at the top if there are a lot of agenda items, if the discussion can take place asynchronously, or if it’s more of an FYI (“Thank you so much to Alexis for starting this awesome blog post [linked to doc] about remote work!”). \n\nHaving a meeting agenda completed in advance (and often elaborated upon during the meeting), lets attendees come prepared and gives everyone a chance to be heard. If you decide that the other agenda items are higher priority, you can always add yours to the bottom of the list and feel good knowing that if time runs up, it will automatically be moved up as higher priority in the following meeting. \n\nFinally, agenda items are a great place to revisit to-dos from weeks prior, to find links to issues that were discussed, and a great single source of truth for meeting notes that all can contribute to.\n\n**_Becka:_** Mute your mic when you aren’t speaking to avoid frustration and perhaps embarrassment. 👀\n\n**_Holly:_** Remote work can blur the lines between personal and professional, but we are all human and things just happen sometimes! If anything, this can create bonding moments.\n\n**_Alexis:_** Many of our [collaboration values](https://handbook.gitlab.com/handbook/values/#collaboration) are around being kind to each other. This can translate to video calls and collaborative workspaces, too! Build any sessions with easy collaboration in mind. Give each other space to respond, and listen to each other. Pause often to allow other people to chime in with thoughts or ideas without interruption. Read the room as you typically would in person. One thing that really helps with this is turning your camera on during meetings, so that others can see your face and read your body language. I know sometimes it is tempting to join with your camera off, but trust me - it helps!\n\nAnother way you can be kind to others is by scheduling meetings with a 5-minute buffer at the end. So, for example, instead of blocking 30 minutes of time with someone, schedule them for 25 minutes. There is nothing worse having back-to-back meetings without time for making coffee, taking a bio break, or just walking around and stretching (hopefully toward some place that has a snack you can bring with you to the next meeting). \n\n**_Matej:_** If you need to collaborate often with the same teammates, schedule your syncs as recurring in a consistent cadence and have an agenda. This allows participants to be intentional in advance about what they’d like to cover during that set time, so they can understand expectations and be prepared - which enables everyone to collaborate on more items!\n\n**_Alexis and Holly:_** Lean into the fact that most coworkers may only be seeing your upper half and anything behind you, and fill that space with your personality (we like to wear outrageously silly sweaters or put our favorite art behind us)! Dogs or family walking behind you or interacting with the camera to say hi to colleagues is not only accepted at GitLab but encouraged. Working outside of an office means that coworkers can get to know you outside of the office “version” of you, if that is something you feel comfortable with.\n\n\n## 🦊 How do you do remote?\n\nFeel free to ping us on Twitter at [@gitlab](https://twitter.com/gitlab?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) with any remote synchronous collaboration tips and tricks in your toolbox that you think our team could learn from. See you in GitLab! \n\n###### [Alexis Ginsberg](https://gitlab.com/uhlexsis) (Chicago, IL, USA GMT-5), [Holly Reynolds](https://gitlab.com/hollyreynolds) (Roswell, Georgia, USA GMT-4), [Becka Lippert](https://gitlab.com/beckalippert) (Austin, TX, USA - and looking forward to working outside of the States when possible and responsible - GMT-5), [Matej Latin](https://gitlab.com/matejlatin) (Ljubljana, Slovenia GMT+2)\n\nCover image by [Sincerely Media](https://unsplash.com/photos/ylveRpZ8L1s) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[1096,1099,1098,1097,9],{"slug":4163,"featured":6,"template":698},"synchronous-collaboration-as-a-remote-designer-at-gitlab","content:en-us:blog:synchronous-collaboration-as-a-remote-designer-at-gitlab.yml","Synchronous Collaboration As A Remote Designer At Gitlab","en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab.yml","en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"_path":4169,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4170,"content":4176,"config":4181,"_id":4183,"_type":13,"title":4184,"_source":15,"_file":4185,"_stem":4186,"_extension":18},"/en-us/blog/tasktop-webcast-recap",{"title":4171,"description":4172,"ogTitle":4171,"ogDescription":4172,"noIndex":6,"ogImage":4173,"ogUrl":4174,"ogSiteName":685,"ogType":686,"canonicalUrls":4174,"schema":4175},"Cross-functional ≠ dysfunctional","Don't let process hold you back – here are our best practices for working cross-functionally.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671305/Blog/Hero%20Images/tasktop-integration-cover.png","https://about.gitlab.com/blog/tasktop-webcast-recap","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Cross-functional ≠ dysfunctional\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n \"datePublished\": \"2017-11-08\",\n }",{"title":4171,"description":4172,"authors":4177,"heroImage":4173,"date":4178,"body":4179,"category":910,"tags":4180},[1158],"2017-11-08","\n\nWe recently teamed up with [Tasktop](https://www.tasktop.com/integrations/gitlab-issues) to talk about processes and how to make sure\nthey work for you instead of against you. Check out the highlights below.\n\n\u003C!-- more -->\n\nCreating great software involves a number of different disciplines, each of\nwhich may use their own tool for managing work. Chaos might seem inevitable, but\nwe've learned that a few guiding principles can help to connect people and keep\nchannels of communication open.\n\n## 1. Goals first, process second\n\nProcess exists to serve goals. Before you put processes in place or continue with existing ones, take a step back to establish what you're trying to achieve. Getting input from all stakeholders to determine goals will help to set clear expectations up front and allow everyone to voice their concerns about the scope of the project. Armed with this information, you can then decide on the best process (including timelines, review cycles and communication vehicles) to achieve the desired outcome.\n\n## 2. Establish a single source of truth\n\nWith so many stages and so much activity involved in creating a product or feature, it can be hard to keep track of what's going on. This potential for chaos is quelled by establishing a single source of truth. So when you've outlined your goals and settled on a process for achieving them, write it all down so that everyone has something to refer to and there's no confusion about what was decided or what stage something is at. This is especially helpful for distributed teams, as it means people in other locations and time zones can get up to speed quickly and collaborators can work asynchronously. \n\n## 3. Clear, visible outcomes\n\nWhat exactly does success mean for your project? What metrics will you use? You want clear, measurable outcomes for what you're working on, so that everyone can see what's expected of them and others. At GitLab, we use [issue trackers](https://docs.gitlab.com/ee/user/project/issues/) to follow the progress of a new feature or project. Individual issues can be customized to reflect the problem you're trying to solve, how you're going to go about it, and what the outcome should be. Issues can be connected to related [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) so that all involved stakeholders can view new developments or changes right away, in a production-like environment. This way concerns or problems can be flagged at any stage along the way.\n\n## 4. Work cross-functionally from start to finish\n\nThe above guidelines only work if all your different functions are in communication. Instead of locking communication per-stage, per team, or per-specialty principle, leave the doors as open as possible. This minimizes risk, as GitLab Product Manager [Victor Wu](/company/team/#victorwu416) explains:\n\n> When you're creating software, and you're creating a feature, you probably want a security stakeholder involved. Security is often something that's tacked on at the end, but if it's baked directly into the design of the software it will be accounted for, and you can estimate the cost or effort required to design and implement something that accounts for security instead of backtracking later.\n\nCross-functional working also encourages a diversity of ideas from different teams contributing to a feature, which can result in a better outcome. You can foster open communication by working more transparently: make your goals, processes and metrics for success visible to your whole organization, if possible, and invite feedback. Use real-time editing tools (such as Google docs) for meetings and allow everyone to add to the agenda, take notes or suggest follow-up items.\n\n## 5. Improve the process in iterations\n\nFeeling inspired? Before you throw out all your existing processes, think about whether you can [iterate](https://handbook.gitlab.com/handbook/values/#iteration) on them instead. Radical change can be difficult for people to embrace, so you may have more success with gradual adjustments. Identify something that's not working well, and a small change you can make to improve on it.\n\n> Try to win those small battles, solve those small problems, week by week and month to month, and over time your process will improve.\n\n## Recording\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/8X6x54gaYRo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Slides\n\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://docs.google.com/presentation/d/e/2PACX-1vRcQw1XTuEk12ALqnrjMSTPLQ9OAm6Mmzn-eIoUOCJgUdX8dVDejdmN_HaK2AW1lVq1iDG7VxmzaXcD/embed?start=false&loop=false&delayms=3000\" frameborder=\"0\" width=\"960\" height=\"569\" allowfullscreen=\"true\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\nYou can read more about [Tasktop's GitLab integration here](/blog/tasktop-gitlab-integration/).\n",[1162,232,9,912],{"slug":4182,"featured":6,"template":698},"tasktop-webcast-recap","content:en-us:blog:tasktop-webcast-recap.yml","Tasktop Webcast Recap","en-us/blog/tasktop-webcast-recap.yml","en-us/blog/tasktop-webcast-recap",{"_path":4188,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4189,"content":4194,"config":4200,"_id":4202,"_type":13,"title":4203,"_source":15,"_file":4204,"_stem":4205,"_extension":18},"/en-us/blog/teams-gitpod-integration-gitlab-speed-up-development",{"title":4190,"description":4191,"ogTitle":4190,"ogDescription":4191,"noIndex":6,"ogImage":2000,"ogUrl":4192,"ogSiteName":685,"ogType":686,"canonicalUrls":4192,"schema":4193},"Teams speed up development with GitLab's Gitpod integration","Learn about Gitpod as cloud development environment, and how its integration into Gitpod helps teams to get more efficient in their DevOps lifecycle.","https://about.gitlab.com/blog/teams-gitpod-integration-gitlab-speed-up-development","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How teams can use the Gitpod integration in GitLab to speed up their development process\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n \"datePublished\": \"2021-07-19\",\n }",{"title":4195,"description":4191,"authors":4196,"heroImage":2000,"date":4197,"body":4198,"category":1053,"tags":4199},"How teams can use the Gitpod integration in GitLab to speed up their development process",[2005],"2021-07-19","\n\nTurn back time a bit and try to remember the first project you started or joined, and the onboarding experience. How long did it take to install the development environment on your local machine?\n\nWe talked about our own onboarding experiences into software development, and thought about sharing our favorite tips with GitLab users.\n\n## A developer's tale\n\nEveryone starts fresh, and often best practices are just \"learning by doing,\" requiring documentation in the same moment. Programming languages and application architectures are also different - a C++ backend environment has different requirements than a Ruby on Rails web application.\n\nStart with defining the requirements and stages. Oftentimes they are equivalent to CI/CD pipeline stages but executed in your own environment.\n\n* Compile/build the application and verify that the source code is valid (\"build\")\n* Run linting, unit tests, code quality checks (\"test\")\n* Run the application in a dev environment (\"runtime test\")\n* Package the application, run installation tests (\"staging installation\")\n* Run the installed application (\"staging deployment\")\n* Tag, release, and deploy the application (\"release production deployment\")\n\nYou want to run the application in a development environment quickly, everything else with staging and deployments continues to run in your CI/CD pipelines. Their implementation and availability should be on your to-do list.\n\nSoftware applications can depend on existing libraries which are used by many other developers, and help speed up the development process. These dependencies need to be installed into the development environment - if that is your local macOS, Windows or Linux desktop, methods and requirements will differ.\n\n### Provision development environments\n\nCreating a development environment for many different operating systems has its disadvantages: Error messages can differ and implementation specific details do not produce the same results and require back-and-forth communication on the team. This often leads to friction and slowed down development processes.\n\nOne key learning over the past decade has been to use CI/CD extensively to test different environments and operating systems, and rely on fast feedback in Merge Requests. Developers should be able to focus on their development environment without having to worry about the many production use cases and support.\n\nVirtual machines in Vagrant, and Docker containers made the generic development environment creation easier and efficient. The documentation instructed everyone to either execute `vagrant up` or `docker-compose up -d` and have the development stack ready. The road to creating Vagrant and Docker base images, including the provisioning scripts with Bash, Ansible, Puppet, etc., was and still is a huge learning process. Opinions on \"good\" best practices differ, and adding your preferred IDE on top of a CLI only VM or container often is an adventure on its own.\n\nBandwidth and traffic can also come into play - each provision and software installation run may consume gigabytes of data. If the workloads and provisioning would run in the cloud, your local connection is not affected.\n\nOne customer mentioned a while ago that their company policy forbids installing a local IDE without a license. The Web IDE in GitLab solves this problem for them throughout the onboarding month.\n\n### Development environment in the browser\n\nThe Web IDE helps with basic programming tasks, editing the documentation or setting up the CI/CD configuration. It does not provide a fully fledged server runtime, as cloud IDE with a programming environment capable of understanding the language you are programming in would. Our vision is to explore ways to [add integrated development environments into the Web IDE](/handbook/engineering/incubation/server-runtime/).\n\nThere are a variety of tools and environments following remote collaboration ideas and the cloud IDE approach. You can learn more in [this Twitter thread](https://twitter.com/sytses/status/1400134840754733059) from [GitLab co-founder and CEO, Sid Sijbrandij](/company/team/#sytses). One approach is [Gitpod](https://gitpod.io/), allowing you to spin a fresh environment in the cloud in seconds.\n\nGitpod uses Visual Studio Code (VS Code) as cloud IDE, and integrates with their marketplace to install the same extensions as you would install locally in VS Code. One of the coolest things about Gitpod is that it not only spins up a fresh environment, but also allows you to install additional software or bring your own workspace container image. That way everyone uses the same pre-provisioned environment, and pair programming and debugging becomes a breeze.\n\nNext time, the same state is booted up, secured by single sign-on.\n\n## First steps with Gitpod\n\nNavigate to [gitpod.io](https://gitpod.io) and choose to `continue with GitLab` as login.\n\nIf you are running a self-managed GitLab setup, ask your administrator to [enable the Gitpod integration](https://docs.gitlab.com/ee/integration/gitpod.html).\n\nLet's start with creating a VueJS application. Fork the [learn-vuejs-gitpod](https://gitlab.com/gitlab-de/playground/learn-vuejs-gitpod) project on GitLab.com.\n\n### Alternative: Start on your CLI\n\nAlternatively to forking the project, install NodeJS, npm and the `vue-cli` package, and run `vue create learn-vuejs-gitpod`. The vue command already initializes and commits based on your local Git configuration. Add the remote origin and push to a new repository on the remote GitLab server.\n\n```shell\n$ brew install node\n$ yarn add @vue/cli\n$ vue create learn-vuejs-gitpod\n\n$ cd learn-vuejs-gitpod\n$ git remote add origin https://gitlab.com/\u003Cyourusername>/learn-vuejs-gitpod.git\n$ git push -u origin main\n```\n\nGitLab will [create a private project from the git push command](https://docs.gitlab.com/ee/user/project/working_with_projects.html#create-a-new-project-with-git-push).\n\n### Start Gitpod\n\nStart Gitpod from the repository overview by selecting the dropdown switch from the Web IDE.\n\n![Gitpod VueJS Start](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_gitlab_start_vuejs.png)\n\nSign into your GitLab account with SSO once asked. Accept the required permissions, and wait until the Gitpod environment is booted up.\n\n![Gitpod VueJS Overview](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_vuejs_overview.png)\n\nChange to the terminal and run yarn to install the dependencies and start the development server. No worries, we'll show you how to automate this in a second!\n\n```shell\nyarn install\nyarn serve\n```\n\nGitpod detects the server listening on port 8080 and offers to make it public. Open the browser instead - it works but says `Invalid host header` because the dev server checks the host name. For running inside Gitpod containers, you need to [disable the host checks](https://github.com/gitpod-io/gitpod/issues/26#issuecomment-554058232).\n\nLet's fix this inside Gitpod in the project. Navigate into the left file tree, and add a new file called `vue.config.js` in the top level.\n\n![Gitpod VueJS Overview](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_vuejs_config_disable_host_checks_devserver.png)\n\nCopy the following code snippet into it\n\n```js\n// vue.config.js\nmodule.exports = {\n // Rationale: https://github.com/gitpod-io/gitpod/issues/26#issuecomment-554058232\n devServer: {\n disableHostCheck: true\n }\n}\n```\n\nAnd stop the running `yarn serve` command in the terminal by pressing `crtl+c`. Press `cursor up` to select the previous command, or type `!!` to repeat the last command followed by `enter` to start the devserver again. Voilà!\n\n![VueJs running app in Gitpod](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_vuejs_web_app.png)\n\nDon't forget to add and commit the new configuration file to persist the changes. Navigate into the `Source Control` section highlighting one pending change. Enter a commit message, click the check mark and approve all pending changes into the commit.\n\n![Gitpod Source Control](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_source_control_add_vuejs_config.png)\n\nSelect the `...` menu to `push` the Git history. Gitpod will ask you for `repository read/write` permissions, walk through the forms and edit them on Gitpod itself. Navigate back to the Gitpod project interface and re-do the push.\n\nFrom the first success, it is not far to your first customized VueJS application. But wait, there is more to learn about Gitpod and efficient workflows!\n\n### VS Code Extensions\n\nNavigate into the `Extensions` menu and search for `gitlab workflow`. Install the extension. We recommend installing it globally for your account and all future workspaces.\n\n![Gitpod extension: GitLab workflow for VS Code](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_extension_gitlab_workflow.png)\n\nNext, navigate into the new GitLab menu item on the left, and configure the extension. It needs a personal access token, similar to the process with a local VS Code extension configuration. Follow the steps in the [Gitlab documentation to create a personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token).\n\n![Gitpod: GitLab workflow extension config](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_gitlab_workflow_extension_config.png)\n\n## Speed up your own projects\n\nUsing Gitpod and GitLab to develop GitLab makes it easy to contribute, but what about your own DevOps lifecycle and projects? Below are a few more examples to speed up your development with Gitpod and GitLab.\n\nRemember: You can start Gitpod without any configuration, directly from a GitLab repository. If there are additional settings needed, you can develop them while learning from the examples and documentation best practices.\n\n### Hugo Pages website live review\n\nYou can use Hugo with GitLab pages to host your own private blog, for example. Hugo is a static site generator written in Go, with public Docker images already available. The deployment of [everyonecancontribute.com](https://everyonecancontribute.com/) uses the following configuration in the [.gitlab-ci.yml](https://gitlab.com/everyonecancontribute/web/everyonecancontribute.gitlab.io/-/blob/main/.gitlab-ci.yml) configuration:\n\n```yaml\n.publish: &publish\n image: registry.gitlab.com/pages/hugo:latest\n script:\n - hugo\n artifacts:\n paths:\n - public\n\npages:\n stage: publish\n \u003C\u003C: *publish\n rules:\n - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n when: always\n environment:\n name: $CI_PROJECT_NAME\n url: https://$CI_PROJECT_NAME/\n```\n\nA local development environment to preview the website needs the Hugo binary installed. Doing the same in the browser, running the Hugo CLI command and previewing the blog post? We've found a way to provision Gitpod in the same way, using [this .gitpod.yml configuration](https://gitlab.com/everyonecancontribute/web/everyonecancontribute.gitlab.io/-/blob/main/.gitpod.yml):\n\n```yaml\nimage: klakegg/hugo:debian\n\nports:\n - port: 1313\n\ntasks:\n - command: hugo server -D -b $(gp url 1313) --appendPort=false\n```\n\nThe Hugo container image gets pulled and the Gitpod workspace builder prepares the environment. Note that [Alpine based images do not work](https://github.com/gitpod-io/gitpod/issues/3356#issuecomment-877604994), use Debian variants instead. After starting the workspace, the tasks run the command, and expose a port. The port binding needs to be the external URL of the pod, not localhost. `gp url 1313` builds the exact URL, and binds the socket to the Hugo server, making the pod URL publicly accessible for reviews.\n\n![Gitpod: Hugo website](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_hugo_everyonecancontribute_com.png)\n\nFrom there, you can switch branches in Gitpod, and immediately verify the changes.\n\n### VueJS with custom container image\n\nGetting started with VueJS in a new project with the `vue-cli` package is very convenient and the Gitpod docs have a [guide](https://www.gitpod.io/docs/languages/vue/#vue-cli) ready. The default `gitpod/workspace-full` image does not provide the `vue cli` package. You can extend the container image by using your [custom .gitpod.Dockerfile](https://www.gitpod.io/docs/config-docker#configure-a-custom-dockerfile) - Gitpod takes care of building the image first, and later starts the workspace based on it.\n\n```yaml\nFROM gitpod/workspace-full\n\nRUN yarn add @vue/cli\n```\n\nThe `.gitpod.yml` configuration file needs to be instructed to build and use a custom image. On startup, the `tasks` section runs the initial dependency installation, and starts the development environment with `yarn serve`. The server listens on port 5000 by default, this is what gets [exposed](https://www.gitpod.io/docs/config-ports), and instructed to open as call-to-action in the browser.\n\n\n```yaml\nimage:\n file: .gitpod.Dockerfile\n\ntasks:\n - init: yarn install\n command: yarn serve\n\nports:\n - port: 5000\n onOpen: open-browser\n```\n\nYou can combine Gitpod for previewing the website with the production deployment using the [five minute production app deployment template](https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template) shown in [this project](https://gitlab.com/gitlab-de/playground/5-min-prod-app-vuejs). GitLab takes care of provisioning a free AWS EC2 instance, TLS certificates and domain handling.\n\n### More Gitpod workspace images\n\nGitpod provides many [ready-to-use workspace images](https://github.com/gitpod-io/workspace-images). In order to use them, create the `.gitpod.yml` file with this content:\n\n```yaml\nimage:\n file: .gitpod.Dockerfile\n```\n\nCreate a new `.gitpod.Dockerfile` file and add the import from the desired workspace image.\n\n```yaml\nFROM gitpod/workspace-mysql\n```\n\nIf you need to install additional software, note that the full workspace image is based on Debian and therefore you'll need to use the `apt` package manager. The following command updates the package index, and clears the cache after installation to keep the image clean.\n\n```\nRUN sudo apt update && sudo apt install -y PACKAGENAME && sudo rm -rf /var/lib/apt/lists/*\n```\n\nIf you are not sure about the package name, run Docker locally and search for the package name. Fair warning: The `gitpod/workspace-full` image is huge, use the base image `debian:latest` instead.\n\n```shell\n$ docker run -ti debian:latest bash\n$ apt search POSSIBLENAME\n```\n\nYou can learn more the [workspace image repository](https://github.com/gitpod-io/workspace-images) to learn more about the Dockerfile configuration used by the builder.\n\n## Do more with Gitpod\n\n### Merge request code reviews\n\nThe GitLab workflow extension comes with more super powers:\n\n* Access the project and Merge Requests\n* Check the CI/CD pipeline status directly in Gitpod\n* Perform MR code reviews in Gitpod and take advantage of [VS Code workflows](/blog/mr-reviews-with-vs-code/)\n\n![Gitpod: MR Code Reviews with the GitLab Workflow extension website](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_vs_code_gitlab_workflow_extension_mr_code_reviews.png)\n\n### Pre-install VS Code Extensions\n\nIn order to ensure specific [VS Code extensions](https://www.gitpod.io/docs/vscode-extensions/) are installed, you can define them in the `.gitpod.yml` configuration file in the repository. Example from the [GitLab project](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitpod.yml#L79):\n\n```yaml\nvscode:\n extensions:\n - rebornix.ruby@0.28.0\n - wingrunr21.vscode-ruby@0.27.0\n - karunamurti.haml@1.3.1\n - octref.vetur@0.34.1\n - dbaeumer.vscode-eslint@2.1.8\n - gitlab.gitlab-workflow@3.24.0\n```\n\n### Learn new programming languages: Rust\n\nGitpod allows you to start a fresh pod environment, pause on idle, and continue at a later point. The default workspace environment image already includes the [Rust compiler](https://www.gitpod.io/docs/languages/rust), which means that you can immediately [start learning Rust](https://doc.rust-lang.org/rust-by-example/).\n\nCreate a new project called `learn-rust` and open Gitpod from the repository view. Add a new file on the left tree view called `hello.rs` and add the following content:\n\n```rust\nfn main() {\n\tprintln!(\"Hello from GitLab! 🦊\");\n}\n```\n\nChange into the terminal and run the following command:\n\n```shell\n$ rustc hello.rs\n```\n\nWe started learning Rust together in an [#EveryoneCanContribute cafe](https://everyonecancontribute.com/post/2020-10-07-cafe-3-gitpod-gitlab-rust/) in October 2020 including [workshop slides with exercises](https://docs.google.com/presentation/d/1t1FdHh04TAOg9WITqRFJHz1YFxMbsQeekN8th1UfFcI/edit). We continued with [Rocket.rs](https://everyonecancontribute.com/post/2021-06-30-cafe-36-rust-rocket-prometheus/) as web app and additional Prometheus monitoring metrics in June 2021. You can watch the recordings to follow the learning process, the mistakes we made on the way, and the first success.\n\n### How to contribute to GitLab with Gitpod\n\nA more complex development environment is GitLab itself. The [architecture](https://docs.gitlab.com/ee/development/architecture.html) involves many different components, and the development environment requires you to install several dependencies in Ruby, NodeJS, Go, and backend applications. The GitLab Development Kit (GDK) describes the steps in detail - in order to get everything up and running, you need to plan for a 30 minutes to three hour process, depending on the compute power and bandwidth.\n\nEarly in the process of adopting Gitpod for GitLab team members, the groundwork with the base image and bootstrap script took the majority of the preparation time. You can learn more about the integration process in [this issue request](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/1076).\n\n> It's already possible to try out how the setup works by opening Gitpod, which after waiting for the setup to finish (six to eight minutes) will bring you the Gitpod UI with the GDK fully running and ready for you to make changes and commit. As soon as that setup is finished, you can switch to whatever branch you want, either from the Gitpod UI or via the terminal.\n\nThe [GDK documentation for Gitpod](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/gitpod.md) guides you through the required steps. **Important**: You need to start Gitpod from the [gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab/) project (as team member, as contributor, please fork the repository). Additional features, such as a local GitLab runner, feature flags, Advanced search, etc., must be [enabled manually](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/gitpod.md#configure-additional-features).\n\n![GitLab Development Kit running in Gitpod](https://about.gitlab.com/images/blogimages/gitlab-gitpod-teams-development/gitpod_gitlab_gdk_running.png)\n\n### Everyone can contribute\n\nReady? Start contributing to your favorite OSS project, and connect with your teams for an all-remote pair programming session using Gitpod! :-)\n\nCover image by [Thomas Lipke](https://unsplash.com/photos/oIuDXlOJSiE) on [Unsplash](https://unsplash.com)\n{: .note}\n",[232,9,912],{"slug":4201,"featured":6,"template":698},"teams-gitpod-integration-gitlab-speed-up-development","content:en-us:blog:teams-gitpod-integration-gitlab-speed-up-development.yml","Teams Gitpod Integration Gitlab Speed Up Development","en-us/blog/teams-gitpod-integration-gitlab-speed-up-development.yml","en-us/blog/teams-gitpod-integration-gitlab-speed-up-development",{"_path":4207,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4208,"content":4214,"config":4219,"_id":4221,"_type":13,"title":4222,"_source":15,"_file":4223,"_stem":4224,"_extension":18},"/en-us/blog/ten-reasons-why-your-business-needs-ci-cd",{"title":4209,"description":4210,"ogTitle":4209,"ogDescription":4210,"noIndex":6,"ogImage":4211,"ogUrl":4212,"ogSiteName":685,"ogType":686,"canonicalUrls":4212,"schema":4213},"10 Reasons why your business needs CI/CD","Want to know why you should consider using CI/CD? Learn more here about the many business benefits of adopting a CI/CD workflow for you and your organization.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663779/Blog/Hero%20Images/cicd-2018_blogimage.jpg","https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"10 Reasons why your business needs CI/CD\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-02-15\",\n }",{"title":4209,"description":4210,"authors":4215,"heroImage":4211,"date":4216,"body":4217,"category":693,"tags":4218},[846],"2022-02-15","\nThere’s no escape: Your company is in the software business, even if it’s not. \n\nCompetitors, customers, investors, and employees are all demanding updated software on a regular basis, alongside whatever products your organization creates.\n\nSo embrace the reality (and [DevOps](/topics/devops/)) and invest in creating the most efficient continuous integration and delivery pipelines possible. Not sure how to sell this strategy to management? Start by pointing out it’s likely your closest competitor is already taking advantage of [continuous integration/continous delivery](/topics/ci-cd/)(CI/CD). And if you need more ammunition, here are 10 reasons why your business needs CI/CD.\n\n## What is CI/CD?\n\nCI/CD is a two-step process that dramatically streamlines code development and delivery using the power of automation. CI makes developer tasks like source code integration and version control more efficient so software can get into production faster. CD automates software testing and deployment. Together, CI/CD is a powerful and unmatched engine of modern software development and it has untold benefits for businesses.\n\n## What are the CI/CD benefits for business?\n\nCI/CD has numerous benefits for business. Here are 10 reasons to adopt CI/CD: \n\n* Ensure superior code quality\n\nIn our [2021 Global DevSecOps Survey](/developer-survey/), participants told us the number one reason to do DevOps is for code quality and, of course, the number one process teams need for DevOps is CI/CD. Because CI/CD pipelines offer test automation, developers can know about code problems nearly in real time. That concept of “failing fast” means teams aren’t wasting time or resources with buggy code, and devs aren’t plagued with endless “fix” requests when they’ve moved on to other projects. Time is saved, money is saved, and developers aren’t endlessly context switching… win, win, win.\n\n* Deliver faster with an accelerated release rate\n\nSkeptics about the benefits of CI/CD need only hear about global financial firm Goldman Sach’s success story: It’s Technology Division went from [one code build every two weeks to over 1,000 builds per day](/customers/goldman-sachs/). A unified CI/CD pipeline is like a turbo engine when it comes to boosting the rate of software releases. The faster code is released, the more new code can be developed, and then released, ad infinitum. The business bottom line: Expensive developer resources aren’t sitting idle when a successful CI/CD pipeline is in play.\n\n* CI/CD pipelines: Automation reduces the cost\n\nAnytime a human does not have to intervene in the software development process, time, and thus money, are saved. That’s why automation is the underpinning to successful DevOps practices. CI/CD automates the handoffs, the source code management, the version control system, the deployment mechanisms, and, of course, so much of the testing. \n\nOf all those, [testing](/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/) is arguably the most important. In our 2021 survey, testing was identified as the number one reason releases were delayed. Not only do delayed releases impact the business from a cost, branding, public relations, and even a reputation perspective, they are deadly to businesses relying on speedy time-to-market. Historically software testing was manual and incredibly time-consuming, which is why companies only released new code once or twice a year. In today’s world, companies have to release all the time, and automated software testing is critical to making that possible.\n\n* Fault isolation\n\nBefore DevOps and CI/CD gained traction in software development, development teams would know there was an issue with code, but would struggle to know exactly *where* the problem was happening. CI/CD and its automated testing has changed that. Developers can easily identify and then isolate code faults, dramatically improving productivity. \n\n* Simplified rollback\n\nA CI/CD pipeline gives developers the power to fail fast and recover even faster. It’s a simple process to push code into production and, if there are issues, simply roll it back. The ability to easily rollback code saves teams time, energy, and resources and leads to faster fixes of problem code. \n\n* Continuous feedback\n\nA unified CI/CD process, operating as part of a DevOps platform, gives everyone on the team – including business stakeholders – a way to see what’s happening, where it’s happening, and what might be going wrong. This sounds like a simple thing, but in reality, a single window into software development is almost revolutionary.\n\nIn the past, there were simply _so many tools_ in play that a project manager might have to look in a number of places, and ask a number of people, to get status updates. Developers and operations pros fared no better. Obviously that was a waste of time and resources, particularly when problems arose. \n\n* Optimum transparency and accountability\n\nThanks to continuous feedback, a CI/CD pipeline makes the entire software development process completely transparent to the business side. Product managers can check project status in a glance and track accountability as needed. \n\n* Improved mean time to resolution (MTTR)\n\nThanks to the visibility provided by a CI/CD pipeline, DevOps teams see issues quickly and can fix them fast. The ability to rapidly resolve problems lies at the heart of a key development metric: mean time to resolution, or MTTR. The better the MTTR, the more efficiently the DevOps team is working and the more quickly software can be released; in other words, MTTR has a direct effect on a business’s bottom line. \n\n* Monitoring metrics data\n\nTeams and the business side need to know how code is functioning in the real world, but in traditional software development practices monitoring metrics are often absent. In an ideal world, teams would know there was a code problem and roll it back long before end users realized it. A CI/CD pipeline makes that “ideal world” a reality by [delivering continuous feedback on a variety of metrics](https://about.gitlab.com/topics/ci-cd/continuous-integration-metrics/). Access to metrics data is more than just a time-saver, however, as no organization wants to be associated with bug-ridden code and applications that don’t perform well. \n\n* Reduction of non-critical defects in backlog\n\nBy now it’s clear CI/CD is a time and money saver, so much so that it gives developers time to work on things they wouldn’t normally be able to, such as going back to fix older code and make it cleaner and more efficient. The idea that devs cannot only tackle the backlog (it’s called a backlog for a reason after all – who has time for this?), but also work on non-critical defects, is a game-changer brought to teams by DevOps and CI/CD.\n",[695,108,9],{"slug":4220,"featured":6,"template":698},"ten-reasons-why-your-business-needs-ci-cd","content:en-us:blog:ten-reasons-why-your-business-needs-ci-cd.yml","Ten Reasons Why Your Business Needs Ci Cd","en-us/blog/ten-reasons-why-your-business-needs-ci-cd.yml","en-us/blog/ten-reasons-why-your-business-needs-ci-cd",{"_path":4226,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4227,"content":4233,"config":4238,"_id":4240,"_type":13,"title":4241,"_source":15,"_file":4242,"_stem":4243,"_extension":18},"/en-us/blog/the-best-of-gitlabs-devops-platform-2021",{"title":4228,"description":4229,"ogTitle":4228,"ogDescription":4229,"noIndex":6,"ogImage":4230,"ogUrl":4231,"ogSiteName":685,"ogType":686,"canonicalUrls":4231,"schema":4232},"The best of GitLab's DevOps Platform 2021","Some highlights from last year, and what to expect from 2022.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667509/Blog/Hero%20Images/continuous-integration-from-jenkins-to-gitlab-using-docker.jpg","https://about.gitlab.com/blog/the-best-of-gitlabs-devops-platform-2021","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The best of GitLab's DevOps Platform 2021\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Brendan O'Leary\"}],\n \"datePublished\": \"2022-02-18\",\n }",{"title":4228,"description":4229,"authors":4234,"heroImage":4230,"date":4235,"body":4236,"category":757,"tags":4237},[1733],"2022-02-18","\nBefore we get too far into 2022, we wanted to take a look back at the most exciting additions to our [DevOps Platform](/topics/devops-platform/) over the last year. Since we release every month on the 22nd, there were lots of new features to consider, but these stood out to me.\n\n## Epic Boards\n\nIn [GitLab 14.0](/releases/2021/06/22/gitlab-14-0-released/#epic-boards), we made it easy to keep track of all epics in one place through Epic Boards. Our Epic Boards are customizable with a simple “drag and drop” interface accessible to all teammates, not just the technical ones. Now it’s painless to create general or DevOps-focused workflow states. And teams aren’t just more efficient, they can actually be predictable.\n\nExplore our [Epic Boards](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html).\n\n## Integrations with VS Code and Gitpod\n\nFans of Visual Studio Code got a much tighter integration with GitLab in 2021. The [GitLab Workflow Extension](https://docs.gitlab.com/ee/user/project/repository/vscode.html) reduces context switching and improves productivity. And we rounded up [8 ways to get the most out of VS Code and GitLab](/blog/vscode-workflows-for-working-with-gitlab/).\n\nGitLab also created a tighter integration with Gitpod. Developers can now set up environments as code, greatly [speeding up the process](/blog/teams-gitpod-integration-gitlab-speed-up-development/). I think this Gitpod integration is so slick I used it to [code, build and deploy from an iPad](/blog/how-to-code-build-and-deploy-from-an-ipad-using-gitlab-and-gitpod/). Gitpod and its features give developers an opportunity to think outside the box.\n\n## So much security\n\nIn 2021 we gave security pros a true “home” in GitLab with our security dashboard. Teams can now [see vulnerabilities in a pipeline](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) and easily slice and dice that data as necessary.\n\nStatic application security testing (SAST) also got an upgrade last year. We now have nextgen SAST that will [reduce Ruby false positives](/releases/2021/09/22/gitlab-14-3-released/#next-generation-sast-to-reduce-ruby-false-positives) as well as the ability to automatically test [Infrastructure as Code](/releases/2021/11/22/gitlab-14-5-released/) for the first time.\n\n## Praefect for Gitaly\n\nCustomers who want high availability on their own instances now can use Praefect, [our Gitaly clustering solution](/blog/high-availability-git-storage-with-praefect/), that allows Git to scale. Here’s what you [need to know](https://docs.gitlab.com/ee/administration/gitaly/praefect.html) about configuring a Gitaly cluster.\n\n## A visual pipeline editor\n\nIt’s hard to build it if you can’t see it, and that’s where our Pipeline Editor comes in. Use Pipeline Editor to [quickly set up CI/CD](/blog/pipeline-editor-overview/) because it’s now easy to see configurations and dependencies between jobs. Validate and visualize [all parts of the pipeline](https://docs.gitlab.com/ee/ci/pipeline_editor/) without feeling overwhelmed by the complexity.\n\n## Working with (and on) OpenShift\n\nIt’s now possible to set up a GitLab Runner for [Red Hat’s popular OpenShift infrastructure](https://docs.gitlab.com/runner/install/operator.html). Organizations relying on OpenShift can now use [the GitLab Operator](https://about.gitlab.com/blog/open-shift-ga/) to easily tap into the power of GitLab’s DevOps Platform.\n\n## The GitLab Agent for Kubernetes\n\nLast fall we announced an easier way to tackle GitLab and Kubernetes integrations in a secure and cloud-friendly way: [The GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/). We call this `agentk` and here’s [everything you need to know](/blog/setting-up-the-k-agent/) about set up.\n\n## 2021 and 2022\n\nIf I had to sum it up, I’d say that in 2021 we doubled down on security. And this year, expect us to double down on operations, specifically observability, thanks to our [acquisition of Opstrace](/press/releases/2021-12-14-gitlab-acquires-opstrace-to-expand-its-devops-platform-with-open-source-observability-solution.html). It’s going to be an exciting ride!\n",[695,807,9],{"slug":4239,"featured":6,"template":698},"the-best-of-gitlabs-devops-platform-2021","content:en-us:blog:the-best-of-gitlabs-devops-platform-2021.yml","The Best Of Gitlabs Devops Platform 2021","en-us/blog/the-best-of-gitlabs-devops-platform-2021.yml","en-us/blog/the-best-of-gitlabs-devops-platform-2021",{"_path":4245,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4246,"content":4252,"config":4259,"_id":4261,"_type":13,"title":4262,"_source":15,"_file":4263,"_stem":4264,"_extension":18},"/en-us/blog/the-gitlab-handbook-by-numbers",{"title":4247,"description":4248,"ogTitle":4247,"ogDescription":4248,"noIndex":6,"ogImage":4249,"ogUrl":4250,"ogSiteName":685,"ogType":686,"canonicalUrls":4250,"schema":4251},"The GitLab handbook by numbers","Two GitLab team-members take a fresh look at GitLab's open source team handbook, charting its evolution over the years to the weighty tome it is today.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670434/Blog/Hero%20Images/handbook-cover.jpg","https://about.gitlab.com/blog/the-gitlab-handbook-by-numbers","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The GitLab handbook by numbers\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lukas Eipert\"},{\"@type\":\"Person\",\"name\":\"Lee Matos\"}],\n \"datePublished\": \"2019-04-24\",\n }",{"title":4247,"description":4248,"authors":4253,"heroImage":4249,"date":4256,"body":4257,"category":300,"tags":4258},[4254,4255],"Lukas Eipert","Lee Matos","2019-04-24","\nSharing and retrieving information is a crucial part of everyday work life.\nWhere do you get information from, be it about hiring processes, social media guidelines, or reporting expenses?\nAt GitLab, all of that can be found in [the handbook](https://handbook.gitlab.com/) – have a look, it's public!\n[Sid](/company/team/#sytses), our CEO, [wrote about the importance and the open sourcing of our handbook][sid-blog-post] about two and a half years ago.\nBack then we were just shy of 100 employees.\nIn this post we will look at how the handbook has developed over time, how we interact with it,\nand how it still works for over 550 employees.\n\n[sid-blog-post]: /blog/our-handbook-is-open-source-heres-why/\n\n## One book to guide them all\n\nAt the time of writing, the handbook contains about 605,000 words.\nWhile probably a bit less captivating than the tales of Frodo and Middle Earth,\nwe have composed more pages than \"The Lord of the Rings\" and \"The Hobbit\" combined, since the [first commit][first-commit] in 2015.\nIt would take around 50 hours of continuous reading to cover the whole handbook, front to back.\n\n### Is it overwhelming to read through it all?\n\nIt would be, but as the handbook covers a wide range of topics, you probably don't need to read every single word.\nAs the handbook changes over time it is not necessary to memorize it all, but it is more important to remember how to retrieve information.\nSo as long as you know where to find something, you are on the safe side.\n\n> It would take around 50 hours of continuous reading to cover the whole handbook, front to back\n\n[first-commit]: https://gitlab.com/gitlab-com/www-gitlab-com/blob/2d2ced8f79da96fe981a3a6f6cf5918fa2dd992a/source/team-handbook/index.html\n\n## One book to be written by them all\n\n![Graph showing the growth of the handbook over time (May 2015 - April 2019)](https://about.gitlab.com/images/blogimages/evolution_handbook/handbook-history.png){: .shadow.center}\n*\u003Csmall>Graph showing the growth of the handbook, broken down by subcategory, over time (May 2015 – April 2019)\u003C/small>*\n\nCurrently all knowledge in the handbook is spread across 550 unique web pages, with the average page containing around 1,100 words.\nThe most words have been written in the subcategory engineering (138,000 words), with marketing a close second (115,000 words).\nTypically, as teams grow, more of their processes get documented in the handbook, which leads to a natural growth of the respective category.\n\n> The most words have been written in the subcategory engineering (138,000 words)\n\n### Who contributes to the handbook?\n\nYou might think that there is someone special who writes all those pages, but it's important\nto remember that [everyone can contribute](https://handbook.gitlab.com/handbook/company/mission/) to the handbook. It is actually part of our [onboarding process]\nto improve something about the handbook – whether that's clarifying wording or making it easier to find something.\nNothing is exempt from change; even [our core values are adjusted over the course of time][values-history].\n\n### How do you make changes to the handbook?\n\nIf someone at GitLab or from the wider community wants to change something, they follow a simple workflow that is familiar to every GitLab user:\n\n1. Create a merge request which introduces the change.\n2. Discuss the merge request with the stakeholders.\n3. Iterate on the change and come to an agreement.\n4. Let the merge request be merged.\n\nMore important changes (not every typo of course!) are then announced via Slack or our [company call].\nThe handbook also has its own [changelog] which you can check regularly to see what has been changed over time.\n\n[onboarding process]: https://handbook.gitlab.com/handbook/people-group/general-onboarding/\n[values-history]: https://gitlab.com/gitlab-com/www-gitlab-com/commits/master/source/handbook/values/index.html.md\n[company call]: https://handbook.gitlab.com/handbook/communication/\n[changelog]: https://handbook.gitlab.com/handbook/about/changelog/\n\n## One book to be read by them all\n\nIn 2018 we had several hundred thousand page views on pages in the handbook. It is hard to tell which views come from GitLab team-members and which from the wider community.\nAmong the most-read pages are our [Markdown Guide], the pages about [global compensation], our [values], the [hiring process], our [product], [benefits], and how to [communicate].\nThese pages are topics of general interest to people within and outside the company.\nWhat could be a better resource to potential candidates than those pages that show the inner workings of GitLab?\n\n### How do you find anything in the handbook?\n\nThe handbook has a search function; you can use the [index page](https://handbook.gitlab.com/) as an entry point, or just use your favorite search engine to find information.\nWhenever someone asks a question in our Slack, there is a high probability that someone will answer with a link to the handbook.\nIf someone asks a question that has no answer in the handbook, we highly encourage people to add that information to document it and make it easier for future GitLab team-members to find answers.\n\n> Whenever someone asks a question in our Slack, there is a high probability that someone will answer with a link to the handbook\n\n[Markdown Guide]: https://handbook.gitlab.com/handbook/markdown-guide/\n[global compensation]: https://handbook.gitlab.com/handbook/total-rewards/compensation/\n[product]: https://handbook.gitlab.com/handbook/product/\n[communicate]: https://handbook.gitlab.com/handbook/communication/\n[values]: https://handbook.gitlab.com/handbook/values/\n[benefits]: https://handbook.gitlab.com/handbook/total-rewards/benefits/\n[hiring process]: https://handbook.gitlab.com/handbook/hiring/\n\n## One book to be the future\n\nWe hope that this glimpse into the handbook is as interesting for you as it was for us.\nIn an all-remote company it is especially important to write everything down, so that no matter\nwhere you are in the world or what time zone you choose to work in, the information you need is accessible.\nAt the moment we are happy to say that we think that the handbook works as well for us now as it did with 100 employees.\nIt aligns with our [values] more than ever.\n\nFor us it is the most transparent way to collaborate on documentation of company internals.\nWe are able to efficiently iterate on topics, resulting in more in-depth coverage over time.\nPersonally the authors cannot see many reasons why the handbook should not be able to scale even further.\nEventually it will evolve further, from the three tomes we have today, to a digital encyclopedia.\nWe are definitely excited to see what the future holds!\n\nHave you taken inspiration from our handbook? Let us know by tweeting [@gitlab](https://twitter.com/gitlab).\n\nPhoto by [Beatriz Pérez Moya](https://unsplash.com/photos/XN4T2PVUUgk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/books?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,829,934,787],{"slug":4260,"featured":6,"template":698},"the-gitlab-handbook-by-numbers","content:en-us:blog:the-gitlab-handbook-by-numbers.yml","The Gitlab Handbook By Numbers","en-us/blog/the-gitlab-handbook-by-numbers.yml","en-us/blog/the-gitlab-handbook-by-numbers",{"_path":4266,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4267,"content":4273,"config":4279,"_id":4281,"_type":13,"title":4282,"_source":15,"_file":4283,"_stem":4284,"_extension":18},"/en-us/blog/the-ultimate-guide-to-software-supply-chain-security",{"title":4268,"description":4269,"ogTitle":4268,"ogDescription":4269,"noIndex":6,"ogImage":4270,"ogUrl":4271,"ogSiteName":685,"ogType":686,"canonicalUrls":4271,"schema":4272},"The ultimate guide to software supply chain security","Coupling DevSecOps with software supply chain security results in the advanced protection organizations need.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667094/Blog/Hero%20Images/container-security.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-software-supply-chain-security","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The ultimate guide to software supply chain security\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n \"datePublished\": \"2022-08-30\",\n }",{"title":4268,"description":4269,"authors":4274,"heroImage":4270,"date":4276,"body":4277,"category":757,"tags":4278},[4275],"Sandra Gittlen","2022-08-30","\n\nThreats to the software supply chain are forcing a sea change in DevOps. Organizations are feeling internal pressure to embed security deep into their software development life cycles and external pressure to comply with numerous federal and industry mandates. What is emerging is a DevSecOps strategy that helps govern how code, applications, and infrastructure are protected across the software supply chain.\n\nThe pairing of DevSecOps with software supply chain security also ensures that, where possible, automation will be used to make processes repeatable, increasing security and reducing the opportunity for human error or malicious activity. \n\nThis comprehensive guide provides deeper dives into all the aspects of software supply chain security so make sure to follow the embedded links.\n\n## The need for software supply chain security\n\nSecuring code is not a new concept. However, promoting security early on in the development life cycle is. The movement to shift security left has taken off, and “sec” is becoming part of the DevOps culture, morphing the concept wholly into DevSecOps. \n\nAlong with this evolution has been an increase in outside pressure – as formidable as [the federal government](/blog/biden-administration-celebrates-1-year-anniversary-of-eo-by-accelerating-software-supply-chain-security/) – to batten down software supply chains so that large attacks such as the [SolarWinds hack of 2020](/blog/what-the-solarwinds-attack-can-teach-us-about-devsecops/#a-brief-summary-of-the-solarwinds-incident) won’t threaten the nation’s critical infrastructure and cause unmitigated damage.\n\nEssentially, businesses must figure out how to meld their development, security, and operations teams internally while complying with numerous mandates from external organizations.\n\nLearn more about the key trends driving software supply chain security:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/Tbiscg09-Ac\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Integrating sec into DevSecOps\n\nThe first step in securing the software supply chain is to create a cohesive DevSecOps approach to software development. In doing so, organizations can expand security in DevOps beyond basic tasks and better [understand myriad threat vectors](/blog/top-challenges-to-securing-the-software-supply-chain/).\n\n_[Security in the modern DevOps solution](/blog/are-you-ready-for-the-newest-era-of-devsecops/) goes beyond just shifting security features left to empower the developers to find and fix security flaws, but also provides end-to-end visibility and control over the entire SDLC to create, deliver, and run the applications._\n\nTeams that integrate security practices throughout their development process are 1.6 times more likely to meet or exceed their organizational goals, according to the Google Cloud DevOps Research and Assessment (DORA) “Accelerate State of DevOps 2021 Report”.\n\nSome [best practices elite DevSecOps teams use](/blog/elite-team-strategies-to-secure-software-supply-chains/) are:\n\n- Apply common controls for security and compliance\n- Automate common controls and CI/CD\n- Apply [zero-trust principles](/blog/why-devops-and-zero-trust-go-together/)\n- Inventory all tools and access, including infrastructure as code\n- Consider unconventional scale to find unconventional vulnerabilities\n- Secure containers and orchestrators\n\n## Understanding federal and industry mandates\n\nThe Biden administration has been singular in its demand that federal agencies and their vendors [make significant improvements in software supply chain security](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/).\n\nThat sense of urgency has trickled down to the standards bodies, including the National Institute of Standards and Technology (NIST) and its [Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf), the Cybersecurity and Infrastructure Agency’s work on [Software Bill of Materials standards](https://www.cisa.gov/sbom), and [SLSA](https://slsa.dev/), a cross-industry collaboration on a security framework to secure the supply chain.\n\nCompliance officers within organizations are looking to DevSecOps teams to make it easy for them to audit the development life cycle and attest to requirements in these mandates.\n\n## How a DevOps platform helps \n\nIn our [2022 Global DevSecOps survey](/developer-survey/), respondents overwhelmingly told us that secure software development is now an imperative for their organization and that they believe security is the top reason to deploy a DevOps platform. \n\nA DevOps platform can certainly help [protect against software supply chain attacks](/blog/devops-platform-supply-chain-attacks/). Here are some examples how:\n\n- End-to-end visibility and auditability: Who changed what, where, and when.\n\n- Consistent application and administration of policies: Both what policies are used where, and the actions taken for exceptions\n\n- More intelligent response through greater end-to-end context\n\n- Reduced attack surface of a simplified toolchain\n\nDevOps platforms can even support more sophisticated software supply chain security techniques such as [securing pipeline builds with code signing](/blog/secure-pipeline-with-single-sign-in/). Code signing is an area of interest to standards bodies setting requirements for protecting software supply chains.\n \n## GitLab’s strengths in software supply chain security\n\nGitLab has been at the leading edge of DevSecOps, helping organizations to evolve their security practices from traditional application testing.\n\nFor instance, rather than being performed by security pros, using their own tools, at the end of the development cycle, security testing is automated within the CI pipeline with findings delivered to developers while they are still iterating on their code. Read how GitLab is also [revolutionizing CI and security, and remediation practices](/blog/gitlab-is-setting-standard-for-devsecops/).\n\nGitLab is laser-focused on enabling organizations to establish and manage security and compliance guardrails that allow developers to run fast while also managing risk, including the introduction of [continuous compliance and policy engines](/blog/gitlabs-newest-continuous-compliance-features-bolster-software/), as well as [automated attestation](/blog/securing-the-software-supply-chain-through-automated-attestation/) and [SBOMs](/blog/the-ultimate-guide-to-sboms/).\n\nThe GitLab partner ecosystem helps the platform to meet even more security needs, including [generating SBOMs\nautomatically](/blog/gitlab-and-testify-sec-witness-alliance/) and [protecting software from malicious modules](/blog/terraform-as-part-of-software-supply-chain-part1-modules-and-providers/).\n\nMore on GitLab’s software supply chain security vision can be found [here](/blog/gitlab-supply-chain-security/). And learn even more about securing the software supply chain as GitLab Field CTO [Lee Faus](https://gitlab.com/lfaus) answers some burning questions:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/HubJIQ-x2EA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[807,695,9],{"slug":4280,"featured":6,"template":698},"the-ultimate-guide-to-software-supply-chain-security","content:en-us:blog:the-ultimate-guide-to-software-supply-chain-security.yml","The Ultimate Guide To Software Supply Chain Security","en-us/blog/the-ultimate-guide-to-software-supply-chain-security.yml","en-us/blog/the-ultimate-guide-to-software-supply-chain-security",{"_path":4286,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4287,"content":4293,"config":4297,"_id":4299,"_type":13,"title":4300,"_source":15,"_file":4301,"_stem":4302,"_extension":18},"/en-us/blog/thelastmile-gitlab",{"title":4288,"description":4289,"ogTitle":4288,"ogDescription":4289,"noIndex":6,"ogImage":4290,"ogUrl":4291,"ogSiteName":685,"ogType":686,"canonicalUrls":4291,"schema":4292},"Inside the collaboration between GitLab and The Last Mile","GitLab teamed up with The Last Mile to bring open source DevOps and tech mentorship to incarcerated populations across the United States.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681743/Blog/Hero%20Images/tlm-blogpost-banner.png","https://about.gitlab.com/blog/thelastmile-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Inside the collaboration between GitLab and The Last Mile\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Christina Hupy, Ph.D.\"}],\n \"datePublished\": \"2020-11-13\",\n }",{"title":4288,"description":4289,"authors":4294,"heroImage":4290,"date":3315,"body":4295,"category":784,"tags":4296},[1136],"\n\n[The Last Mile (TLM)](https://thelastmile.org/), an organization focused on changing lives through technology, is tackling the daunting problem of mass incarceration in the United States by providing education and career training opportunities to incarcerated individuals to help break the generational cycle of incarceration. GitLab team members with similar passions and ideas connected with The Last Mile team and built a partnership to help bring the tech industry and mentorship directly to incarcerated individuals.\n\n## AMA to Coffee Chat to Partnership\n\nThe idea for TLM partnership originated during an AMA (or \"Ask Me Anything\" session) between GitLab CEO, [Sid Sijbrandij](/company/team/#sytses), and GitLab team members. [In one of these AMAs](https://www.youtube.com/watch?v=qi9zrymBO8o), [Tucker Logan](/company/team/#tuckcodes), a federal solutions architect at GitLab, asked Sid about the inspiration behind his [tweet](https://twitter.com/sytses/status/1227319454817804288) about mass incarceration. In a follow-up question, [Morgen Smith](/company/team/#msmith6), a sales development representative (SDR) for the Americas, asked Sid if GitLab would consider creating initiatives to help combat the school-to-prison pipeline.\n\nAs a former educator, Morgen has witnessed first-hand the national trend of disadvantaged youth being agressively disciplined in schools, which can then lead to juvenile offenses and later to formal charges. During the AMA, Morgen asked Sid: \"What do you think GitLab could do to encourage minority youth in this situation to be inspired by opportunities in tech?\" Sid shared his support and passion for the topic, and invited Morgen and Tyler to host an [open coffee chat](/company/culture/all-remote/informal-communication/#coffee-chats) on the topic to brainstorm ideas and next steps.\n\nDuring the coffee chat, Sid decided to take the smallest step, first. He visited San Quentin State Prison in San Rafael, Calif., and organized a call with Chris Redlitz, a co-founder of TLM. It turns out that TLM was using GitLab internally and also using the GitLab Community Edition to train nearly 300 students participating in their programs about how to use DevOps.\n\nTLM is a nonprofit program that started at San Quentin. TLM works with the incarcerated populations at men’s, women’s, and young adult correctional facilities to help them build relevant skills in technology with the goal of preparing individuals for successful reentry and building careers in business and technology. Today, TLM is in 23 classrooms across six states and has served 622 students since its inception.\n\n## TLM students learn DevOps with GitLab\n\nParticipants in TLM use the self-managed, free open core version of GitLab in their courses on Web Development. Each of the twenty individual classrooms have their own self-managed instance which around 20 students use to create and host their own private repositories. The sandbox environments are deployed centrally via Google Cloud. The core curriculum includes HTML/CSS and JavaScript, Node.js, Express.js, React.js, and Mongodb. GitLab is used primarily as a [source code management tool](/solutions/source-code-management/) for the students. Students write and commit code to personal repositories during course assignments. TLM Remote Instruction team also manages student-facing GitLab repositories to demonstrate industry best practices in merging, code collaboration, and version control platforms. Additionally, TLM leverages GitLab by providing students access to their repositories after they are released from prison, preserving commit history and all version control for the aspiring coders.\n\n\"By utilizing GitLab, The Last Mile students become comfortable using a best-in-class open source DevOps tool,\" says Tulio Cardozo, IT Manager, TLM. \"This experience empowers our students as aspiring software engineers, enabling them to enter the workforce with the collaboration and communication framework skills employers demand.\"\n\nThe GitLab team is partnering with the TLM Programs department to organize a series of webinars and workshops for the students. The first webinar kicked off in June of 2020 and was broadcast to 27 students (men, women, and youth programs), across four classrooms in several states. The topic was an introduction to GitLab and DevOps. Sid joined and shared the story of founding GitLab and his journey in tech. [Brendan O’Leary](/company/team/#brendan), a senior developer evangelist at GitLab, provided an overview of DevOps and explained how GitLab is the first single application for the entire DevOps lifecycle.\n\n\"The students appreciated the information on how to get started as new developers. Sid and Brendan helped the students believe they could accomplish anything with enough hard work,\" says a classroom facilitator from the Pendleton Youth Correctional Facility in Indiana.\n\nThe TLM team added that the webinar exposed students to a large company that works remotely and introduced them to an industry-recognized brand that the students use. In addition to the value of the content itself, there was a Q&A portion of the session where the studetns asked questions about the technology itself, such as how to start an open-source project and protecting intellectual property in open source, and about the facilitators' personal journey into tech.\n\nWatch the webinar with GitLab and TLM below.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/ejHmvMjXJVU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn addition to the general workshop, the teams also collaborated on more technical content. The students at the Pendleton Juvenile Correctional Facility had a very special guest visit their [Web Development Fundamentals Course](https://thelastmile.org/our-work/), [Natalia Tepluhina](/company/team/#ntepluhina). Natalia, who currently lives in the Ukraine, is a frontend engineer at GitLab and also serves as a [core Vue.js team member](https://vuejs.org/v2/guide/team.html) and [core team member](/community/core-team/) of GitLab itself. Natalia answered a variety of questions about how to approach learning Javascript and provided a few demos related to specific questions from the students.\n\n## Mentorship for a career in DevOps\n\nGitLab and TLM also partnered on a series of Technical recruiting workshops with the classrooms. These have definitely been one of the highlights of the partnership thus far. In these workshops, a GitLab recruiter gave a presentation on the technical recruiting processes at GitLab, best practices during the application process and interview process, as well as an overview of what to expect during an interview. During each of the four sessions, the recruiters directly engaged with the participants, who asked a variety of questions, including:\n\n* How do I address incarceration on my resume?\n* What about background checks?\n* How do I gain professional experience while incarcerated?\n\nThe GitLab recruiting team was very sensitive to the participants' concerns and provided honest, clear answers, and great suggestions. The recruiters shared that during the process candidates should think of their recruiter as a resource, and they can always ask to speak to the People team at GitLab in confidence if it would help reassure them with any concerns they have regarding their criminal records. The recruiters encouraged the students to highlight their work in TLM courses on their resume and think about whether they can use course projects to start to build a portfolio. In addition, the facilitators encouraged participants to think about contributing to open source projects as a way to build technical skills, increase their network and mentorship opportunities.\n\n## How can open source help incarcerated populations gain experience in tech?\n\nThe discussion around contributing to open source projects as a way to build technical skills sparked a few different exciting ideas with the teams. One of these ideas was to hold a first time contributor workshop with alumni from TLM. The workshop was held in September 2020 had 16 alumni participants, four GitLab team members, including Sid, and five TLM team members. The workshop covered the basics on how to contribute to GitLab and demonstrated the step-by-step process. Participants were [provided an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/247284) with a list of simple fixes with the label [\"good-for-new-contributors\"](https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=good+for+new+contributors) in the GitLab docs or handbook with typos or other minor changes. We had a few merge requests after just a few hours of the workshop! Participants were encouraged to tag GitLab team members for recognition and to win a pair of tanuki socks – by the end of the week we had given away six pairs of socks.\n\nParticipants and instructors appreciated the opportunity to learn in a hands-on way during the workshop:\n\n\"Thank you for the opportunity to participate in the GitLab workshop. I am so grateful to the GitLab staff for taking the time to introduce those of us who are new to GitLab to the history and functionality of the company. I learned so much, not just about how I can utilize GitLab to accomplish personal tasks more efficiently, but also how I can contribute and collaborate more with others and contribute to my local and global communities.\" - TLM staff and alumna.\n\nThe GitLab team found the experience equally rewarding. \"Working with The Last Mile was such a rewarding experience! When I think about how our product takes in contributions from all over the world and knowing it is also leveraged by those currently and or previously incarcerated really shows how truly 'inclusive' Git can be. Additionally, the empowerment it offers and the gift of knowledge and skill that can't be taken away is invaluable,\" says [Candace Brydsong Williams](/company/team/#cwilliams3), manage of the Diversity, Inclusion and Belonging program at GitLab.\n\n## How TLM uses GitLab technology\n\nGitLab also provides free licenses of our top-tier hosted application for the TLM team, who use our DevOps technology in nearly every aspect of their operations.\n\nTLM transitioned from GitHub to GitLab in 2019 after we provided the licenses. Initially, GitLab was used primarily in TLM's engineering department to track all internal processes with issues and Wikis. Infrastructure as code data and internal information is stored in repositories. Soon, TLM adopted GitLab technology in their education and programs departments, where it is now being used for project management. TLM now uses sprint planning, milestones, issues, priority levels, burndown charts, and issues boards to streamline project management across their departments.\n\nThe Last Mile has introduced numerous new and distinct use cases for GitLab. These include:\n\n* Issues are used to manage classroom facilities including to keep track of the impacts of COVID-19 on each classroom. For example, status updates are recorded on the issue and in the comments.\n* [The Last Mile’s reentry program](https://thelastmile.org/our-work/#reentry) uses GitLab to track returned citizen onboarding and service delivery process as well as tracking internal workloads, task efforts, and collaboration across teams. To-do lists are used to manage actions and labels are used to view the status of various efforts.\n\n\"The GitLab platform provides The Last Mile with a remarkable range of solutions -- from our application of GitOps workflows for managing our hybrid infrastructure, to our org-wide application of issues across teams,\" says Mike Bowie, Director of Engineering, The Last Mile. \"By solving such a broad range of our needs, GitLab enables us to focus on delivering value into our programs, instead of administering and maintaining a plethora of disparate tools.\"\n",[787,1263,9,934,1306],{"slug":4298,"featured":6,"template":698},"thelastmile-gitlab","content:en-us:blog:thelastmile-gitlab.yml","Thelastmile Gitlab","en-us/blog/thelastmile-gitlab.yml","en-us/blog/thelastmile-gitlab",{"_path":4304,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4305,"content":4311,"config":4316,"_id":4318,"_type":13,"title":4319,"_source":15,"_file":4320,"_stem":4321,"_extension":18},"/en-us/blog/thoughts-on-open-source",{"title":4306,"description":4307,"ogTitle":4306,"ogDescription":4307,"noIndex":6,"ogImage":4308,"ogUrl":4309,"ogSiteName":685,"ogType":686,"canonicalUrls":4309,"schema":4310},"What to consider with an open source business model","CEO Sid Sijbrandij discusses the role of transparency and contribution in an open source business model.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682919/Blog/Hero%20Images/opensourcecover.jpg","https://about.gitlab.com/blog/thoughts-on-open-source","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What to consider with an open source business model\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2019-07-05\",\n }",{"title":4306,"description":4307,"authors":4312,"heroImage":4308,"date":4313,"body":4314,"category":784,"tags":4315},[846],"2019-07-05","\nAn open source business model used to be relatively rare but successes at companies like Red Hat and our own have changed that. As the idea of open source continues to gain traction with startups, our CEO [Sid Sijbrandij](/company/team/#sytses) talked with [OSS Capital](https://oss.capital) founder Joseph “JJ” Jacks about some of the changing – and nuanced – requirements to play in this complicated and competitive space.\n\n## How to build a business model for open source software businesses\n\nOpen source has always required a social contract between the owners of the project and the community that uses and contributes to it, Sid explains, and that’s something GitLab benefited from when the company was experimenting with the idea of [how to get paid](/blog/monetizing-and-being-open-source/). But today, with an [“open core” business model](/blog/gitlab-is-open-core-github-is-closed-source/) involving both open source and proprietary code, there’s another level, one where the community can have a much bigger voice on releases. “How much of what you make ends up in the open source and how much is proprietary?” Sid asks. “We try to find a good balance then when we go for a few releases where we're a bit weak on the open source side, people will post comments on our blog post and we can point to the stuff that's coming down the pipe. The wider community keeps us honest.”\n\nJJ, whose company is focused on investing in commercial open source startups, asks Sid about the ways open source licensing has changed. It’s a broad landscape, Sid offers: “You can go from the free software movement to open source to open core to these new licenses that are now made by Redis and Mongo and Confluent, the so-called non-compete licenses, which say it's kind of open source except if you're a hyper cloud, then you have to pay us.”\n\nThe “freemium” business model has also come along. “(That) makes it very easy to get trials and you can use it for free for a long time, but it's commercial. And then you have the completely proprietary Oracle light model. So licensing is much more of a spectrum today.”\n\n> The wider community keeps us honest.\n\n## Time to contribute\n\nThe spectrum of licensing isn’t necessarily a bad thing. Sid points to the free software movement that requires a user to contribute as a positive sign, but admits there is still a long way to go before this behavior is second nature. Companies try to put restrictions in, or to enforce things via copyright, Sid says, “but we’re not there yet, not by a long stretch. Lots of car manufacturers don’t contribute back to Linux so please start doing that everyone.”\n\nOf course, contributions from the community can only take a company so far. “Open core allowed us to compete with the proprietary vendors,” Sid says. “GitLab would not have survived as an open source project because open source projects sometimes implode under their popularity. There are some great examples of projects that did well – Kubernetes, Linux, and PostgreSQL – but without our business model we would not be able to compete at this point in this market with Microsoft and Atlassian.”\n\n> Open core allowed us to compete with the proprietary vendors.\n\n## Transparency in all things\n\nJJ wonders how much transparency and expectation setting have helped GitLab as an open core company, and Sid’s quick to point out it’s essential. “[Transparency](https://handbook.gitlab.com/handbook/values/#transparency) is in our top three values and we started with that because we didn’t want to alienate the wider community.” Transparency shortens the feedback loop and makes it more straightforward to deal with mistakes or challenging situations. When we [decided to merge both of GitLab’s code bases](/blog/merging-ce-and-ee-codebases/), we did it openly and honestly, wrote a blog post about it, and then waited to see how it was received. “I think by being transparent about our plan up front, what could have turned into a big flame war was a really positive experience for both the people at the company working really hard on this project, but also the wider community feeling like we take their interests seriously. And if we would have made a mistake, this was a proposal. They could have just said, ‘Okay, you're making a mistake here and there,’ and we could have fixed it before people were upset, and we lost trust.”\n\nWould Sid recommend “transparency first” to a startup open core company? Absolutely and it has to be there from the beginning, he says. “Values are really hard to introduce later in a company. I'm pushing for a bit more transparency now, and it's super, super, super, super hard. So, if you plan to do it, do it from the start, and (understand) it feels very counterintuitive to be open. And there are some areas where it's naturally harder to be as transparent. Security comes to mind. So, it's a daily struggle. People see that it works, but it requires effort at any layer of the company to actually do it, but I'm really proud of how far we've come.”\n\n_GitLab CEO Sid Sijbrandij occasionally sits down for a \"[pick your brain](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings)\"\nmeeting with people seeking advice on open source, remote work, or a discussion of other things related to GitLab. Read [other posts in the series here](/blog/tags.html#pick-your-brain)._\n\nCover image by [Natasha Miller](https://unsplash.com/@tashography?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[268,9,787,787],{"slug":4317,"featured":6,"template":698},"thoughts-on-open-source","content:en-us:blog:thoughts-on-open-source.yml","Thoughts On Open Source","en-us/blog/thoughts-on-open-source.yml","en-us/blog/thoughts-on-open-source",{"_path":4323,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4324,"content":4329,"config":4334,"_id":4336,"_type":13,"title":4337,"_source":15,"_file":4338,"_stem":4339,"_extension":18},"/en-us/blog/tips-for-mastering-video-calls",{"title":4325,"description":4326,"ogTitle":4325,"ogDescription":4326,"noIndex":6,"ogImage":1708,"ogUrl":4327,"ogSiteName":685,"ogType":686,"canonicalUrls":4327,"schema":4328},"5 Tips for mastering video calls","All-remote work wouldn't be possible without communication tools like video conferencing. Here are a few tips we use at GitLab.","https://about.gitlab.com/blog/tips-for-mastering-video-calls","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 Tips for mastering video calls\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Betsy Church\"}],\n \"datePublished\": \"2019-08-05\",\n }",{"title":4325,"description":4326,"authors":4330,"heroImage":1708,"date":4331,"body":4332,"category":910,"tags":4333},[1199],"2019-08-05","\nAs remote and distributed work becomes more popular around the world, technology is\nconstantly evolving to support it. Communication tools, particularly video conferencing, allow\npeople to [connect and collaborate from anywhere with an internet connection](/blog/how-remote-work-at-gitlab-enables-location-independence/).\n\nFor an [all-remote](/company/culture/all-remote/), global company like\nGitLab, video calls are even more crucial to how\nwe [communicate](/handbook/communication), get work done as a team,\nand get to know each other.\n\nWhile best practices for video calls may seem obvious to the experienced remote\nprofessional, they often don’t come naturally to someone who’s used to working in a\ntraditional office setting. Here are some of the tips and tricks we use at\nGitLab to help you master the art of a successful video call.\n\n## 1. Know when a call is necessary\n\nFirst things first: Do you even need to have a video call? We’ve all had those\nwork weeks that are overloaded with calls or meetings, when oftentimes the\ntopic could have been discussed asynchronously in an email, Google Doc, or even a GitLab issue.\n\nWe default to [asynchronous communication](https://handbook.gitlab.com/handbook/communication/) at\nGitLab for many reasons. For one, it means there is far more documentation of your project\nand the work being done. On a global team, asynchronous communication allows for progress to continue even after\none person’s working day ends. Asynchronous work is also naturally more inclusive\nbecause [everyone can contribute](/company/mission/#mission).\n\nBut that doesn’t mean it works for every conversation. At GitLab, our rule of thumb is\nthat if you go back and forth about a topic three times, it’s time for a video call to\ntalk it out in real time.\n\n## 2. Use the right equipment correctly\n\nThe headphones and equipment you use can make a big difference in a successful video call,\nbut only if you use them the right way.\n\nIt's tempting to join a call using the built-in mic in your laptop, but grab a set of headphones instead.\nThey help eliminate interference and background noise for others on the call, making the conversation flow more smoothly.\n\nWhen you're preparing for your call, allow yourself a few minutes to test your audio and video, especially if it's the first time you've used that video conferencing tool.\n\nAnother equipment misstep that happens often, particularly in companies with a mix of in-office and remote\nemployees, is what we call “hybrid calls.” A [hybrid call](https://handbook.gitlab.com/handbook/communication/#hybrid-calls-are-horrible)\n is when two (or more) people in one room try to share the same equipment during a call\n – laptops, cameras, even headphones. Not only does this create a negative and non-inclusive\n experience for anyone who’s not in the room, it rarely works well for the people sharing the equipment.\n\nDo your remote team members a favor: Use your own laptop, camera, and headphones (and\npreferably, your own conference room) so that you can talk, screen share, take notes, and be seen clearly.\n\n## 3. Turn on your video\n\nOne of the best aspects of video calls is that they allow us to have high-fidelity conversations without being in the same location.\nBut if you don't use your camera, it's tough to get to know the person you're meeting with.\nThis is especially important at GitLab or any all-remote company, since we only get together in person every\nso often.\n\nWhile it's certainly not required, we encourage team members to default to using their cameras whenever possible.\nWhether you just came back from the gym, you’re eating lunch at your desk, or your dog,\nspouse, or child is in the room (have them wave!), still consider turning on your camera.\nThese are all typical parts of a remote workday, and might even spark a conversation that\nhelps you get to know a member of your team better.\n\n## 4. Speak up\n\nIt might go against your instincts around meeting etiquette, but (politely) speaking up or\neven interrupting someone on a video call is perfectly okay.\n\nThis takes some getting used to because the latency on video calls means you may be\ntalking over someone for longer than you would in person. But you can’t have a dynamic,\ncollaborative meeting unless people are able to contribute, ask questions, and add context in the moment.\n\nIf you’re on a call and you notice a team member who appears to be struggling to get a word in,\ndon’t hesitate to specifically invite them into the conversation so that they have a\nchance to speak as well. Your call will be more productive if everyone feels able to participate.\n\n## 5. Watch the clock\n\nIt’s hard to decide which is more important: starting a call on time or ending it on time.\nSo we aim for both. A meeting that runs even two or three minutes over can put someone’s entire schedule behind.\n\nIf your team regularly struggles to end on time, try assigning someone ahead of each meeting to\nbe the time keeper and give everyone a heads up when the call is almost over. If you weren’t\nable to get through your whole agenda in the allotted time, either schedule an additional call,\nor continue to communicate about it asynchronously instead.\n\n___\n\nLearn more about GitLab’s approach to [all-remote work](https://about.gitlab.com/company/culture/all-remote/).\nInterested in joining our team? Browse our [vacancies](https://about.gitlab.com/jobs/).\n\nCover image by [Trust \"Tru\" Katsande](https://unsplash.com/@iamtru?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}\n",[1097,934,9],{"slug":4335,"featured":6,"template":698},"tips-for-mastering-video-calls","content:en-us:blog:tips-for-mastering-video-calls.yml","Tips For Mastering Video Calls","en-us/blog/tips-for-mastering-video-calls.yml","en-us/blog/tips-for-mastering-video-calls",{"_path":4341,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4342,"content":4348,"config":4353,"_id":4355,"_type":13,"title":4356,"_source":15,"_file":4357,"_stem":4358,"_extension":18},"/en-us/blog/toolchain-security-with-gitlab",{"title":4343,"description":4344,"ogTitle":4343,"ogDescription":4344,"noIndex":6,"ogImage":4345,"ogUrl":4346,"ogSiteName":685,"ogType":686,"canonicalUrls":4346,"schema":4347},"How to overcome toolchain security challenges with GitLab","Use GitLab to control your toolchain sprawl, improve team communication and productivity, and secure your DevOps lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673158/Blog/Hero%20Images/toolchain-security-gitlab-cover.jpg","https://about.gitlab.com/blog/toolchain-security-with-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to overcome toolchain security challenges with GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vanessa Wegner\"}],\n \"datePublished\": \"2019-11-20\",\n }",{"title":4343,"description":4344,"authors":4349,"heroImage":4345,"date":4350,"body":4351,"category":807,"tags":4352},[887],"2019-11-20","\nIntegrated toolchains [are on the rise](https://go.forrester.com/blogs/the-rise-fall-and-rise-again-of-the-integrated-developer-tool-chain/), according to Forrester analyst Christopher Condo. Integrated toolchains actually faded out for a while\nbecause developers wanted to avoid vendor lock in - and because sometimes solutions didn’t [play well with others](/handbook/product/gitlab-the-product/#plays-well-with-others).\nBut today, the growing popularity of CI/CD and open source means more free tools in the software delivery market and dev teams are happily adding them to their arsenal.\n\nUnfortunately, too much of a good thing can be a bad thing. Integrating,\nmanaging, and protecting the DevOps lifecycle has become a burden on many teams.\nIn a recent [Forrester report](/resources/whitepaper-forrester-manage-your-toolchain/),\nover three quarters of survey respondents said their teams use more than two\ntoolchains to support software delivery, and a majority reported that each\ntoolchain is made up of six or more tools.\n\nDevOps fosters innovation but an overly complex toolchain stifles it.\nToolchain maintenance and management shouldn’t consume resources that could\notherwise be invested in product development and innovation, but that’s the reality\non the ground for too many teams.\n\n## Complex toolchains compromise security\n\nManaging these toolchains has become a monumental task, with some businesses\ndevoting 10% of their dev team to toolchain maintenance, according to the Forrester report.\nBesides inhibiting productivity, toolchain complexity also poses a risk to\nyour security posture.\n\nMost teams are tasked with integrating their toolchains by manual means, such\nas plugins and scripts or hard-coded custom integrations. Not only is this\nlabor-intensive, it also adds the significant risk of human error.\nAdditionally, more tools mean more authentication and security requirements to\nmanage, less visibility into the software\nlifecycle, and no view into the process of maintaining the toolchain\nitself - all of which adds unnecessary risk for your IT and dev teams to deal\nwith.\n\nMeanwhile, the consequences of poor security practices are mounting. [According to IBM](https://databreachcalculator.mybluemix.net),\nit takes businesses an average of 279 days to identify and contain a breach,\nat an average cost of $3.9 million.\n\n## DevSecOps with GitLab: your knight in shining armor\n\nLuckily, we’re here to save the day. [GitLab is a single out-of-the-box solution\nfor your **entire** software delivery lifecycle](/stages-devops-lifecycle/) -\nsolving your authentication and requirement woes right off the bat. We’ve built\na number of security and risk prevention measures into many of the DevOps lifecycle\nphases: code reviews, static and dynamic [application security\ntesting](/topics/devsecops/), dependency and container scanning, license compliance, and incident\nmanagement. We also have an exciting array of new features on the horizon, which\ncan be found in the table below.\n\n![GitLab is a complete DevOps platform, delivered as a single application.](https://about.gitlab.com/images/blogimages/toolchain-security-gitlab-inline.png){: .shadow}\n\nDevSecOps is a product of the shift-left movement, integrating security into\nthe earliest possible phases of DevOps. Bringing security in at the beginning\nhelps teams understand where certain testing processes and controls need to\nfall, and helps save time, energy, and resources as you move through the final\nphases of DevOps.\n\nGitLab’s single application eases communication between teams, increases\nvisibility, and streamlines your DevOps lifecycle as a whole. We’re here to\nhelp your teams achieve faster delivery cycles without compromising quality,\nand bring your security practices to the speed of the business.\n\nCover image by [Jukan Tateisi](https://unsplash.com/@tateisimikito) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[695,9,807],{"slug":4354,"featured":6,"template":698},"toolchain-security-with-gitlab","content:en-us:blog:toolchain-security-with-gitlab.yml","Toolchain Security With Gitlab","en-us/blog/toolchain-security-with-gitlab.yml","en-us/blog/toolchain-security-with-gitlab",{"_path":4360,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4361,"content":4367,"config":4372,"_id":4374,"_type":13,"title":4375,"_source":15,"_file":4376,"_stem":4377,"_extension":18},"/en-us/blog/top-five-takeaways-from-the-developer-survey",{"title":4362,"description":4363,"ogTitle":4362,"ogDescription":4363,"noIndex":6,"ogImage":4364,"ogUrl":4365,"ogSiteName":685,"ogType":686,"canonicalUrls":4365,"schema":4366},"Top 5 takeaways from the 2018 Developer Survey","GitLab's director of product marketing discusses the challenges facing DevOps adoption and other key findings from our 2018 Developer Survey.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680105/Blog/Hero%20Images/top-five-takeaways-blog-image.jpg","https://about.gitlab.com/blog/top-five-takeaways-from-the-developer-survey","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Top 5 takeaways from the 2018 Developer Survey\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n \"datePublished\": \"2018-05-14\",\n }",{"title":4362,"description":4363,"authors":4368,"heroImage":4364,"date":4369,"body":4370,"category":693,"tags":4371},[2125],"2018-05-14","\n_Our [2022 Global DevSecOps Survey](/developer-survey/) has the latest insights from over 5,000 DevOps professionals._\n\nWhile the merits of cross-functional workflows are becoming more accepted in the software development space, it still has quite a way to go. In fact, [GitLab’s survey of 5,000 software professionals](/developer-survey/previous/2018/) found that only 23 percent of respondents are working with a DevOps workflow.\n\nThis is one of five top takeaways from the annual report on software development trends and the impact continuous integration and automation have on the way IT teams work.\n\n- [What’s in the webcast](#whats-in-the-webcast)\n- [Watch the recording](#watch-the-recording)\n- [Top takeaways](#top-takeaways)\n\n## What’s in the webcast\n\nThe discussion kicks off with the differing outlooks managers and developers have on DevOps adoption and the source of bottlenecks in the development process. We move on to highlight the distinctions between high- and low-performing teams and the role open source tools have in software development. The discussion then delves into the way continuous integration helps teams get working code out of the door faster.\n\n## Watch the recording\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/7hgoeV6LcFo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Top takeaways\n\n### Managers are more optimistic about their DevOps adoption progress than developers\n\n>Companies tend to look at DevOps as the next transformational methodology that's going to solve all software delivery problems, and of course there's a lot of truth in that when done really well. What we're finding is when you actually go and survey these organizations, managers and the management layer seem to have a more optimistic view of how they are progressing and what they can do with it. And though developers find the promise in it, they tend to agree less with the optimism of management. From our perspective, that makes a lot of sense because developers are in the trenches tooling, retooling, trying to configure, making that CD pipeline work, always kind of running into different roadblocks and trying to solve that all the time. So, although they're excited, I think their viewpoint is not necessarily as rosy about it when compared to management.\n\n### Developers say most delays in the development process are in the testing phase, while managers say the majority of bottlenecks are attributed to the planning process\n\n>Everybody acknowledges that there are bottlenecks and delays in this development pipeline. When doing DevOps, you still get stuck. But where they actually encounter these delays and bottlenecks varied from team to team. The majority of this was in testing, the next one was planning. Development, operations, and practitioner teams actually found most of the bottlenecks and delays in their actual phases of work, whether this was testing the plan to production, etcetera. Management was found to be more frustrated and concerned about the planning phase of getting things kick started. - Ashish Kuthiala\n\n>Fifty-two percent of people say that testing is where they encounter the most delays. I don't think that's a number to be taken lightly. This is why continuous testing, automated testing is such a big piece of the DevOps software development lifecycle. If that's the single biggest cause for delay and we can automate more of that testing, the time it takes has got to come down. - Alan Shimel\n\n### Open source tools play an integral role in the software development process\n\n>We're finding that open source tools are becoming a very critical component that developers choose to help solve their problems. People are starting to look at tools that they can integrate with their stack and modify or contribute to; and they want to be recognized as well. So they're starting to turn to tools that are malleable, tools that they can use and understand what's underneath the hood. There's a good community around open source because as developers face problems, they can ask their peers for help and also help others. - Ashish Kuthiala\n\n### Teams that self-identify as high performing do DevOps well\n\n>Teams that move fast work on smaller pieces of code and get them out of production quickly, i.e. they do DevOps well and they assess themselves as higher performing teams ...\nFor these teams that do well, we found that removing roadblocks in the development process starts with continuous integration. If you are doing continuous integration well and automating that portion of the lifecycle along with others, it makes a huge impact in removing bottlenecks. You have to ship and get the code or the configuration change production ready right away. The more you wait, the more it piles it up and the harder it becomes. - Ashish Kuthiala\n\nPhoto by [Caspar Rubin](https://unsplash.com/photos/fPkvU7RDmCo) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[695,850,1162,912,9],{"slug":4373,"featured":6,"template":698},"top-five-takeaways-from-the-developer-survey","content:en-us:blog:top-five-takeaways-from-the-developer-survey.yml","Top Five Takeaways From The Developer Survey","en-us/blog/top-five-takeaways-from-the-developer-survey.yml","en-us/blog/top-five-takeaways-from-the-developer-survey",{"_path":4379,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4380,"content":4385,"config":4390,"_id":4392,"_type":13,"title":4393,"_source":15,"_file":4394,"_stem":4395,"_extension":18},"/en-us/blog/translating-gitlab",{"title":4381,"description":4382,"ogTitle":4381,"ogDescription":4382,"noIndex":6,"ogImage":1462,"ogUrl":4383,"ogSiteName":685,"ogType":686,"canonicalUrls":4383,"schema":4384},"Help us speak your language!","GitLab is available in many languages, but there's always more translation work to be done. Here's how you can contribute to translating GitLab.","https://about.gitlab.com/blog/translating-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Help us speak your language!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-01-08\",\n }",{"title":4381,"description":4382,"authors":4386,"heroImage":1462,"date":4387,"body":4388,"category":784,"tags":4389},[1281],"2019-01-08","\nOne of the lesser-known features of GitLab is that it has been translated into many languages by community members. If you have only seen GitLab in (American) English, you can go to your [Profile page](https://gitlab.com/profile) and change your **Preferred language** to see it in another language.\n\n![Selecting preferred language](https://about.gitlab.com/images/blogimages/translation-blog/preferred_language_chinese.png){: .shadow.small.center}\n\n![GitLab in Chinese](https://about.gitlab.com/images/blogimages/translation-blog/gitlab_in_chinese.png){: .shadow.small.center}\n\nWe are proud of the work done by so many dedicated community members to help translate GitLab, but this is ongoing work, and we also have many languages that are just getting started with translation. That's where you come in!\n\n## Why translate GitLab?\n\nSome may say that GitLab is used by technical people who are already used to using a lot of different software in English, and translation is not really necessary. That may be true, but having the software available in local languages that people are more comfortable with lowers the barrier to entry not only for users, but for contributors too. Maybe it's because GitLab is an [all-remote company](/blog/the-case-for-all-remote-companies/) with [employees in nearly 50 countries](/company/team/), but GitLab team-members appreciate the benefits of localized software in local communities.\n\n## How is GitLab translated and how do I start contributing?\n\nThe translation is managed at [translate.gitlab.com](https://translate.gitlab.com/) using [Crowdin](https://crowdin.com/). First, a phrase (e.g. one that appears in the GitLab user interface or in error messages) needs to be internationalized before it can be translated. The internationalized phrases are then made available for translations on [translate.gitlab.com](https://translate.gitlab.com/). As each phrase is translated, it is added to the translation file, and will then be merged into future releases. You can find more details on how GitLab is translated in the [Translate GitLab documentation](https://docs.gitlab.com/ee/development/i18n/).\n\nAs you can see in the [translation activity stream](https://translate.gitlab.com/project/gitlab-ee/activity_stream), the majority of translations are contributed by community members. You're probably already familar with GitLab's motto, \"Everyone can contribute,\" and contributing translation is even easier than contributing code. All you need is an account on [CrowdIn](https://crowdin.com/) plus a browser, and you are ready to translate GitLab to a language of your choice. So if you're looking for ways to contribute and know other languages, translation is a great place to get started.\n\nDuring the [GitLab Hackathon](/community/hackathon/) in September, one of our [Core Team](/community/core-team/) members [Hannes Rosenögger](https://gitlab.com/haynes) presented a session on translation where he walked through how community members can contribute. You can watch the recording:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/LJ9oSSx0qyY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Where do we need help?\n\nAs you can see from the screenshot below, GitLab is almost fully translated into several languages, such as Chinese (both Simplifed and Traditional), French, German, Filipino, Brazilian Portuguese, Ukrainian, etc. However, many languages are in early stages, with a lot of translation left to be done and may also need [proofreaders](https://docs.gitlab.com/ee/development/i18n/proofreader.html) to help review and approve translations. You can find steps to becoming a proofreader also outlined in [the proofreader documentation](https://docs.gitlab.com/ee/development/i18n/proofreader.html#become-a-proofreader).\n\n![GitLab translation status](https://about.gitlab.com/images/blogimages/translation-blog/gitlab_translation_status.png){: .shadow.medium.center}\n\nEven if a language is fully translated today, new phrases are added all the time, so we welcome new contributors across all languages. If you have any questions as you get started on [translate.gitlab.com](https://translate.gitlab.com/), you can post questions on the [Crowdin discussions forum](https://translate.gitlab.com/project/gitlab-ee/discussions), and you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[268,9,787,1285],{"slug":4391,"featured":6,"template":698},"translating-gitlab","content:en-us:blog:translating-gitlab.yml","Translating Gitlab","en-us/blog/translating-gitlab.yml","en-us/blog/translating-gitlab",{"_path":4397,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4398,"content":4404,"config":4409,"_id":4411,"_type":13,"title":4412,"_source":15,"_file":4413,"_stem":4414,"_extension":18},"/en-us/blog/ubs-gitlab-devops-platform",{"title":4399,"description":4400,"ogTitle":4399,"ogDescription":4400,"noIndex":6,"ogImage":4401,"ogUrl":4402,"ogSiteName":685,"ogType":686,"canonicalUrls":4402,"schema":4403},"How UBS created their own DevOps platform using GitLab","How GitLab helped power more than a million builds in six months on UBS DevCloud.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665839/Blog/Hero%20Images/devops.png","https://about.gitlab.com/blog/ubs-gitlab-devops-platform","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How UBS created their own DevOps platform using GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n \"datePublished\": \"2021-08-04\",\n }",{"title":4399,"description":4400,"authors":4405,"heroImage":4401,"date":4406,"body":4407,"category":1053,"tags":4408},[1325],"2021-08-04","\n\nUBS, the largest truly global wealth manager, uses GitLab to power DevCloud, a single [DevOps platform](/solutions/devops-platform/) that allows for a cloud-based, service-oriented, software development lifecycle.\n\n\"GitLab is a fundamental part of DevCloud,\" said [Rick Carey](https://www.bloomberg.com/profile/person/20946258), Group Chief Technology Officer at UBS. \"We wouldn't be able to have that seamless experience without GitLab. It allowed us to pull ahead of many of our competitors, and break down the barriers between coding, testing, and deployment.\"\n\nDuring GitLab Virtual Commit 2021, Rick and [Eric Johnson](/company/team/#edjdev), Chief Technology Officer at GitLab, talked about how building DevCloud on GitLab's DevOps Platform allowed UBS to increase their development velocity, lower their infrastructure costs, and increase collaboration between engineers and non-engineering teams worldwide.\n\n## How engineers used DevCloud to collaborate during UBS Hackathon\n\nThe annual [UBS Hackathon](https://www.ubs.com/global/en/our-firm/what-we-do/technology/2020/hackathon-2020.html), which typically brings together engineers from around the world in one room, went virtual in 2020 due to the COVID-19 pandemic. UBS did a soft launch of the DevCloud platform during the 2020 Hackathon to have a truly global development and seamless team experience among the more than 500 participants dispersed worldwide.\n\n\"It was hard to pick a winner, because nearly every program and team built something absolutely incredible in such a short amount of time,\" said Rick. \"They got so much done that even while chatting with each other, they said, 'I can't believe how easy it is to get this done.'\n\nOnce this Hackathon was successful, we knew that we were going to be able to migrate the rest of our engineers to DevCloud.\"\n\n## Open source collaboration benefitted UBS and GitLab\n\n\"I must say it's uncommon in my experience to see such a large organization let alone one in such a compliance-driven industry as finance take on such a large project and deliver it on time,\" Eric said.\n\nRick attributes part of that success to GitLab's commitment to open source collaboration, which allowed UBS to turn to GitLab team members with questions.\n\n\"In an open source model, every time there was a gap, or an issue, or something we just needed your help with, we could reach out to GitLab and say, 'Can we work on this together? Is there a way to improve this?'\", said Rick. \"That's the value, and that's one of the reasons we went with GitLab.\"\n\nIt wasn't a one-way relationship. Eric said that GitLab learned a lot about compliance and risk processes that are unique to the financial sector by collaborating on open source projects with UBS.\n\n\"Collaboration is one of the GitLab's core values – which was key to this project. We set common goals. We're in constant communication, and we're always working together to remove roadblocks. Working with UBS's engineers is a truly agile experience,\" said Eric.\n\nGitLab forums have a lot of contributions from UBS team members, and both UBS and GitLab are members of open source communities such as the Fintech Open Source Foundation (FINOS) and Cloud Native Computing Foundation (CNCF).\n\n## How adopting DevCloud paid off for UBS\n\nOne of the key messages for why adopting a single DevOps platform such as GitLab or DevCloud benefits engineering teams is the productivity pay-off – for engineers and non-engineers alike.\n\nSimilar to GitLab, which enables simple asynchronous collaboration between team members, DevCloud was built with engineers in mind but so everyone can contribute. Rick said that one of the best pieces of feedback he got on DevCloud was from someone on the business side of UBS, who wanted to do some development projects but struggled with other tools.\n\n\"He said, 'Oh, that's DevCloud? I love DevCloud,'\" said Rick.\n\nIn the roughly six months since UBS launched DevCloud, there have been more than 12,000 users and more than one million successful builds.\n\n## What's next?\n\nIn June 2021, [GitLab acquired machine learning company UnReview](/press/releases/2021-06-02-gitlab-acquires-unreview-machine-learning-capabilities.html) which has allowed us to improve our machine learning capabilities as part of our DevOps Platform. Eric said that by practicing applied machine learning, specifically for code review, GitLab should be able to balance review workloads across teams to increase efficiency.\n\nKeeping all the DevOps activities in a single application makes it easier to extract insights throughout the software development lifecycle. By adding machine learning to a DevOps Platform such as GitLab or DevCloud, teams can not only derive data from past activities, but start to predict the future.\n\n \"We were very impressed by UBS's development culture,\" said Eric. \"It is very complimentary to our own, and we look forward to our continued partnership.\"\n\n## More of a video person?\n\nThis conversation was part of GitLab Virtual Commit 2021. Watch the video below to see the full conversation between Eric and Rick.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/Tof-7fDultw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[695,787,1306,9],{"slug":4410,"featured":6,"template":698},"ubs-gitlab-devops-platform","content:en-us:blog:ubs-gitlab-devops-platform.yml","Ubs Gitlab Devops Platform","en-us/blog/ubs-gitlab-devops-platform.yml","en-us/blog/ubs-gitlab-devops-platform",{"_path":4416,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4417,"content":4422,"config":4427,"_id":4429,"_type":13,"title":4430,"_source":15,"_file":4431,"_stem":4432,"_extension":18},"/en-us/blog/updates-from-aws-reinvent",{"title":4418,"description":4419,"ogTitle":4418,"ogDescription":4419,"noIndex":6,"ogImage":708,"ogUrl":4420,"ogSiteName":685,"ogType":686,"canonicalUrls":4420,"schema":4421},"Highlights from AWS re:Invent 2019","DevOps dining, selecting jukebox tunes, learning ‘Dog’Ops from Wag!, supporting Graviton, and more from AWS re:Invent 2019.","https://about.gitlab.com/blog/updates-from-aws-reinvent","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Highlights from AWS re:Invent 2019\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Tina Sturgis\"}],\n \"datePublished\": \"2019-12-13\",\n }",{"title":4418,"description":4419,"authors":4423,"heroImage":708,"date":2944,"body":4425,"category":300,"tags":4426},[4424],"Tina Sturgis","AWS re:Invent is both energizing and exhausting all at the same time. Come\non... admit it, you think so too! But, it is actually one of my favorite\nevents of the year. It is just me and approximately 65,000 of my best\nfriends coming together to hear what AWS is up to and how it will effect\nGitLab and our joint users. \n\n\n\n## AWS announcements and how they relate to GitLab\n\n\n**Transformation.** I am a sucker for a transformation theme and AWS didn’t\ndisappoint this year. Whether we are talking transformation personally or in\nour business, I can’t help but visualize a caterpillar transforming into a\nbeautiful butterfly. \n\n\nAWS internally reflected as well as challenged their customers to think\nabout “How should we reinvent ourselves?” In the [keynote with Andy\nJassy](https://www.youtube.com/watch?v=7-31KgImGgU), Goldman Sachs, and\nVerizon each told their stories about transforming their business with AWS.\nWhile each story was a little different, they all talked about what they\nhave accomplished with AWS. \n\n\nI sat back and reveled in the fact that the ‘untold’ story of [Goldman\nSachs](/customers/goldman-sachs/) is that GitLab’s [DevOps\nplatform](/solutions/devops-platform/) is used exclusively by their dev\nteams across the entire software development lifecycle. They have been able\nto remove toolchain complexity while going from providing a build once every\ntwo weeks to over a thousand per day. Talk about a transformation. Just\nimagine the velocity in their build cycle that they are able to achieve. \n\n\n**Amazon Fargate for Amazon EKS.**: Customers asked and AWS took action by\nlaunching Amazon Fargate for Amazon EKS. This is big news seeing that 84% of\nall Kubernetes installations run on AWS. So if you are looking to manage\nyour containers at the task level, this announcement should have you dancing\nin your seat. Two out of five new container customers choose to start their\ncontainer journey with Amazon Fargate, citing its overall ease of use.\nGitLab already supports Amazon Fargate and Amazon EKS, so it is very natural\nthat we are excited about this new launch. Have a look at our [Trek10\ncustomer case study](/customers/trek10/) to learn more about how it is using\nGitLab and Amazon Fargate today.\n\n\n**AWS Graviton**: AWS announced the next generation of Graviton with native\nrunners for 32 and 64-bit ARM-based processors. GitLab already supports this\nservice and our customers are already contributing.\n\n\n## WAG!’s phased approach to ‘Dog’Ops...errrrr DevOps \n\n\nDave Bullock from Wag! went through the first two phases of the\ntransformation journey with both AWS and GitLab. Some of my favorite\nhighlights from his talk, in his words, were:\n\n\n```\n\n“Automate all the things!”\n\n\n“We wanted Dev to work locally to test and monitor themselves so they take\nownership.”\n\n\n“Everything as code! Code, not clicks!”\n\n\n“Everything is built into the pipeline...if something happens you can\nrollback at each step.”\n\n\n“Change is hard, things break! No one is perfect.”\n\n```\n\n\nWatch the full [Wag! story](https://youtu.be/HfEl9GXZC0s) from AWS\nre:Invent. \n\n\n\n\n## The importance of early security\n\n\n[Brandon Jung](/company/team/#bjung), our VP of alliances and board member\nat the Linux Foundation, sat down with Stu Miniman and John Walls, hosts of\n[theCUBE](https://www.thecube.net), to talk about how [GitLab empowers\nDevOps while making CISOs\nhappy](https://siliconangle.com/2019/12/06/qa-gitlab-empowers-devops-making-cisos-happy-reinvent/).\nBrandon explained how GitLab users are able to include security earlier in\nthe software development process, which saves them money because they're not\niterating in the production phase.\n\n\nWatch [Brandon’s full\ninterview](https://www.youtube.com/watch?v=Auua2qMYFOw).\n\n\n## Do you want to play a game?\n\n\nWe love games here at GitLab and were thrilled to be the featured SCM tool\nused in [AWS GameDay](https://aws.amazon.com/gameday/) at re:Invent this\nyear. AWS GameDay is an interactive team-based learning exercise designed to\ngive players a chance to put their AWS skills to the test in a real-world,\ngamified, risk-free environment. Expect to see us \"play\" a bigger role in\nAWS GameDay in 2020. \n\n\nThis year, the GitLab DevOps Diner-themed booth earned an honorable mention\nfor the [best booth by\nAWS](https://twitter.com/AWSreInvent/status/1202735726153981953). Our\ncorporate events team stayed laser-focused and each and every corner of the\nbooth, including the swag, had the diner theme. My personal fav was the jams\non the jukebox – I think this is a must-have in every one of our booths. We\nare already thinking about how to outdo the diner theme in 2020.\n\n\n![GitLab Diner at\nAWS](https://about.gitlab.com/images/blogimages/gitlabdiner.jpg){:\n.shadow.medium.center}\n\n\nLet’s keep the conversation going...what were your favorite parts at\nre:Invent this year? Comment here or ping me on Twitter @t_sturgis!\n",[268,1285,9,278,1203],{"slug":4428,"featured":6,"template":698},"updates-from-aws-reinvent","content:en-us:blog:updates-from-aws-reinvent.yml","Updates From Aws Reinvent","en-us/blog/updates-from-aws-reinvent.yml","en-us/blog/updates-from-aws-reinvent",{"_path":4434,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4435,"content":4441,"config":4447,"_id":4449,"_type":13,"title":4450,"_source":15,"_file":4451,"_stem":4452,"_extension":18},"/en-us/blog/upgrade-to-rails5",{"title":4436,"description":4437,"ogTitle":4436,"ogDescription":4437,"noIndex":6,"ogImage":4438,"ogUrl":4439,"ogSiteName":685,"ogType":686,"canonicalUrls":4439,"schema":4440},"The road to Rails 5","Senior Backend Engineer Jan Provaznik shares some of the challenges we encountered when upgrading GitLab to Rails 5 – and how we overcame them.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683399/Blog/Hero%20Images/road-to-rails-5.jpg","https://about.gitlab.com/blog/upgrade-to-rails5","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The road to Rails 5\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jan Provaznik\"}],\n \"datePublished\": \"2019-05-28\",\n }",{"title":4436,"description":4437,"authors":4442,"heroImage":4438,"date":4444,"body":4445,"category":1053,"tags":4446},[4443],"Jan Provaznik","2019-05-28","With [Rails 6 coming\nsoon](https://weblog.rubyonrails.org/2018/12/20/timeline-for-the-release-of-Rails-6-0/)\nit's a good time to look back at the journey we took when upgrading GitLab\nto Rails 5, which was not so long ago.\n\n\n[Our issue for upgrading to Rails\n5](https://gitlab.com/gitlab-org/gitlab-ce/issues/14286) was around for\nquite a while, largely because it was difficult to switch such a big project\nas GitLab instantly to the next major version. Here is a brief story about\nhow we solved this upgrade challenge.\n\n\n## Our solution? Cut it into pieces\n\n\nThe upgrade to Rails 5 was first prepared as a one big merge request. The\nnice thing about this approach is that when the merge request is ready, you\ncan just merge the single merge request without dealing with any backward\ncompatibility. The [first\nattempt](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5555) had\nlower priority and it was later replaced with a [second\nattempt](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12841). But\nfor the GitLab codebase this merge request became pretty big: 151 commits,\nover 120 pushes, and more than 1000 changed files. Then it was almost\nimpossible to get such merge request ready to be merged and keep it up to\ndate without hitting problems with conflicts.\n\n\nRather than trying to get the upgrade done in a single merge request, a\ncouple of changes made it possible to run the application either on Rails 4\nor 5 depending on an environment variable. The application was still running\non Rails 4 by default, but we were able to run it on Rails 5 either locally\nor in CI just by setting `RAILS5` and `BUNDLE_GEMFILE` environment\nvariables. This allowed us to split the upgrade into many small issues.\nTypically each issue addressed one specific type of error in CI, so with\neach fix there were fewer failing tests in CI. Another major benefit was\nthat then it was significantly easier to split the work between more people\nand to get an overview of who was working on what issue.\n\n\nA Rails version-specific Gemfile was loaded depending on the `RAILS5` and\n`BUNDLE_GEMFILE` environment variable. Here is an example of [enabling Rails\n5 in rspec](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18140):\n\n\n```ruby\n\ngemfile = %w[1 true].include?(ENV[\"RAILS5\"]) ? \"Gemfile.rails5\" : \"Gemfile\"\n\nENV['BUNDLE_GEMFILE'] ||= File.expand_path(\"../#{gemfile}\", __dir__)\n\n```\n\n\nThe content of\n[Gemfile.rails5](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17761):\n\n\n```ruby\n\n# BUNDLE_GEMFILE=Gemfile.rails5 bundle install\n\n\nENV[\"RAILS5\"] = \"true\"\n\n\ngemfile = File.expand_path(\"../Gemfile\", __FILE__)\n\n\neval(File.read(gemfile), nil, gemfile)\n\n```\n\n\nAnd the Gemfile:\n\n\n```ruby\n\ndef rails5?\n %w[1 true].include?(ENV[\"RAILS5\"])\nend\n\n\n\ngem_versions = {}\n\ngem_versions['activerecord_sane_schema_dumper'] = rails5? ? '1.0' :\n'0.2'\n\ngem_versions['default_value_for'] = rails5? ? '~> 3.0.5' : '~>\n3.0.0'\n\ngem_versions['html-pipeline'] = rails5? ? '~> 2.6.0' : '~>\n1.11.0'\n\ngem_versions['rails'] = rails5? ? '5.0.6' :\n'4.2.10'\n\ngem_versions['rails-i18n'] = rails5? ? '~> 5.1' : '~>\n4.0.9'\n\n```\n\n\nThere were situations when a fix for Rails 5 was not compatible with Rails 4\nand two different versions of code were needed, typically an Active Record\nquery. For this purpose we used a simple helper method `Gitlab.rails5?` to\ncheck which version was being used and added code for each version. It was\npretty easy to remove all Rails 4-compatible code in the cleanup phase when\nwe upgraded to Rails 5 just by searching for `Gitlab.rails5?` in our\ncodebase.\n\n\nAn example of the check used in `lib/gitlab/database.rb`:\n\n\n```ruby\n\ndef self.cached_table_exists?(table_name)\n if Gitlab.rails5?\n connection.schema_cache.data_source_exists?(table_name)\n else\n connection.schema_cache.table_exists?(table_name)\n end\nend\n\n```\n\n\n## Upgrade process\n\n\nTo be able to address upgrade issues in small, separate pieces, we did the\nfollowing steps during the upgrade process:\n\n\n* [Allowed GitLab to run both with Rails 4 and\n5](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17761), but keep\nRails 4 default.\n\n* We also [added support both for Rails 4 and 5 into\nGDK](https://gitlab.com/gitlab-org/gitlab-development-kit/merge_requests/497).\n\n* Fixed all issues until it fully worked with Rails 5 and CI was green.\n\n* Did manual testing to make sure everything will work after the upgrade.\n\n* [Switched to Rails 5 by\ndefault](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21492), (but\nkept Rails 4 code).\n\n* Still enforced compatibility with Rails 4 (by running CI both with Rails 4\nand 5) in case we had to switch back because of a blocker issue.\n\n* Dropped Rails 4 compatibility when we were sure everything worked.\nReleases are done monthly, so we removed Rails 4 code after the next\nrelease.\n\n\n## Major challenges\n\n\n### Active Record changes\n\n\nIn some places we use `Arel` directly and there were various incompatible\nchanges (e.g. [`IN` statement\nissue](https://github.com/rails/arel/issues/531) solved by [this\nfix](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19796)) which\ncaused some of our SQL queries to stop working on Rails 5. (Almost) all of\nthem were discovered during the preparation phase thanks to good test\ncoverage. A list of [database-related changes is\nhere](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?label_name%5B%5D=rails5&label_name%5B%5D=database&scope=all&state=all).\n\n\n### Monkey patches\n\n\nWe keep various monkey patches (either not-merged-yet upstream fixes or\ncustom extensions), many of which required refactoring with the major\nupgrade. The positive is that we were able to get rid of some of them.\n\n\n### Keeping Rails 5 CI green\n\n\nThere was quite a long period between the moment we had all Rails 5 issues\nfixed and the moment we really switched the master branch to Rails 5.\n\nDuring this period we used a scheduled pipeline which ran daily on CE and EE\nmaster branches on Rails 5, so we knew quickly when a new incompatibility\nissue was introduced.\n\nAnother option was running CI jobs both for Rails 4 and 5 for each merge\nrequest and making it mandatory to pass all jobs. The disadvantage of this\noption was it would take twice as much time to run CI.\n\n\nUnfortunately there were many new incompatibility issues introduced during\nthis period. Next time it would be better to run CI for each merge request,\nboth with Rails 4 and 5, although it would require twice as much CI runtime.\n\n\n## Production release\n\n\nOnce we had all known issues in our codebase fixed, we still had additional\nsteps to make sure we didn't hit a critical issue when releasing the next\nversion. [We tracked these steps in this\nissue](https://gitlab.com/gitlab-org/gitlab-ce/issues/48991). We switched\nmaster branches to Rails 5 at the beginning of the development cycle (each\ncycle is one month long). We then ran CI jobs both with Rails 5 (default)\nand 4 (to keep backward compatibility). Timing was important because during\nthe development cycle we discovered a couple of issues and we had enough\ntime to fix them before release. After the release of the next version\n(11.6), when we were sure that we would not have to switch back to Rails 4,\nwe removed Rails 4 both from CI and from the codebase.\n\n\nAlthough it took longer than expected, I think this upgrade was successful\nbecause it didn't cause any production issues. There were a few [major\nissues](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=rails5&label_name[]=P1)\ndiscovered after switching the master branch, but we were able to fix them\nquickly before release.\n\n\nThis upgrade was done with huge help from our community – especially\n[@blackst0ne](https://gitlab.com/blackst0ne) and\n[@jlemaes](https://gitlab.com/jlemaes). Thank you!\n\n\n## Next steps\n\n\n* The upgrade to Rails 5.1 is [happening\nnow](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24852).\n\n* The upgrade to Rails 5.2 is [still in\nprogress](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8877) –\nunfortunately there are many incompatibilities.\n\n\nBecause upgrades to 5.1 and 5.2 should be relatively small, we aim to do\neach upgrade in a single merge request. The upgrade to Rails 6 is expected\nto be bigger, so hopefully the same approach we used for Rails 5 upgrade\nwill be useful in this case too.\n\n\nPhoto by Cody Board on [Unsplash](https://unsplash.com/photos/2hu-SSktidc)\n\n{: .note}\n",[9,2325,787,268],{"slug":4448,"featured":6,"template":698},"upgrade-to-rails5","content:en-us:blog:upgrade-to-rails5.yml","Upgrade To Rails5","en-us/blog/upgrade-to-rails5.yml","en-us/blog/upgrade-to-rails5",{"_path":4454,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4455,"content":4461,"config":4466,"_id":4468,"_type":13,"title":4469,"_source":15,"_file":4470,"_stem":4471,"_extension":18},"/en-us/blog/use-cases-for-epics",{"title":4456,"description":4457,"ogTitle":4456,"ogDescription":4457,"noIndex":6,"ogImage":4458,"ogUrl":4459,"ogSiteName":685,"ogType":686,"canonicalUrls":4459,"schema":4460},"How the GitLab UX team uses epics","UX Manager Sarrah Vesselov shares how the UX team is using epics to manage their workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680187/Blog/Hero%20Images/how-ux-team-uses-epics.jpg","https://about.gitlab.com/blog/use-cases-for-epics","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How the GitLab UX team uses epics\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sarrah Vesselov\"}],\n \"datePublished\": \"2018-03-19\",\n }",{"title":4456,"description":4457,"authors":4462,"heroImage":4458,"date":4463,"body":4464,"category":1053,"tags":4465},[2303],"2018-03-19","\n\nOne of the challenges for UX here at GitLab is how to work iteratively, making the smallest changes possible, while maintaining a holistic view of the application. As the manager for the UX department, I was curious to see how we could use [epics](https://docs.gitlab.com/ee/user/group/epics/) to better plan and track UX efforts over time.\n\n\u003C!-- more -->\n\n## What are epics?\n\nThe term 'epic' is most commonly associated with Agile methodology. In Agile, an epic is a collection of user stories that describe a larger user flow, typically consisting of multiple features. So, what does ‘epic’ mean at GitLab? Here, epics contain a title and description, much like an issue, and allow you to attach multiple child issues to indicate hierarchy. In short, an epic is a feature that allows you to manage a portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones.\n\nWhat this meant for the UX team was that we finally had an efficient way to plan, track, and execute a group of thematically related issues. Take the merge request page for example. We have over 100 issues related to UX improvements for this feature alone! Each issue, taken on its own, represents just one piece of a much bigger picture. Epics would allow us to define the goal we have for the entire page and organize issues specific to that effort.\n\n## Getting started with epics\n\nTo get started with epics, we put together a UX strategy template. This template would be filled out and added to the epic description. The template defined the following:\n\n- **Challenges:** What user problem are we trying to solve? What business problem are we trying to solve? Are there obstacles standing in the way?\n\n- **Vision:** What do we want to achieve?\n\n- **Focus Areas:** What will we focus our attention on to have the most impact?\n\n- **Mission:** How will we achieve this goal?\n\n- **Activity/Deliverables:** What will we do and what will we deliver?\n\n- **Measure:** How will we measure success qualitatively and quantitatively?\n\nThe template also includes links to any relevant [personas](/blog/discovering-gitlabs-personas/) and [research](/blog/conducting-remote-ux-research/) we should consider when working toward the overall goal.\n\n## Creating our first epic\n\nWith the template ready to go, we chose the merge request page as our first area of focus. We started by reviewing the existing UX research for this page. It was essential to use data to understand the pain points and opportunities. We also examined the entire backlog of issues related to this page, matching existing issues to the research findings. With the significant pain points identified, we were able to fill out the template and create our very first epic.\n\n![Merge Request Epic](https://about.gitlab.com/images/blogimages/epics-ux.png){: .shadow}\n\nWith a holistic view of what we wanted to achieve, we could go back and find issues in the backlog that were critical to the vision. These issues were added to the epic and ordered according to priority. As we discover new information, we can reorder these issues to match the change in priority. As the scope expands, we can aggressively break things out into new epics for development at a later time or parallel to the existing epic. In the future, [sub-epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4282) will make this process even more fluid.\n\n![Merge Request Epic Issues](https://about.gitlab.com/images/blogimages/epic-ux-issues.png){: .shadow}\n\n*\u003Csmall>Issues are listed under the epic description. They can be easily reordered by dragging and dropping them into place.\u003C/small>*\n\nWe also set a time frame for this overall effort to be achieved. Having a set timeframe allows us to resource plan with the product team and make adjustments accordingly.\n\n## Looking ahead\n\nSo far, epics have proven to be well suited for planning long-term UX efforts. It has allowed us to maintain a holistic view of product area while still working iteratively. Epics also give other departments better visibility into what UX considers important. We are already looking beyond the merge request page and using epics to plan other efforts spanning multiple milestones. Epics are still relatively new, and there are many additions yet to come. In future releases, they will support [labeling](https://gitlab.com/gitlab-org/gitlab-ee/issues/4032), [discussions](https://gitlab.com/gitlab-org/gitlab-ee/issues/3889), [project-level epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4019), and integration with [issues](https://gitlab.com/gitlab-org/gitlab-ee/issues/4684) and [roadmaps](https://gitlab.com/gitlab-org/gitlab-ee/issues/3559).\n\n![Roadmap feature for epics](https://about.gitlab.com/images/blogimages/roadmaps.png){: .shadow}\n\nThe [Roadmap feature](https://gitlab.com/gitlab-org/gitlab-ee/issues/3559), pictured above, is set to be released in 10.5. Roadmaps offer a graphical, high level overview of an epic, or multiple epic's, goals and deliverables presented on a timeline. The blue roadmap bar and the epic list item are clickable and will navigate to that epic's detail page.\n\n## Resources\n- [Portfolio Management Roadmap](/direction/#portfolio-management-and-issue-management )\n\nPhoto by [Dmitri Popov](https://unsplash.com/) on [Unsplash](https://unsplash.com/search/photos/scale?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[891,912,9,1099],{"slug":4467,"featured":6,"template":698},"use-cases-for-epics","content:en-us:blog:use-cases-for-epics.yml","Use Cases For Epics","en-us/blog/use-cases-for-epics.yml","en-us/blog/use-cases-for-epics",{"_path":4473,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4474,"content":4480,"config":4486,"_id":4488,"_type":13,"title":4489,"_source":15,"_file":4490,"_stem":4491,"_extension":18},"/en-us/blog/verify-week-hackathon",{"title":4475,"description":4476,"ogTitle":4475,"ogDescription":4476,"noIndex":6,"ogImage":4477,"ogUrl":4478,"ogSiteName":685,"ogType":686,"canonicalUrls":4478,"schema":4479},"What we learned during an internal Hackathon Week","The Verify team spent a week on Hackathon projects building new features, Proof of Concepts and cleaning up “dead code”","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682399/Blog/Hero%20Images/marvin-meyer-SYTO3xs06fU-unsplash.jpg","https://about.gitlab.com/blog/verify-week-hackathon","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What we learned during an internal Hackathon Week\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"James Heimbuck\"}],\n \"datePublished\": \"2022-07-28\",\n }",{"title":4475,"description":4476,"authors":4481,"heroImage":4477,"date":4483,"body":4484,"category":300,"tags":4485},[4482],"James Heimbuck","2022-07-28","\n\nTo inspire the Verify Stage product and engineering teams to solve new problems, we conducted a \"Hackathon Week\" in July 2022. \n\nPrior to the Hackathon, the team spent time brainstorming ideas to solve and enhancements to make. We then collaborated to make those ideas better. For projects with a critical mass of people who wanted to work on them, an engineer took the lead in organizing the work, making sure there was a design (where needed) and doing other unblocking to deliver an outcome. The team also focused on deleting some dead code in the code base to make future development easier. We even offered a prize for the most code/files deleted. Several themes emerged as the team brainstormed, which resulted in some greatly improved Proof of Concepts (POCs) or new features shipped in the product.\n\n## Searching job logs is hard\n\nAt GitLab we use the product to build new features, and we have a very rich build pipeline but not a perfect one. Because of this the team knows how hard it can be to parse through the job logs shown on the job detail page.\n\nOne engineer delivered a POC to make scrolling through failures easier, delivering an MVC for an [open issue](https://gitlab.com/gitlab-org/gitlab/-/issues/343658). Another team worked on adding a simple search and highlight to the job logs page. After seeing the demo we quickly decided that [this](https://gitlab.com/gitlab-org/gitlab/-/issues/367574) was something we could ship and it will roll out during the 15.3 milestone.\n\n## Could this job be faster?\n\nSpeedy and reliable pipelines is something we think a lot about across the stage so it was no wonder we saw several groups thinking about ways to get more job performance data to users.\n\nOn demo day, a POC re-envisioning how the job performance page shows job executions in other pipelines was shown. Before delivering the feature to customers, the team wants to make some improvements and opened [gitlab#367322](https://gitlab.com/gitlab-org/gitlab/-/issues/367322) for a future milestone.\n\nAnother group delivered a POC that took a similar approach on the pipeline editor, which delivers the insights in a context where users can act on data to improve its performance. \n\nWe know failed tests are often the culprit of failed pipelines but debugging the failures can be slowed down simply by the process of finding them. A POC to create a one-click copy of the path of all the failing tests from the Merge Request Test Report widget was developed during our Hackathon Week. This has since been merged and is available on gitlab.com\n\n## Fault Tolerant Runners\n\nThe Runner team recently introduced the GitLab Runner Pod Cleanup as a way to clean up orphaned pods the GitLab Runner Manager has not had a chance to do (like the Runner Manager pod getting evicted). The team delivered a [POC MR](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3512) that lays the foundation for the next iteration toward a Fault Tolerant Runner.\n\n## CI Workflows POC\n\nGitLab has a very flexible way to start a pipeline on any number of events from other pipelines, by schedule and by a commit among other things. Teams may want to run a pipeline on other events, like issue creation, merge request approval, etc. A team headed up by \n[Grzegorz](https://gitlab.com/grzesiek) created an initial concept for GitLab CI workflows. This is a great first step towards the larger goal of creating a full-fledged [GitLab Workflow](https://gitlab.com/groups/gitlab-org/-/epics/8349) solution. Watch the demo:\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/cwfRI9m3rRs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Code cleanup\n\nOne of the highest upvoted items from our brainstorming was code cleanup. The team does a great job while working on new features and enhancements in doing what they can to reduce any technical debt and to keep things lean, but \"cruft\" builds up that needs attention from time to time. Over the course of the week, over 1300 lines of code and 4421 MB of database data were deleted by the team.\n\n## Closing thoughts\n\nThis hackathon was an incredible example of iteration, collaboration, and efficiency as individuals worked to deliver new features to solve problems and streamline the codebase. \n\nThese are some of the highlights of the work completed over the course of the week. We would love to hear your thoughts on the pending issues, proof of concept merge requests, and in new issues about features we should build. You can also contribute code to these projects or many others in the next [GitLab Hackathon](https://about.gitlab.com/community/hackathon/) that runs August 2 through August 9 2022.\n\nCover image by [Marvin Meyer](https://unsplash.com/@marvelous) on [Unsplash](https://unsplash.com/photos/SYTO3xs06fU-unspalsh.jpg)\n{: .note}\n\n\n",[1306,9,1388],{"slug":4487,"featured":6,"template":698},"verify-week-hackathon","content:en-us:blog:verify-week-hackathon.yml","Verify Week Hackathon","en-us/blog/verify-week-hackathon.yml","en-us/blog/verify-week-hackathon",{"_path":4493,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4494,"content":4500,"config":4505,"_id":4507,"_type":13,"title":4508,"_source":15,"_file":4509,"_stem":4510,"_extension":18},"/en-us/blog/visualizing-incident-management-metrics",{"title":4495,"description":4496,"ogTitle":4495,"ogDescription":4496,"noIndex":6,"ogImage":4497,"ogUrl":4498,"ogSiteName":685,"ogType":686,"canonicalUrls":4498,"schema":4499},"Visual guide to incident metrics","Learn what incident metrics are and how they contribute to better performance and response times.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667913/Blog/Hero%20Images/clocks.jpg","https://about.gitlab.com/blog/visualizing-incident-management-metrics","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Visual guide to incident metrics\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n \"datePublished\": \"2023-01-09\",\n }",{"title":4495,"description":4496,"authors":4501,"heroImage":4497,"date":4502,"body":4503,"category":757,"tags":4504},[2418],"2023-01-09","\n\nIncident metrics are a set of standard, quantifiable measurements used to track the incident response process. Accurately tracking these metrics will help DevSecOps teams understand how they are performing and whether responses to unplanned outages are getting better or worse. Decreasing the time to detect, respond, mitigate, and recover from an incident decreases the impact of an incident on customers as well as the cost of the incident to the business overall. \n\nHow are these metrics captured and recorded? Let's backtrack a bit and define five key timestamps to capture during an incident that will enable teams to measure the relevant incident metrics.\n\n1. First product impact (`Start time`): When a service starts degrading or metrics begin deviating from the norm.\n2. Time to detection (`Impact detected`): When the operator becomes aware of the problem.\n3. Time to respond (`Response initiated`): When the operator starts to address the problem. \n4. Time to mitigate (`Impact mitigated`): When there is no longer severe product impact. The system may still be degraded in some way.\n5. Time to recovery (`End time`): When the system has fully recovered and is operating normally. Note: Sometimes recovery and mitigation are the same, but sometimes they are different. Time to recovery is the same as the DORA metric [time to restore service](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html#time-to-restore-service): time an incident was open in a production environment over the given time period.\n\nIt is important to create a single source of truth for what actually happened during a given incident, and GitLab enables users to do that easily by creating incident timelines. Throughout an incident, there are many conversations, meetings, and investigations to determine what's going on and how to recover. However, only some key pieces of what happened during the incident need to be identified to build an incident timeline, and these timeline items are the building blocks of the important incident metrics. \n\nLet's walk through an example of how that could work:\n\n- When an alert is triggered, Sally, the engineer on call, gets paged.\n- Sally is in the middle of breakfast and doesn't hear the first page.\n- When she gets paged again, she picks up her phone (`impact detected`) and starts to investigate.\n- After taking a closer look, it looks like something isn't working as expected and she declares an incident.\n- After reviewing the metrics that triggered the alert, she notices this has been happening for 8 minutes.\n- Sally determines that the true `start time` of the incident was 8 minutes before the first alert.\n\nSo far, two important timeline events have happened. By applying the `start time` and `impact detected` tags to your incident timeline, you can measure the time to detection, which is the difference between these two timestamps.\n\n![time_to_detection](https://about.gitlab.com/images/blogimages/incident-mgmt/time_to_detection.png)\n\nAfter Sally has had a chance to start investigating the alert, she reaches out to team members that can help, sets up a video conference call, and starts to determine the root cause. The `response is initiated`. \n\nThe response team is seeing multiple reports from customers and internal users that traffic is absent. After taking a closer look at the alert and recent changes, the team is able to determine that this incident originates from a recent deployment. Sally coordinates with the Release Manager to roll back the deployment. Once the rollback is complete, the incident has been mitigated. So far we've captured two key metrics, time to detect and time to mitigate.\n\n![time_to_mitigation](https://about.gitlab.com/images/blogimages/incident-mgmt/time_to_mitigation.png)\n\nOnce the changes from the bad deployment have been reverted, Sally continues to monitor for any additional alerts, irregular logs, or reports that traffic is absent. Things continue to look like they are working as expected, marking the `end time` of the incident and declaring the incident _resolved_. (In this example, the time to mitigate is the same as the time to recover since the rolled back deployment restored services.) Sally starts working on creating/determining corrective actions and investigating the total impact that users experienced during the incident. Once these closing tasks are complete, the incident is closed.\n\n![time_to_recovery](https://about.gitlab.com/images/blogimages/incident-mgmt/time_to_recovery.png)\n\nAt GitLab we've built [incident timelines](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html#view-the-timeline) on the [incident](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) issue type as a first step towards tracking important incident metrics. We are currently building an MVC for [incident tags](https://gitlab.com/groups/gitlab-org/-/epics/8741) so incident response teams can capture relevant incident timestamps during an incident and add them to the incident timeline. To learn more about how incident timelines can help your team during an incident, check out [How to leverage GitLab incident timelines](https://about.gitlab.com/blog/gitlab-incident-timelines/).\n\nSpecial thanks to GitLab's talented Product Designer [Amelia Bauerly](https://gitlab.com/ameliabauerly) who illustrated the examples in this blog post.\n",[1388,9,829],{"slug":4506,"featured":6,"template":698},"visualizing-incident-management-metrics","content:en-us:blog:visualizing-incident-management-metrics.yml","Visualizing Incident Management Metrics","en-us/blog/visualizing-incident-management-metrics.yml","en-us/blog/visualizing-incident-management-metrics",{"_path":4512,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4513,"content":4519,"config":4524,"_id":4526,"_type":13,"title":4527,"_source":15,"_file":4528,"_stem":4529,"_extension":18},"/en-us/blog/wag-labs-blog-post",{"title":4514,"description":4515,"ogTitle":4514,"ogDescription":4515,"noIndex":6,"ogImage":4516,"ogUrl":4517,"ogSiteName":685,"ogType":686,"canonicalUrls":4517,"schema":4518},"How Wag! cut their release process from 40 minutes to just 6","The popular dog-walking app is rolling out new features faster and with more confidence as they adopt GitLab for more of their DevOps workflows.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678923/Blog/Hero%20Images/dog-walking.jpg","https://about.gitlab.com/blog/wag-labs-blog-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How Wag! cut their release process from 40 minutes to just 6\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n \"datePublished\": \"2019-01-16\",\n }",{"title":4514,"description":4515,"authors":4520,"heroImage":4516,"date":4521,"body":4522,"category":784,"tags":4523},[2125],"2019-01-16","\nDo you own a dog and work outside of the home? If you do, or even just know someone who does, you know that finding a trustworthy caretaker is of the utmost importance. With dog walkers in cities and towns across the U.S., the folks at [Wag!](https://wagwalking.com/about) have proven to be a source of reliable caretakers for countless fur parents. In three years, the company has powered more than one billion walks via its app for on-demand dog walking, sitting, and boarding, that boasts of millions of users.\n\nWag! recently signed on with GitLab to make the most of their engineering hours and bring their customers new features and updates at a faster clip.\n\n### From version control, to CI, to the full pipeline\n\nHaving previously used GitLab as their main source of truth for repositories, Wag! initially planned to return to the app solely for [continuous integration (CI)](/solutions/continuous-integration/). But after giving it a whirl, they quickly expanded their strategy to include the use of other features.\n\n\"We started our GitLab project about seven or eight months ago,\" explains [Dave Bullock](https://www.linkedin.com/in/eecue), director of engineering at Wag! \"The original idea was to just use it as our CI platform. But as we built that out, we started using it for more and more tasks, and ended up using it for our full [CI/CD pipeline](/topics/ci-cd/). That includes both our application, so the CI/CD that powers the API, along with our infrastructure. We use GitLab with Terraform to test, review, save, and deploy all of our infrastructure as well as the application on two separate pipelines. Every team uses it in their application, whether it's the Android application, the web application, the API, or our infrastructure; it's all being tested, built, and deployed through GitLab.\"\n\n### Streamlining to a single application\n\nPart of GitLab's appeal stemmed from the [ability to do everything in one place](/topics/single-application/). Wag! was searching for an [integrated solution](/solutions/continuous-integration/) that would streamline their development process, and they found it in GitLab.\n\n\"We were previously using a combination of Travis and other random technologies, and we just wanted something with a little bit better interface, a little more control, and something that we owned as far as the hosting and the management,\" says Bullock. \"We really wanted to move towards a single, full-service application.\"\n\n>\"We just wanted something with a better interface, a little more control, and something that we owned as far as the hosting and the management. We really wanted to move towards a single, full-service application.\"\n\nThe impact of that choice is also being felt on the infrastructure side. Wag!'s infrastructure engineers no longer have to manually stage and test their work. They are now following the same basic workflow that is used for their app, while integrating Terraform to manage their infrastructure.\n\n\"Basically, one of our DevOps team members will make a change, cut a pull request, and it'll be reviewed by the team. If it looks good, we'll say, 'Okay, cool. Merge it into master,'\" Bullock explains. \"If it's one of the modules, we'll tag that module, update the reference to it, and then the CI pipeline will kick off. It'll test the syntax, look for any security issues, and alert a Slack channel if there are any. It'll then stage a full version of the environment and test it. So, it stages all the pieces: the database, cache, and everything else, and tests it all to make sure that it works, just like we would be testing our production website.\n\n\"If that passes, then it allows you to see what your changes are going to do before you apply them,\" he continues. \"We call it Terraform plan. So, it runs Terraform plan on each piece of our infrastructure, and it'll tell us something like, 'Hey, we see 34 changes and 2 destructions and 1 creation in this environment. Click here to review.' Then the group will review it and if it looks good, we'll apply it in production. Having that as a full pipeline is really great.\"\n\n>“Now it's so easy to deploy something and roll it back if there's an issue. It's taken the stress and the fear out of deploying into production.” – Dave Bullock, Director of Engineering\n\n### Easy learning curve\n\nSome of the Wag! engineers had working experience with GitLab, while others had not. Nonetheless, Bullock found the onboarding of his teams to be a fairly easy process due to the intuitive nature of the interface.\n\n\"I think once you kind of understand how CI works, it's basically about following things step by step,\" he says. \"Pipelines were a new concept to a lot of the team, but once you see it happening visually, it's really easy to understand what's going on, expand and add to it. It's a really useful interface. Seeing all those green dots or red dots makes it really clear what's going on.\"\n\n### Built-in security, shaving down test times and faster releases\n\nAs part of their ramp up in GitLab, the dog-walking service recently furled [automated security scanning and license management](/solutions/security-compliance/) into their workflow, with Bullock noting how \"great\" it is to have those features baked into the pipeline so that immediate action can be taken when needed.\n\nWag! currently issues three releases a day, with plans to bump that number up to eight or more. Since adopting GitLab, they have seen a massive improvement in the amount of time spent on the release process. **What previously took 40 minutes to an hour to accomplish, now takes just six minutes.**\n\n\"Traditionally, the release process was slow, fragile, and limited to only a few key release engineers who had access to 10 different systems to monitor, make changes, and log into to make updates and pull in the latest code. It was not optimal. Now it's literally a single pane of glass. A lot of it just happens automatically when you merge `develop` into `master` and tag it.\"\n\nThe release process time should improve even more once Wag! engineers switch from manually pushing parts of the release through to automating the process.\n\n\"Right now, we're still clicking through the interface and saying, 'Okay, do this, now let's monitor,'\" says Bullock. \"But I think as we become more comfortable with it, we'll go to fully automated deployments. Literally, just let it go and deploy. If we see an uptick in errors, we'll let it roll back on its own. But as it is now, it's so easy to deploy something and roll it back ourselves if there's an issue. It's taken the stress and the fear out of deploying into production.\"\n\n### Adopting DevOps\n\nWag!'s engineering team has big plans for 2019. They are currently in the process of moving their repositories from GitHub to GitLab and are planning to switch from Amazon ECS to [Kubernetes](/solutions/kubernetes/). This is all part of their roadmap to implementing DevOps.\n\n\"I think we're going to start working on the project in Q1 and it will be really awesome to have all the bells and functionality,\" Bullock says. \"We're excited about Auto DevOps and a lot of new things GitLab has coming down the pipeline. We're going to push pretty hard on that this year.\n\n\"I'm a big fan of DevOps in general, so I think the closer that you can bring the development engineers to the ops side, the better things work,\" he adds. \"I would love for every software engineer or backend engineer to take ownership of the environment that their code runs in, or at least be able to experiment with it and kind of instantly just spin up a full working environment that is the same as our production environment, which we do now, but not with Kubernetes. I think removing that friction is great.\"\n\n### Growing with GitLab\n\nGitLab's releases are a treat the folks at Wag! look forward to checking out each month. The rollout of new features, which are partly determined by user feedback, tend to correlate with the engineering needs of the growing dog-walking and boarding service.\n\n\"I think it's exciting that as we're growing and adding interesting pieces to our infrastructure and application, we're seeing GitLab grow with your monthly release cycles,\" says Bullock. \"Every month there's some new stuff that we're like, 'Oh cool, we could use that, that's perfect.' It's nice to have GitLab as a partner that's growing with us, and it's exciting to see the parallels of new features that you're launching and how it's solving our problems and optimizing things. There's all kinds of cool stuff, and every time we start using a new piece of GitLab, I feel like, 'Okay, that's great, we're really getting our money’s worth.'\"\n\nPhoto by [Andrii Podilnyk](https://unsplash.com/photos/dWSl8REfpoQ?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/dog-walk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1141,1306,9,695,807,1055,1263,912],{"slug":4525,"featured":6,"template":698},"wag-labs-blog-post","content:en-us:blog:wag-labs-blog-post.yml","Wag Labs Blog Post","en-us/blog/wag-labs-blog-post.yml","en-us/blog/wag-labs-blog-post",{"_path":4531,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4532,"content":4537,"config":4542,"_id":4544,"_type":13,"title":4545,"_source":15,"_file":4546,"_stem":4547,"_extension":18},"/en-us/blog/want-a-better-devops-career-learn-the-business",{"title":4533,"description":4534,"ogTitle":4533,"ogDescription":4534,"noIndex":6,"ogImage":4151,"ogUrl":4535,"ogSiteName":685,"ogType":686,"canonicalUrls":4535,"schema":4536},"Want a better DevOps career? Learn the business","A better DevOps career starts with a thorough understanding of business. Here's how to get started.","https://about.gitlab.com/blog/want-a-better-devops-career-learn-the-business","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Want a better DevOps career? Learn the business\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Johanna Ambrosio\"}],\n \"datePublished\": \"2022-03-17\",\n }",{"title":4533,"description":4534,"authors":4538,"heroImage":4151,"date":4539,"body":4540,"category":693,"tags":4541},[2809],"2022-03-17","\nIf it’s time to add to your skill set and improve your DevOps career, a new programming language is always a good choice, but a fundamental understanding of your company’s business might be better. \n\nSpending time to understand the “business side” isn’t just a nice-to-have – it can literally be the difference between remaining an individual contributor or moving into management. It’s so important that in our 2021 Global DevSecOps Survey, respondents ranked “subject matter expertise” as one of the top skills they’d need for their future DevOps careers. \n\nIf you plan to stay a pure technologist and don’t want to manage anyone else or engage in strategy development, you can stop reading now. But if you want to jumpstart your DevOps career, be prepared to put in a couple of hours each week on the following six areas of subject matter expertise. (This is all while [staying current with your tech skills](/blog/the-top-skills-you-need-to-get-your-devops-dream-job/), of course.) Enlist your HR department, your manager, and your mentor(s) for information and start adding to your DevOps career right away. \n\n**Find out all you can about your company.** Yes, you probably got a bit of this when you first started working there, but you could likely use a deeper dive or a refresher. If your company has a knowledge-sharing wiki or library that includes materials about the company’s history and background, make that your go-to. Do a web search. Really explore your company’s website. What’s on the home page? What are the major sections of the site, and what’s being promoted and/or explained to your company’s customers? (And do re-check from time to time; this isn’t a one-and-done process.) \n\nIf your company started out doing X and shifted to Y, when did that happen, and why? (If you’re on Slack or another company-wide communication platform, those can be great places to ask about the past and course corrections.). Soak up any history and as much of the culture as possible. \nLearn about the business you’re in. If your company manufactures widgets, become better-versed in the fundamentals of widget manufacturing. The web is your friend here; you can learn tons for free. Here are some questions to ask:\n\n- Does the company make or create everything it sells, or does it partner with others? \n- How does the manufacturing process work? \n- Where are the plants? \n- Is the company hitting snags these days because of shipping problems or shortages of parts? What’s it doing to address these? \n- What are the major trends affecting the business now, and what’s projected for the next couple of years? \n\n**Search for analyst reports about the industry you’re in.** And even if you can’t get the full reports without paying for them, you can soak up enough from the key takeaways or executive summaries to understand the most important trends. Find out which key publications – online or paper – your management reads to keep up with the industry. Subscribe, or at least read them from time to time.\n\n**Do some competitive research.** You don’t need to create a hugely detailed competitive analysis, of course, but know your firm’s major business rivals –- who they are, what sets them apart from each other, and what differentiates your own company from the rest of the pack. Your marketing department likely already has this document.\n\n**Absorb all you can about your company’s external customers.** Who are they and what products and services do they buy from your firm? If your company’s done focus groups, or surveys, or anything to do with finding out about customer preferences, read through at least the executive summaries to get the big picture. Again, the marketing department will probably have materials you can read.\n\n**Acquire essential business know-how.** Basic [communication skills](/blog/soft-skills-are-the-key-to-your-devops-career-advancement/) – both oral and written – are key to doing pretty much anything on the job, no matter your role or seniority. It’s essential to be both concise and clear, and those are learned aptitudes, not bestowed at birth. As you progress in your career, you’ll need to be able to communicate with internal customers and make presentations to managers and others. \n\n**Seek out leadership, problem-solving, and negotiation skills to improve how you work with others.** Those skills will also help you get to consensus in meetings as quickly as possible. Basic financial management is also key ([Coursera courses, books, or a community college](https://www.coursera.org/learn/finance-for-non-financial-managers)are good options); you’ll want to learn how to shepherd tech projects that come in at or under budget and understanding some level of finance will save you when talking to higher-ups who are all about the bottom line. \nPractice (or learn) time management skills. Yes, you depend on others for pieces of the projects you work on. But you should learn to use your own time most effectively and not be *The Person Who Holds Everything Up* or is hopelessly disorganized anytime someone asks you a question. This will also help you juggle multiple projects without crashing and burning or having to work 12-hour days. Bonus: These techniques can be very helpful in your personal life also.\n\nYour DevOps career goal with learning all of this is to develop the knowledge and tools you need to think broadly about how tech can solve problems, make or save money, create new products and services, and delight customers. \n\nThe more you know about your company, your customers, and the business you’re in, the more you’ll be able to combine that knowledge with your tech smarts. Yours might be the next game-changer idea that results in your promotion or a nice, fat bonus. The sky’s the limit.\n\n\n",[695,737,9],{"slug":4543,"featured":6,"template":698},"want-a-better-devops-career-learn-the-business","content:en-us:blog:want-a-better-devops-career-learn-the-business.yml","Want A Better Devops Career Learn The Business","en-us/blog/want-a-better-devops-career-learn-the-business.yml","en-us/blog/want-a-better-devops-career-learn-the-business",{"_path":4549,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4550,"content":4556,"config":4561,"_id":4563,"_type":13,"title":4564,"_source":15,"_file":4565,"_stem":4566,"_extension":18},"/en-us/blog/ways-to-encourage-collaboration",{"title":4551,"description":4552,"ogTitle":4551,"ogDescription":4552,"noIndex":6,"ogImage":4553,"ogUrl":4554,"ogSiteName":685,"ogType":686,"canonicalUrls":4554,"schema":4555},"3 Ways to foster collaboration","Want to know how we encourage everyone to contribute?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669991/Blog/Hero%20Images/ways-to-encourage-collaboration.jpg","https://about.gitlab.com/blog/ways-to-encourage-collaboration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"3 Ways to foster collaboration\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rebecca Dodd\"}],\n \"datePublished\": \"2017-06-12\",\n }",{"title":4551,"description":4552,"authors":4557,"heroImage":4553,"date":4558,"body":4559,"category":910,"tags":4560},[1158],"2017-06-12","\n\nWe know that [collaboration is critical](/blog/why-collaboration-tools-matter/) for organizations moving towards a DevOps culture. Here's how we encourage collaboration in our workflow at GitLab.\n\n\u003C!-- more -->\n\n## 1. We make suggesting changes less scary\n\nUsing version control for more than just your source code means that everyone feels free to contribute to documentation, configurations, tests and whatever else you're working on. With the benefit of [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/), it's possible to suggest a change or an improvement, or even just query something that isn't entirely clear or could be described better, without just going ahead and making the change immediately. This invites discussion and prevents less experienced team members from feeling nervous to voice their opinions.\n\n>\"It really makes the documentation, similar to the source code, an open source and living document that everyone can contribute to.\" – GitLab Platform Backend Lead, [Douwe Maan](/company/team/#DouweM)\n\n## 2. We open our development platform\n\nBy giving everyone in your organization access to view what other teams are working on, you allow everyone to discover and contribute beyond their own projects. This [inner sourcing](https://en.wikipedia.org/wiki/Inner_source) approach makes it more likely that team members can learn from others or offer suggestions from their own experience that could be applied to a different project, avoiding duplication of work. Douwe explains: \"It's working together to make all of our code better, because if we use a shared library – even if it’s just an internal one – if one person improves it or fixes a bug or increases the functionality of that application, that’s work by one person that will immediately affect all the different teams.\"\n\n## 3. We make code review impersonal\n\nEveryone is encouraged to [review each other's code](https://www.youtube.com/watch?v=XluG9mAQdSo&feature=youtu.be) or ask for input, and the focus of that review is firmly on improving the code. The approach is not to say, \"This is wrong, change it to this,\" which can be really demotivating. We use language like, \"Have you considered this?\" or \"What do you think about this?\"\n\nThis not only makes code review less scary for the person whose merge request is being reviewed, it also makes it less intimidating for other team members to weigh in on more senior team members' work.\n\n>\"Review is really something we all do together. Even the most junior person or just someone who doesn’t really know this part of the application yet, if they see something that doesn’t quite look right to them or something they might have a question about, it’s really useful if you make them feel free to comment on that.\" - Douwe\n\nBy removing the barriers to contribution and making it easy and encouraged to offer input, even where team members have less experience, we've built a culture around collaboration and learning from others' expertise. Fostering collaboration across different teams and functions is just one element of a DevOps culture – to learn more, watch our webcast, \"[Managing the DevOps Culture Shift](https://www.youtube.com/watch?v=py8c6-3zyKM&feature=youtu.be)\" on demand now.\n\n*How does your team encourage everyone to contribute? Tell us in the comments!*\n\n\u003C!-- cover image: https://unsplash.com/search/street-art?photo=PVw_vtpCGaM-->\n",[1162,9,912,695],{"slug":4562,"featured":6,"template":698},"ways-to-encourage-collaboration","content:en-us:blog:ways-to-encourage-collaboration.yml","Ways To Encourage Collaboration","en-us/blog/ways-to-encourage-collaboration.yml","en-us/blog/ways-to-encourage-collaboration",{"_path":4568,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4569,"content":4574,"config":4578,"_id":4580,"_type":13,"title":4581,"_source":15,"_file":4582,"_stem":4583,"_extension":18},"/en-us/blog/what-will-devops-do-for-your-team-in-2022",{"title":4570,"description":4571,"ogTitle":4570,"ogDescription":4571,"noIndex":6,"ogImage":2765,"ogUrl":4572,"ogSiteName":685,"ogType":686,"canonicalUrls":4572,"schema":4573},"What will DevOps do for your team in 2022?","DevOps brings the technical wins but business is winning too, thanks to this modern software development strategy. Here's what our latest DevOps assessment found.","https://about.gitlab.com/blog/what-will-devops-do-for-your-team-in-2022","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"What will DevOps do for your team in 2022?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-01-19\",\n }",{"title":4570,"description":4571,"authors":4575,"heroImage":2765,"date":1407,"body":4576,"category":757,"tags":4577},[846],"\n\nOver the last six months, we’ve asked teams and individual contributors to assess their DevOps platform practices by answering a 20-question quiz. To date, more than 600 people have shared their experiences, providing a clear, and somewhat surprising, snapshot of DevOps as it’s done _today_. There are obvious technical wins, of course, but there are also glimpses of how DevOps and modern software development are driving business change. \n\nHere are some of the key takeaways:\n\n### DevOps is a stand up (and out) choice\t\n\nAlmost 35% of respondents say they’ve been doing DevOps for between one and three years, while 22% report they’ve been at DevOps less than a year. And 16% are in that DevOps sweet spot of between three and five years, while 15% are seasoned DevOps pros with more than five years of experience. \n\nDevOps, of course, enables faster and safer software development and it’s clearly taking teams and entire organizations along for the ride, with much greater levels of collaboration/planning and a commitment to cross-functional processes. Nearly one-quarter of respondents say everyone in their organization considers themselves to be part of the DevOps team. And 17% say security, test, and design have joined dev and ops to create their DevOps teams. \n\nBig changes are happening within those teams as well. Just shy of 30% say the traditional roles of “dev” and “ops” are definitely blurring and 16% report everyone on their team is “cross-functional”. Nearly 15% say dev, sec, ops, and test are all seeing roles change and blend together.\n\nWhen asked how teams handle planning and collaboration, 50% say their processes were either “long-established and effective” or “completely seamless and baked into everything.” Meanwhile, 43% are either just starting a planning/collaboration process or are well underway. \n\nTo put it another way, it appears DevOps drives faster releases *and* better planning and collaboration almost in equal measure. \n\n### A DevOps platform in 2022\n\nJust shy of 36% of quiz takers use an “out of the box” [DevOps platform](/solutions/devops-platform/), while only 7% are considering one. Nearly one-third of respondents say their DevOps platform is a “hybrid” affair of homegrown and purchased solutions, or what GitLab refers to as [DIY DevOps](/blog/welcome-to-the-devops-platform-era/#phase-3",[695,9,268],{"slug":4579,"featured":6,"template":698},"what-will-devops-do-for-your-team-in-2022","content:en-us:blog:what-will-devops-do-for-your-team-in-2022.yml","What Will Devops Do For Your Team In 2022","en-us/blog/what-will-devops-do-for-your-team-in-2022.yml","en-us/blog/what-will-devops-do-for-your-team-in-2022",{"_path":4585,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4586,"content":4592,"config":4598,"_id":4600,"_type":13,"title":4601,"_source":15,"_file":4602,"_stem":4603,"_extension":18},"/en-us/blog/whats-wrong-with-devops",{"title":4587,"description":4588,"ogTitle":4587,"ogDescription":4588,"noIndex":6,"ogImage":4589,"ogUrl":4590,"ogSiteName":685,"ogType":686,"canonicalUrls":4590,"schema":4591},"3 things that are wrong with DevOps today","Why are collaboration woes, shift-left waste, and tooling admin costs still plaguing DevOps?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680211/Blog/Hero%20Images/what-is-wrong-with-devops.jpg","https://about.gitlab.com/blog/whats-wrong-with-devops","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"3 things that are wrong with DevOps today\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Joel Krooswyk\"}],\n \"datePublished\": \"2018-02-20\",\n }",{"title":4587,"description":4588,"authors":4593,"heroImage":4589,"date":4595,"body":4596,"category":693,"tags":4597},[4594],"Joel Krooswyk","2018-02-20","\n\nI’m continually impressed by the benefits achieved by modern ways of working. Lean processes, [Conversational Development](http://conversationaldevelopment.com/), and automation have helped us ship more value, faster. Those achievements have led customers to expect a lot more from their service providers. DevOps has been critical to those gains, but we’ve got more work to do – DevOps still has its problems.\n\n\u003C!-- more -->\n\nI have the privilege of talking with GitLab users every day. We celebrate impressive technical achievements, work through complex problems with CI/CD, or discuss new needs for their organization. The needs and problems seem to align themselves to one of three different areas:\n\n## 1. The wall still stands\n\nDev and Ops are still at war in some environments. In just the past couple of weeks I’ve heard the lack of collaboration between these groups called “the wall,” a “chasm,” and a “joke” by people in both areas! We’re simply not communicating well enough yet. We’re disappointed that after this much investment, there’s still so much room for improvement. Development and Operations continue to use different tools and to follow different rules.\n\n>It's like we're really doing DevSecBizPerfOps\n\nBut it doesn't end there. Now we've got more people in the mix analyzing concerns like security, performance, and business metrics. It's like we're really doing DevSecBizPerfOps or some such thing, and so our flow continues to be interrupted. Silos continue to exist, if not multiply. It also feels like Ops hasn’t gotten enough love, which is why GitLab is working toward better Operations views as part of our [product vision](/blog/devops-strategy/) for 2018.\n\n## 2. Administration costs are still too high\n\nAs we continue to [shift left with build, test, and security](/solutions/security-compliance/), admin costs continue to rise. Developers are often being empowered at the cost of their own productivity. Administration efforts can actually consume [half a developer’s time](https://www.infoworld.com/article/2613762/application-development/software-engineers-spend-lots-of-time-not-building-software.html) each week! Unfortunately, this is a growing form of waste. A core DevOps goal is to reduce administration time, but the admin costs of DevOps tools can be some of the highest in the software development lifecycle ecosystem due to extensive plug-in architectures, support of quickly evolving environments, and asynchronous vendor update woes. We continually increase complexity and add requirements to existing stacks without looking for more modern solutions. Despite all the loss of time, I still hear commonly that there's no way to visualize the flow of the code from requirement to production, especially once code is committed to a repository.\n\nThe good news is that more of us are taking the time to re-examine our ecosystems because they've become bloated with a wide variety of tools from a wide variety of vendors for very specific purposes. I wouldn't consider the current trend to be a tooling consolidation so much as a streamlining or simplification of toolsets. Questions I hear most often tend to focus on optimizing our efficiency and reliability while minimizing administration of laborious plug-in and trigger-driven architectures. We're trending in the right direction.\n\n## 3. We're holding onto the past\n\nWe’ve spent and continue to spend billions on software tools annually. Tooling can be extremely costly! Sometimes we’ve invested so much money in old tooling that we simply can’t let it go. Too often we hold onto tools and processes just because we spent a lot of time and money on them while newer, time-saving products are available for less than the cost of the renewal of the old beasts. And so we hold onto the past as we try to implement new technologies. It’s no surprise that shoving new technology into old tools can generate enormous friction and unique problems.\n\n>It’s no surprise that shoving new technology into old tools can generate enormous friction and unique problems.\n\nPerhaps we bought best-in-breed tools. Those products commonly require excessive coding efforts to integrate and maintain because \"best in breed\" typically means we bought from a number of vendors. Interconnectivity of those tools typically doesn’t come out of the box. And of course, once the API is mentioned as a solution, the admin and maintenance burden increases once again. We spend a lot of money on specific solutions but inevitably end up with holes in our end-to-end process, too often as it relates to security or performance.\n\nBut this way of looking at tooling is beginning to change! I'm hearing more frequently that dramatic price increases, as well as the outsourcing of product maintenance and support, are triggering enterprises to reconsider the past. When we've invested all that time and money into a product, but that product then gets sold to three different parent companies within a decade, our ROI calculations lose their luster. Outsourcings and vendor-level product sales are being viewed as indicators of a potentially declining market. Enterprises are using that as a trigger to seek out updated tools for the years ahead, reducing cost and enabling modern workflows.\n\n## It all impacts delivery efficiency\n\nNo matter whether we’re talking about disappointment in collaboration, shift-left waste, or tooling admin costs, it comes down to this: it all negatively impacts our ability to deliver securely with speed and efficiency. If we truly want to meet and exceed the expectations of our customers, we’ll need to continually hone and improve our DevOps processes and tools to reflect modern ways of working.\n\n[Photo](https://unsplash.com/photos/suaBxarUnyo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) by Caleb George on [Unsplash](https://unsplash.com/search/photos/wall?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[695,912,9],{"slug":4599,"featured":6,"template":698},"whats-wrong-with-devops","content:en-us:blog:whats-wrong-with-devops.yml","Whats Wrong With Devops","en-us/blog/whats-wrong-with-devops.yml","en-us/blog/whats-wrong-with-devops",{"_path":4605,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4606,"content":4612,"config":4619,"_id":4621,"_type":13,"title":4622,"_source":15,"_file":4623,"_stem":4624,"_extension":18},"/en-us/blog/whiteboarding-remote-work-superpower",{"title":4607,"description":4608,"ogTitle":4607,"ogDescription":4608,"noIndex":6,"ogImage":4609,"ogUrl":4610,"ogSiteName":685,"ogType":686,"canonicalUrls":4610,"schema":4611},"Virtual whiteboarding is a remote work super power","Want to master a collective understanding of technical explanations remotely? Learn how to use virtual whiteboards to their maximum capabilities in this tutorial.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682431/Blog/Hero%20Images/kvalifik-5Q07sS54D0Q-unsplash.jpg","https://about.gitlab.com/blog/whiteboarding-remote-work-superpower","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Virtual whiteboarding is a remote work super power\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n \"datePublished\": \"2022-09-01\",\n }",{"title":4607,"description":4608,"authors":4613,"heroImage":4609,"date":4615,"body":4616,"category":1053,"tags":4617},[4614],"Darwin Sanoy","2022-09-01","\n\nAt one point in my career I had a solo business in technology training. During this time, I went through a transition from live, in-person classes to live-delivered virtual classes. One of the things that I dearly missed in virtual delivery was unpacking explanations through whiteboarding. The difference in the speed and completeness of achieving common understanding across the group was very evident by the nature of the questions and discussions that occured immediately afterward. \n\nAt that time, it was difficult to find solutions that enabled me to do this as fluidly as an in-person classroom experience. I persisted and came up with an elaborate solution involving software and hardware – but the results of a fluid whiteboarding experience for both presenter and participants were preserved.\n\n## Explaining and collaborating through drawings\n\n“[The Back of the Napkin: Solving Problems and Selling Ideas with Pictures](https://www.penguinrandomhouse.com/books/300247/the-back-of-the-napkin-expanded-edition-by-dan-roam/)” is a great book on the topic of leveraging drawing in business meetings. The title contains two main themes. “Selling Ideas” is about explaining something you already understand in a highly effective way that creates shared understanding. “Solving Problems” is a very different mode, that of collaborating to create a new visual model that documents the structure of a problem or envisions a new solution. While there are variations on these two themes, these appear to be two most fundamental modes of using drawing in a group context.\n\n## The importance of progressive disclosure in understanding technical explanations \n\nTechnical explanation is challenging on its own - but the situation is made much worse by presenting complex visuals fully formed. Using a whiteboard for the same explanation leverages the progressive disclosure element of storytelling and overlays it on a technical visualization. This has a fundamental effect of enhancing understanding because when a complex visual appears completely formed, the visual cortex hijacks all neurological attention resources (including listening) as it attempts to make sense of the scene. Progressive disclosure allows the minds of listeners to focus on the verbal explanation because only the component being described is visible. As the narrator reveals the next chunk by drawing while explaining the relationship to the last chunk, the audience naturally shifts their full attention.\n\nYou could think of this effect as being the same as what a cartoon strip does to create a sense of progressive disclosure. By simply framing the scenes, our mind automatically focuses on one frame at a time in the intended sequence. The difference with technical explanations is that the final view is extremely informative without frames - it paints a global picture of the sum of the parts.\n\nThe magic of infographics is also the enforcement of progressive disclosure on their topic matter by purposely creating a visual so long that it must be scrolled. Frequently they are also organized around a natural or contrived timeline that the disclosure of the component parts progresses through. They frequently also create frames through visual effects such as lines, shapes, and whitespace.\n\nTechnical visualizations frequently have the characteristic that a big-picture visual is very valuable for complete understanding. Progressive disclosure resolves the contradictory requirements for both a “parts-level understanding” and a “big-picture understanding” of a technical design visualization. This is accomplished by layering up the big picture through many bite-sized explanations - exactly like how the mind's eye creates the world of a story when it is narrated in a sequence of small parts.\n\nWhiteboarding, by nature, can only be done as progressive disclosure and, in doing so, it transforms technical explanation into much more digestible and memorable frames for the audience to consume.\n\n## Maintaining a common understanding of the composite vision\n\nIn order to have the best chance to foster a \"group creative flow,\" everyone who is collaborating needs to maintain a common understanding of the composite vision as rapidly emerging ideas and insights are iteratively worked in. Whiteboarding fulfills this need in a way that is not distracting to the effort because a visualization of the vision is maintained in real-time during collaboration.\n\nFrequently group insights compound on each other as ideas are expanded by building on idea expressed by someone else in the group. Whiteboarding provides a real-time composite visualization which accelerates more new and valuable insights. Drawing frequently enables collaborators to draw things they can't find the words for at the moment. If the conditions are right, there is the potential for a snowball effect of synergistic ideas being incorporated into the composite whole.\n\nThis is where the need for the mechanism for holding the common understanding needs to be fluid and non-distracting.\n\n## Solutions architecture requires both technical explanation and collaboration\n\nIn my job as a Solutions Architect, it turns out that explanation of technical visuals and collaboration in creating technical designs are critical to making helpful contributions to colleagues, customers, and partners.\n\nIt is truly amazing how much more quickly a group of people can get on the same page and innovate when whiteboarding is available.\n\nWhen there are language barriers, it takes on an even higher value as visuals are not dependent on language and can help store the real-time common understanding between different language speakers. Multiple times, I’ve found that speakers who are working through a translator get excited and are emboldened to start talking in English (my native tongue). Generally, the technical terms are recognized in any language and adding them to the diagram fuels more mutual understanding.\n\nWhen I came to GitLab as a Solutions Architect, I, once again, began to experiment with ways to make fluid whiteboarding easy to do in any meeting.\n\n## Better than real whiteboards for in-person meetings\n\nOccasionally, when working hard for one objective, you accidentally achieve some objectives you didn’t even know you should or could have. This is known as serendipity.\n\nThis is what has happened in my pursuit of very fluid virtual whiteboarding. I found virtual whiteboarding handles a lot of logistics and practical considerations for whiteboarding for in-person meetings such as:\n\n* Verifying availability of whiteboards at a meeting venue\n* Simultaneous whiteboards and computer projection visibility (I’ve been in rooms where you had to stop projecting use the whiteboard)\n* You don’t even need a projector if you do an in-person virtual meeting to share your screen\n* Marker management - smell, mess, dried-out markers\n* The inability to preserve every whiteboard that you draw due to needing to erase for the next one\n* The inability to electronically store or share the visuals\n\n## The challenges of hardware and software selection\n\nI wish I could honestly say the process of putting together a fluid virtual whiteboard setup is now easy but I have not found that to be the case.\n\n### Mental flow requires fluid technology\n\nWhether explaining or collaborating the concept of mental flow is very critical. If the need for flow is interrupted by things that should be transparent, it is frustrating for everyone and the audience quickly loses attention. It interrupts the thoughts of both the whiteboarder and the participants.\n\nThink of the times that someone starts whiteboarding and the one and only marker goes dry and they have to hunt for one. Virtual whiteboarding can actually make the problem of interrupting flow much worse. This is because if there are delays in the hardware or software, the shape of what you are drawing gets incorrectly “smoothed”. \n\nA lack of fluidity will generally make your shapes challenging to draw and then you slow down to allow the system to recognize your strokes and, well, it’s not fluid anymore - it’s distracting and effortful. And the rending of shapes aren’t the worst of it, when trying to add text to label diagram parts, lack of fluidity causes the smaller strokes of text to be unrecognizable. A lack of fluid drawing completely kills the presenters desire to use drawing and the audiences desire to listen to the pictures.\n\n### Fluidity of the drawing activity\n\nIn trying to devise a cost-effective, yet fluid, setup I’ve tried all the shortcuts - such as using capacitive touchscreens with a stylus and using web apps as the primary whiteboarding software. Both of these are deal breakers for me because after trying many instances on these two options, they just never work out to have sufficient fluidity. \n\nSo here are the constraints I ended up adopting to make drawing itself very fluid:\n\n* **Use an iOS or Android mobile platform tablet** - as it has the following advantages:\n * Native mobile apps are much, much more fluid than web apps.\n * Many more native software options than there are for laptops.\n * More modular and cheaper hardware in the long run than attempting to gain these capabilities in a laptop or desktop.\n* **Must support active pen technology** - capacitive touchscreens, even with a stylus, don’t cut it. When working rapidly, the smoothing algorithms aren’t very smooth - this makes drawing shapes difficult, but more importantly it makes writing words especially difficult.\n* **Having a stylus that is the correct length and thickness** is important for fluid writing and drawing. The stylus that comes with tablets is frequently not the conventional length or thickness of real pens or pencils.\n\n### Fluidity of integrating the act of drawing into virtual meetings\n\nUsing drawing needs to be easy for the meeting host and for the participants.\n\n* For easy virtual sharing, it helps if the native app also has a collaborative web app that updates quickly as it avoids the complications of joining the tablet to the meeting and sharing from there. \n* This enables other meeting participants to whiteboard on the same virtual whiteboard without specialized hardware.\n* Some systems allow guests to join and whiteboard without having to setup an account.\n\n### Fluidity of availability of whiteboarding across teams\n\nThere are multiple elements of what will ensure fluid whiteboarding is available to everyone for collaborations. A primary one is cost, followed by local device availability of active pen tablet options in international markets. Thankfully, the applications covered later support both iOS and Android which helps in finding affordable and locally available options.\n\n* Cost\n* Mobile apps tend to be more likely to be available for both major mobile operating systems compared to a native desktop-only solution being available on multiple desktop platforms\n* Mobile platform flexibility and global cost and availability compared to pursuing laptops with the same capability\n\n## A working example setup\n\n![](https://about.gitlab.com/images/blogimages/virtualwhiteboarding/whiteboarding-setup-samsung8.jpg)\n\n### Tablet\n\n* My first tablet was a [Samsung Galaxy Tab A 8.0 with Spen (SM-P200)](https://www.amazon.com/gp/product/B07TS2N27S/) that cost me USD $235. It is actually an international edition as the US market does not seem to offer an active pen tablet in the 8” format. In this case, the stylus fits inside the tablet so is really not appropriate for fluid drawing and writing. \n* Since my first purchase, Samsung has come out with a less expensive line of large tablets with active pen technology, so I now also have the [Samsung Galaxy Tab S6 Lite 10.4 inch (SM-P610NZBAXAR)](https://www.amazon.com/SAMSUNG-Android-Included-Speakers-SM-P610NZBAXAR/dp/B086Z3S3MY/), which I obtained for USD $250. While the stylus in this unit is considered more full-sized, the thickness, feel, forefinger button and length all cause me to reach for my after-market stylus for the most fluid experience.\n\n### Stylus\n\n* For a stylus, I use the [STAEDTLER 180 Noris digital classic EMR Stylus](https://www.amazon.com/STAEDTLER-22-1-digital-compatibility-purchase/dp/B0728HBD7F). I find the length, weight, and lack of buttons all helpful in handling drawing and writing smoothly. The color makes it a little less easy to lose. The downsides include that there are very few tablet cases that can accommodate it and that it looks so much like a pencil that someone in your household may accidentally toss it in the regular pen jar. Always be sure to verify stylus compatibility with your device's active pen technology.\n\n### Settings\n\nI almost returned the 10” tablet due to a behavior that a couple settings fixed. Android tablets with no physical buttons put a navigation bar on the bottom part of the screen. I found that I was having my palm be picked up by the Home Screen button, which would close the whiteboarding app. Also, when any of these buttons are activated by the stylus, it is equally disruptive to the flow. For the Navigation Bar settings, I set “Navigation type” to “Swipe gestures” and I enable “Block gestures with S Pen” (Android 12, Samsung OneUI v4.1).\n\n### Collaborative whiteboard options\n\nThere are multiple options for the collaborative whiteboard options - some completely free and paid options that carry enough value-add features to consider it for heavy users.\n\n\n\u003Ctable>\n \u003Ctr>\n \u003Ctd>\n \u003C/td>\n \u003Ctd>\u003Ca href=\"https://www.liveboard.online\">Liveboard Online\u003C/a>\n \u003C/td>\n \u003Ctd>\u003Ca href=\"https://support.google.com/jamboard/answer/7424836?hl=en\">Google Jamboard\u003C/a>\n \u003C/td>\n \u003Ctd>\u003Ca href=\"https://miro.com\">Miro\u003C/a>\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Long Term Usage of Free Tier\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>No - Only 3 Boards\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Native Mobile Apps\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Native Desktop Apps\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Web App (for screen sharing)\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Fluidity Extras\n \u003C/td>\n \u003Ctd>\n \u003C/td>\n \u003Ctd>\n \u003C/td>\n \u003Ctd>Multiple pens on deck\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Pages / Canvas\n \u003C/td>\n \u003Ctd>Pages\n \u003C/td>\n \u003Ctd>Pages\n \u003C/td>\n \u003Ctd>Endless Canvas\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Presentation Mode\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Direct Import From Google Slides\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Shape Recognition from hand drawing\n \u003C/td>\n \u003Ctd>Light Duty\n \u003C/td>\n \u003Ctd>Light Duty\n \u003C/td>\n \u003Ctd>Awesome\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Reusability of Drawing as Formal Technical Diagrams\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>No\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003C/tr>\n \u003Ctr>\n \u003Ctd>Viewers Synchronized To Drawing Location\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Yes\n \u003C/td>\n \u003Ctd>Manual\n \u003C/td>\n \u003C/tr>\n\u003C/table>\n\nSee here for more [GitLab remote work whiteboarding information](/company/culture/all-remote/collaboration-and-whiteboarding/).\n\nPhoto by [Kvalifik](https://unsplash.com/@kvalifik?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/whiteboard?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[4618,9,1097],"solutions architecture",{"slug":4620,"featured":6,"template":698},"whiteboarding-remote-work-superpower","content:en-us:blog:whiteboarding-remote-work-superpower.yml","Whiteboarding Remote Work Superpower","en-us/blog/whiteboarding-remote-work-superpower.yml","en-us/blog/whiteboarding-remote-work-superpower",{"_path":4626,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4627,"content":4632,"config":4637,"_id":4639,"_type":13,"title":4640,"_source":15,"_file":4641,"_stem":4642,"_extension":18},"/en-us/blog/why-devops-collaboration-continues-to-be-important",{"title":4628,"description":4629,"ogTitle":4628,"ogDescription":4629,"noIndex":6,"ogImage":1131,"ogUrl":4630,"ogSiteName":685,"ogType":686,"canonicalUrls":4630,"schema":4631},"Why DevOps collaboration continues to be important","Modern DevOps isn't just about tech adoption and new processes. DevOps collaboration is going to play a key role. Here's why.","https://about.gitlab.com/blog/why-devops-collaboration-continues-to-be-important","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why DevOps collaboration continues to be important\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-10-25\",\n }",{"title":4628,"description":4629,"authors":4633,"heroImage":1131,"date":4634,"body":4635,"category":757,"tags":4636},[846],"2022-10-25","\nIt’s tempting to think the concept of DevOps collaboration is something no one needs to talk about anymore. After all, the methodology has been around for nearly 15 years, is in widespread use, and has clearly proven to be successful at getting safer software out the door faster. Haven’t we figured out DevOps collaboration by now?\n\nThe answer is no, at least according to our [2022 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/) and to industry experts looking at the future of DevOps.\n\nFor starters, dev and ops respondents to our survey told us programming languages and soft skills like collaboration are going to be most important for their careers going forward. DevOps collaboration was the second most important skill for sec pros surveyed. These results were far from a one-off: In our [2020 survey](/images/developer-survey/gitlab-devsecops-2021-survey-results.pdf), dev, sec, and ops were unanimous that “soft skills,” including DevOps collaboration, were the most critical for future careers. In [2021](/images/developer-survey/gitlab-devsecops-2021-survey-results.pdf), sec and ops continued to prioritize DevOps collaboration for the future, while devs opted for AI/ML.\n\nThis year, we asked over 5,000 survey takers what would be most important to their careers, but we didn’t ask *why* it would be so important. A look at some recent thought leadership around DevOps collaboration sheds some light.\n\nAccording to [an article in SDX Central](https://www.sdxcentral.com/articles/analysis/devops-its-about-the-people/2022/07/), pundits think collaboration is “critical for DevOps success” today and in the future. An [article in Tech Beacon](https://techbeacon.com/app-dev-testing/future-devops) goes further, suggesting DevOps will embrace business metrics as a measure of success going forward, and, as such, will require levels of cross-functional collaboration not seen before.\n\nIn other words, as DevOps expands beyond a technology goal (develop software) to a business goal (ensure customer satisfaction or business profitability), more teams will be seated at the table. The more people involved, the more DevOps collaboration will be critical to the future.\n\nWe’d like to know how DevOps collaboration works on _your_ team. Our 12-question survey will take you less than four minutes! [Take the survey!](/blog/take-our-survey-on-collaborative-software-development/)\n",[695,850,9],{"slug":4638,"featured":6,"template":698},"why-devops-collaboration-continues-to-be-important","content:en-us:blog:why-devops-collaboration-continues-to-be-important.yml","Why Devops Collaboration Continues To Be Important","en-us/blog/why-devops-collaboration-continues-to-be-important.yml","en-us/blog/why-devops-collaboration-continues-to-be-important",{"_path":4644,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4645,"content":4651,"config":4656,"_id":4658,"_type":13,"title":4659,"_source":15,"_file":4660,"_stem":4661,"_extension":18},"/en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase",{"title":4646,"description":4647,"ogTitle":4646,"ogDescription":4647,"noIndex":6,"ogImage":4648,"ogUrl":4649,"ogSiteName":685,"ogType":686,"canonicalUrls":4649,"schema":4650},"Why do GitLab designers contribute to the codebase?","This article is not another blog post about whether designers should code. Instead, it's the perspective of a GitLab designer learning to contribute.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679556/Blog/Hero%20Images/insights.png","https://about.gitlab.com/blog/why-do-gitlab-designers-contribute-to-the-codebase","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why do GitLab designers contribute to the codebase?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Austin Regnery\"}],\n \"datePublished\": \"2021-03-17\",\n }",{"title":4646,"description":4647,"authors":4652,"heroImage":4648,"date":1345,"body":4654,"category":716,"tags":4655},[4653],"Austin Regnery","\n\n\n\nWorking with engineering in the past used to feel so foreign to me. I never truly understood all the complexities of collaborative software development, and in full transparency, I still don’t. However, using GitLab has taught me how to contribute to the success of our product.\n\n## We believe everyone can contribute\n\nAt GitLab, one of our [goals](https://about.gitlab.com/company/mission/#goals) is to ensure that everyone can contribute to GitLab the application and the company. To help share this working knowledge, everyone that works at GitLab must add themselves to the [team page](https://about.gitlab.com/company/team/). Conquering this development task can be daunting because there are new terms and lots of steps. However, our [documentation](https://about.gitlab.com/handbook/git-page-update/#12-add-yourself-to-the-team-page) does a great job of helping reduce the barrier of entry.\n\n## Develop shared empathy\n\nI never had access to the codebase in previous product teams because it was far too time-consuming to get a build environment configured on my computer. For GitLab, this is a requirement so that I can review changes before they go to production. During onboarding, I invested a decent amount of time setting up the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/README.md) (gdk) on my computer. It was a challenge, but now I know why getting developers up and running can be incredibly complex. I can even more greatly appreciate the [GitPod integration](https://docs.gitlab.com/ee/integration/gitpod.html), which does all the heavy lifting of setup for you in minutes.\n\n![GitPod + GitLab = Love](https://about.gitlab.com/images/blogimages/why-do-gitlab-designers-contribute-to-the-codebase/teaser-gitlab-gitpod.jpg)\nSource: [GitLab Support for Gitpod is Here](https://www.gitpod.io/blog/gitlab-support/)\n{: .note.text-center}\n\nOnce my setup was ready to go, I was able to jump in. When I started at GitLab there was a [quarterly goal](https://gitlab.com/groups/gitlab-org/-/epics/3914) to migrate our button components to the new front-end we were using. I migrated several buttons, but [the one I am most proud of](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46990) required me to step into an area of GitLab I was completely unfamiliar with. I had to get a niche button to verify that my changes were correct, which required me to learn how to get [Terminal working in the GitLab WebIDE](https://docs.gitlab.com/ee/user/project/web_ide/#interactive-web-terminals-for-the-web-ide). Then, I reached out to other designers and team members to get my [runners](https://docs.gitlab.com/runner/) to function correctly. This helped me understand more complex areas of GitLab better than just reading the documentation. It is one thing to read about something, and a totally different beast to make something work yourself.\n\nThis idea of [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is something we uphold as a sub-value at GitLab. By using GitLab to contribute to GitLab the application and company, we put ourselves in our users’ shoes. If we don’t like something then we are that much more motivated to change it.\n\n## Diversify skill sets\n\nAs a designer, I want to have a functional understanding of the frontend framework I am designing within. Having the basics down allowed me to communicate expectations, minimize assumptions, and ask insightful questions. Working through the initial learning curve has helped me tremendously in the coming months for scoping designs and working alongside engineering.\n\nSometimes rather than just sending a mockup to my engineers, I’ll open a Merge Request to propose a change instead. For example, I could have asked them to update the border color of a table, but I discovered removing an extra CSS class would fix the problem; submitting that change was much faster than creating a mockup and chatting about it asynchronously.\n\nIt's much easier to get input from engineers if you are talking about something specific in the codebase, instead of something more nebulous like border colors. Engineers will have to dig into the codebase to reference what is there, so help save them a step if you can. Discussing an explicit change is actionable, which is why we say [everything starts with a merge request](https://handbook.gitlab.com/handbook/communication/start-with-a-merge-request).\n\n> ### \"It's much easier to get input from engineers if you are talking about something specific in the codebase.\"\n\nDoing smaller and simpler changes made me comfortable trying more complex ideas like [replacing label colors with common names](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50393). Each merge request taught me something new. I learned more about keeping my code formatting clean, writing good commit messages, and how to resolve failing pipelines. All things that contributors to GitLab must learn at some point in time.\n\nAs I learn about the different nuances that come with various pages in GitLab, I rely less on asking questions because I can look them up myself. For example, it is not always visually identifiable in the GitLab UI if a page is coded in HAML or Vue. Before I suggest a change or even start designing in some cases, I look for these differences in the codebase. Touching HAML can be more complicated than working with the Vue components documented in Pajamas.\n\nFor User Research, I can use these small changes for [Short Tests](https://help.usertesting.com/hc/en-us/articles/360055473112-Short-Tests-Beta-) instead of using complex prototypes in Figma. Using research to drive decision-making can help reduce subjective bias for implementing an idea.\n\n![Comparing a change before and after in a Merge Request](https://about.gitlab.com/images/blogimages/why-do-gitlab-designers-contribute-to-the-codebase/before-after.png)\nTesting a live environment can be useful for validating changes - [View Merge Request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51753)\n{: .note.text-center}\n\nNot only can I make more informed design decisions, but I can also contribute ideas that others are excited about. I am actively working on two:\n\n- [Add UX reviewer/maintainer to Danger bot](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51127)\n- [Add a shortcut for collapsible section markdown](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54938)\n\nI started working on both ideas while I was between meetings, and I have continued to progress them along ad-hoc. It has been fun to see some of my ideas make it into GitLab, but I also have a nice collection of [scrapped ideas](https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=closed&author_username=aregnery).\n\n## Conclusion\n\nI have already come a long way from making my first Merge Request at GitLab. I thought I knew the basics of git, but going through this process helped me get my feet wet with more complex development and working in a single repository. I learned about having others review and approve my changes, the magic of seeing checkmarks for all pipelines, and finally, the Merge Request badge turning from Open to Merged.\n\nIf you are interested in learning how I create small merge requests, then watch this walkthrough of my process.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/PnxHQGpFD1w\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n",[1099,1096,1388,9,3709],{"slug":4657,"featured":6,"template":698},"why-do-gitlab-designers-contribute-to-the-codebase","content:en-us:blog:why-do-gitlab-designers-contribute-to-the-codebase.yml","Why Do Gitlab Designers Contribute To The Codebase","en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase.yml","en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase",{"_path":4663,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4664,"content":4670,"config":4676,"_id":4678,"_type":13,"title":4679,"_source":15,"_file":4680,"_stem":4681,"_extension":18},"/en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team",{"title":4665,"description":4666,"ogTitle":4665,"ogDescription":4666,"noIndex":6,"ogImage":4667,"ogUrl":4668,"ogSiteName":685,"ogType":686,"canonicalUrls":4668,"schema":4669},"Why GitLab is the right design collaboration tool for the entire team","Design collaboration in GitLab creates a single source of truth and makes product teams more efficient","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681792/Blog/Hero%20Images/train-station.jpg","https://about.gitlab.com/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why GitLab is the right design collaboration tool for the entire team\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Matthew Nearents\"}],\n \"datePublished\": \"2020-11-30\",\n }",{"title":4665,"description":4666,"authors":4671,"heroImage":4667,"date":4673,"body":4674,"category":716,"tags":4675},[4672],"Matthew Nearents","2020-11-30","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\u003C!-- Intro -->\n\nAs designers, the combination of design and handoff tools in our tool belt often fail to enable the rest of the product team to collaborate efficiently. These tools can also lack integration with the [DevOps tools](/topics/devops/) the developers and product managers use for issue tracking, code reviews, and implementation reviews. Any efficiency we perceive in our handoff toolsets is probably due to habituation and individual familiarity.\n\nIn the early 1900s, the Canfranc International Railway Station was built to spur trade and travel between Spain and France. However, the railway had one major flaw: the difference in rail gauge used by the French and Spanish made it impossible for a train to pass through the station. Travelers and all of their cargo had to be unloaded and transferred to a new train in order to continue the journey. It was a painfully slow process for everyone involved. The station never became profitable and was closed shortly after opening.\n\nI love this metaphor because on one hand the passengers could travel successfully from one country to the other. But on the other hand, the trip was very inefficient and lengthy. In a similar vein, our design handoff tools are much like the railway with its different rail gauges: we can force them to function together successfully, but they fail at creating efficient workflows.\n\n### Multiple sources of truth creates confusion\n\nDesign and handoff tools have improved dramatically in recent years — both in the UI and features — but a good workflow is more than an impressive set of tools. These tools fall short by creating new sources of truth: additional places to find assets, code, and conversations, which in turn forces us to adopt even more tools to integrate them together such as chat, email, kanban boards, and wikis. Let’s look at an example:\n\n- A designer creates a wireframe in Sketch.\n- The design is posted to InVision.\n- The InVision link is posted in Slack to make the team aware of the wireframe.\n- The developers go to InVision and have conversations about the designs.\n- Meanwhile, other conversations are happening in DevOps tools.\n- Decisions in meetings are also being documented in a wiki.\n- Other random conversations are also happening via email.\n![A diagram showing the inefficiency of design collaboration without GitLab](https://about.gitlab.com/images/blogimages/2020-design-management-gitlab/diagram1.jpg){: .shadow}\nAn example flow using a disparate set of collaboration tools.\n{: .note.text-center}\n\nThe problem with multiple sources of truth is it’s almost impossible to piece together the history of a design. If the final deliverable fails to meet client or stakeholder expectations, it’s tough to know what caused the departure. Because conversations are happening in several different places, the evolution of that feature is muddled and results in conflicts and confusion about who was responsible for each decision. Some teams have adopted additional tools to maintain decision logs as a band-aid solution for this problem.\n\nWith all the commotion, incorporating feedback accurately and completely into a design becomes extremely tedious. The multiple sources of truth usually present incompatible information creating a complex web of confusion. Nobody enjoys the embarrassment of presenting a design to stakeholders or executives that lacks the feedback a team promised to incorporate. It makes teams look incompetent. But really they’re just victims of bad processes.\n\nSo what’s the solution to this problem? Abandon these disparate tools and move your designs to GitLab. GitLab believes [Design should be part of the DevOps lifecycle](/blog/is-devops-for-designers/), not separate from it, and handles everything post-Figma or Sketch. This creates a single source of truth with a set of handoff and collaboration tools teams are familiar with. Your toolset can be much smaller, creating efficiency and saving time, training, and money.\n\n### Design collaboration in GitLab\n\nIn GitLab, teams do the majority of their work in [issues](https://docs.gitlab.com/ee/user/project/issues/). Issues are like tickets or stories, and have multiple purposes, from getting down a rough idea before you forget, to spec’ing out fully fledged features, to reporting bugs and everything in between. With GitLab’s Figma and Sketch plugins, anyone can instantly upload designs, diagrams, or basically anything straight to a specific issue. That way, conversations about the design happen in the same issue where the whole team is discussing implementation. When a design is uploaded to an issue, the team will automatically be notified. No need to paste a link in Slack or email.\n\nAdditionally, when developers propose changes to the code, through GitLab’s [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/) feature, [designers will be able to post the relevant designs directly to the merge request](https://gitlab.com/gitlab-org/gitlab/-/issues/281055), with a link back to the original issue. Using the merge request, designers can compare their designs to the implemented code since merge requests often generate [review apps](https://docs.gitlab.com/ee/ci/review_apps/) - a test environment where you can preview coded features without having to configure an environment yourself.\n\n![A diagram showing the efficiency of design collaboration with GitLab](https://about.gitlab.com/images/blogimages/2020-design-management-gitlab/diagram2.jpg){: .shadow}\nAn example workflow using Figma (or Sketch) and GitLab.\n{: .note.text-center}\n\n### A single source of truth For the entire team\n\nTeams are much more efficient when everyone can work within the same tool at the same time throughout the entire process to produce a single source of truth. So, although GitLab can be a little intimidating for a designer at first, having a single source of truth means no more lost feedback or decision juggling acts. Everyone is on the same page and teams can focus less on process and more on building great products.\n\nWe’re constantly working to make GitLab easier, more appealing and more fun for teams to use. The best way to move GitLab in the right direction is to use it and give feedback. GitLab is eager to hear from its customers. So although the individual pieces of GitLab might not look as attractive as InVision or Zeplin, when they come together teams can work efficiently, decisions can be more easily tracked, and our customers enjoy better products because of it.\n\nSo what are you waiting for? [Sign in](https://gitlab.com/users/sign_in) to your GitLab account or [create a new one](https://gitlab.com/users/sign_up). Also, download our [Figma](https://www.figma.com/community/plugin/860845891704482356/GitLab) or [Sketch](https://gitlab.com/gitlab-org/gitlab-sketch-plugin) plugins to start uploading your designs to GitLab.\n\nRelevant links\n- [Figma Plugin Installation Video](https://youtu.be/KR2nuehGtrU)\n- [GitLab Figma Plugin Epic](https://gitlab.com/groups/gitlab-org/-/epics/3449)\n- [Design Management Documentation](https://docs.gitlab.com/ee/user/project/issues/design_management.html)\n- [Category Direction Page](/direction/plan/)\n\n\u003C!-- image: https://unsplash.com/photos/dmH3NWhYTHQ -->\n\nCover image by [Michał Parzuchowski](https://unsplash.com/@mparzuchowski?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/train-station?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[9,1096,1099],{"slug":4677,"featured":6,"template":698},"why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team","content:en-us:blog:why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team.yml","Why Gitlab Is The Right Design Collaboration Tool For The Whole Team","en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team.yml","en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team",{"_path":4683,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4684,"content":4690,"config":4695,"_id":4697,"_type":13,"title":4698,"_source":15,"_file":4699,"_stem":4700,"_extension":18},"/en-us/blog/why-we-use-rails-to-build-gitlab",{"title":4685,"description":4686,"ogTitle":4685,"ogDescription":4686,"noIndex":6,"ogImage":4687,"ogUrl":4688,"ogSiteName":685,"ogType":686,"canonicalUrls":4688,"schema":4689},"Why we use Ruby on Rails to build GitLab","Here's our CEO on GitLab’s inception using Rails, and how challenges are being handled along the way.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668296/Blog/Hero%20Images/gitlab-ruby.jpg","https://about.gitlab.com/blog/why-we-use-rails-to-build-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why we use Ruby on Rails to build GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aricka Flowers\"}],\n \"datePublished\": \"2018-10-29\",\n }",{"title":4685,"description":4686,"authors":4691,"heroImage":4687,"date":4692,"body":4693,"category":300,"tags":4694},[2125],"2018-10-29","\nWhen our Co-founder and Engineering Fellow [Dmitriy Zaporozhets](/company/team/#dzaporozhets) decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time. GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework. GitLab CEO [Sid Sijbrandij](/company/team/#sytses) thinks his co-founder made a good choice:\n\n\"It's worked out really well because the Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality,\" he explained. \"If you look at GitLab, it has an enormous amount of functionality. Software development is very complex and to help with that, we need a lot of functionality and Ruby on Rails is a way to do it. Because there's all these best practices that are on your happy path, it’s also a way to keep the code consistent when you ship something like GitLab. You're kind of guided into doing the right thing.\"\n\n### Depending on useful gems\n\nRuby gems play an integral role in the building of GitLab, with it loading more than a thousand non-unique gems, according to Sid. Calling the Ruby on Rails framework \"very opinionated,\" he thinks it's a strong environment in which to build a complex app like GitLab.\n\n\"There's a great ecosystem around it with gems that can make assumptions about how you're doing things and in that regard, I think the Ruby on Rails ecosystem is still without par,\" he says. \"If you look at our Gemfile, it gives you an indication of how big the tower is of dependencies that we can build on. Ruby on Rails has amazing shoulders to stand on and it would have been much slower to develop GitLab in any other framework.\"\n\n### Overcoming challenges\n\nAll of this is not to say there haven’t been challenges in building GitLab with Ruby on Rails. Performance has been an issue that our developers have made strides to improve in a number of ways, including rewriting code in Go and [using the Vue framework](/blog/why-we-chose-vue/). The latter is being used to rewrite frequently accessed pages, like issues and merge requests, so they load faster, improving user experience.\n\nGo is being used to address other issues affecting load times and reduce memory usage.\n\n\"Ruby was optimized for the developer, not for running it in production,\" says Sid. \"For the things that get hit a lot and have to be very performant or that, for example, have to wait very long on a system IO, we rewrite those in Go … We are still trying to make GitLab use less memory. So, we'll need to enable multithreading. When we developed GitLab that was not common in the Ruby on Rails ecosystem. Now it's more common, but because we now have so much code and so many dependencies, it's going to be a longer path for us to get there. That should help; it won't make it blazingly fast, but at least it will use less memory.\"\n\nAdding Go to GitLab’s toolbox led to the creation of a separate service called [Gitaly](/blog/the-road-to-gitaly-1-0/), which handles all Git requests.\n\n### Building on GitLab’s mission\n\nThe organized, structured style of Ruby on Rails’ framework falls in line with our core mission. Because Rails is streamlined, anyone can jump into GitLab and participate, which made it especially attractive to Sid from the start.\n\n\"[Our mission is that everyone can contribute](/company/mission/#mission),\" he explains. \"Because Ruby on Rails is really opinionated about which pieces go where, it's much easier for new developers to get into the codebase, because you know where people have put stuff. For example, in every kitchen you enter, you never know where the knives and plates are located. But with Ruby on Rails, you enter the kitchen and it's always in the same place, and we want to stick to that.\n\n>In every kitchen you enter, you never know where the knives and plates are located. But with Ruby on Rails, you enter the kitchen and it's always in the same place, and we want to stick to that.\n\n\"I was really encouraged when I opened the project and saw it for the first time a year after Dmitriy started it. I opened it up and it's idiomatic Rails. He followed all the principles. He didn't try to experiment with some kind of fad that he was interested in. He made it into a production application. Dmitriy carefully vetted all the contributions to make sure they stick to those conventions, and that's still the case. I think we have a very nice codebase that allows other people to build on top of it. One of our sub-values is [boring solutions](https://handbook.gitlab.com/handbook/values/#efficiency): don't do anything fancy. This is so that others can build on top it. I think we've done that really well … and we're really thankful that Ruby has been such a stable, ecosystem for us to build on.\"\n\n[Cover image](https://unsplash.com/photos/0y6Y56Pw6DA) by [Elvir K](https://unsplash.com/@elvir) on Unsplash\n{: .note}\n",[9,268,3709,934,2402,2325,912],{"slug":4696,"featured":6,"template":698},"why-we-use-rails-to-build-gitlab","content:en-us:blog:why-we-use-rails-to-build-gitlab.yml","Why We Use Rails To Build Gitlab","en-us/blog/why-we-use-rails-to-build-gitlab.yml","en-us/blog/why-we-use-rails-to-build-gitlab",{"_path":4702,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4703,"content":4709,"config":4714,"_id":4716,"_type":13,"title":4717,"_source":15,"_file":4718,"_stem":4719,"_extension":18},"/en-us/blog/why-your-code-review-process-is-broken-and-how-to-fix-it",{"title":4704,"description":4705,"ogTitle":4704,"ogDescription":4705,"noIndex":6,"ogImage":4706,"ogUrl":4707,"ogSiteName":685,"ogType":686,"canonicalUrls":4707,"schema":4708},"Why your code review process is broken, and how to fix it","What do you do when you follow your code review process, and you’re still rudely greeted by code full of bugs, or a flood of user complaints?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679775/Blog/Hero%20Images/why-your-code-review-process-is-broken-and-how-to-fix-it.jpg","https://about.gitlab.com/blog/why-your-code-review-process-is-broken-and-how-to-fix-it","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why your code review process is broken, and how to fix it\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n \"datePublished\": \"2017-07-25\",\n }",{"title":4704,"description":4705,"authors":4710,"heroImage":4706,"date":4711,"body":4712,"category":910,"tags":4713},[1487],"2017-07-25","\nPeople in every field can relate to the feeling of carefully moving down your checklist, triple-checking your work, and confidently *sending that email*, or *posting that tweet*, or *merging those changes*, only to at some later interval experience unmistakable stomach-sinking at some surprise snafu. That’s why we identify areas with potential for human error and build in review cycles with hopefully explicit steps and goals — like code reviews! So what about when you follow all of those steps and you’re still rudely greeted by code full of bugs, or a flood of user complaints?\n\n\u003C!-- more -->\n\nIn other words, why exactly did your code review process “fail” to deliver what you designed it for? It’s not just overt technical errors we’re looking to avoid; our Discussion Product Manager [Victor Wu](/company/team/#victorwu416) told me that we can think of code review as being ineffective if it results in code being shipped that doesn’t meet business or product goals. In this case, poor code review contributes to the ultimate failure, and may lead the product to snowball over time, becoming harder to fix and add new features. Here are a few scenarios with some thoughts on what might have contributed to the code review breakdown.\n\n### Feature shipped with a lot of defects\n\nThis one is easy to identify, but maybe not always as easy to remediate. What broke in the process that allowed this to happen? It might have something to do with rushed or unrealistic deadlines handed to developers, which we heard in our [Global Developer Survey](https://page.gitlab.com/2016-developer-survey_2016-developer-survey.html) is a major reason code gets shipped before it’s ready. One option here might be to try a cross-functional team, or review the channels available for communication with teammates in a different function than your own — the key to [better deadline-setting](/blog/why-code-is-released-too-early/) is finding ways to develop empathy for other teams’ needs, and that won’t happen if you’re siloed.\n\nIt can be even trickier if the problem arises from within the culture of the dev team itself. There can be a power dynamic and intimidation factor inherent in the review process that could make a more junior reviewer, for example, not stick to their guns when their suggestions are insufficiently addressed. At GitLab, we follow best practices, largely based on the [thoughtbot code review guide](https://github.com/thoughtbot/guides/tree/master/code-review), that are designed to create an effective environment for code reviews.\n\n>There can be a power dynamic and intimidation factor inherent in the review process that could make a more junior reviewer, for example, not stick to their guns when their suggestions are insufficiently addressed\n\nThe guide contains truisms that could apply to any setting where one’s creation might be critiqued by a teammate, like `avoid using terms that could be seen as referring to personal traits`, and `if you don't understand a piece of code, say so. There's a good chance someone else would be confused by it as well` for the reviewer, and `don't take it personally. The review is of the code, not of you` and `be grateful for the reviewer's suggestions` for the reviewee. It’s important to have the right person reviewing, and for everyone to internalize the respect and balance between the reviewee and reviewer roles.\n\n### Feature shipped with poor usability or did not solve the underlying business problem\n\nWhat happened here is likely to do with the [dynamic between the business and engineering teams](/blog/your-engineers-need-to-understand-your-business-heres-why/). Engineers may feel disheartened by business managers who seem solely concerned with functionality. This disregard can be reciprocal, with engineers focusing on delivering quality work but unconcerned with the business and the end users.\n\nIt’s not uncommon for engineers to be excluded from business discussions, until requirements are [thrown over the wall](/blog/your-engineers-need-to-understand-your-business-heres-why/) at them — this lack of alignment creates inefficiencies that can have long-term consequences. Engineers may feel uneasy about the timeline or the product direction, or they may simply feel whatever’s being asked of them is a bad idea. If their organization doesn’t have a channel open for them to discuss their concerns, they might feel they have no choice but to go along with it. Ideally, dev teams today will be heavily involved in business discussions, and they’ll have the responsibilities to match.\n\n>Ideally, dev teams today will be heavily involved in business discussions, and they’ll have the responsibilities to match\n\n### Feature shipped BUT...\n\nIt might be the case that all seems well when a feature ships, but going forward it takes much more time to develop new features, and there are many brittle edge cases. Victor told me that in this case, it’s more likely that the architecture is simply inadequate, and not enough effort was made to clean up tech debt. This is not the opportunistic tradeoff of tech debt and time to market that many startups weigh; it’s when tech debt feels like it’s spiraled out of control. This might be the confluence of the poor dynamics we’ve discussed above, with engineers pressed for time, [burned out and working long hours](https://codewithoutrules.com/2017/06/21/why-company-want-long-hours/), and perhaps feeling unable to push back against business demands.\n\nOn his blog *Code Without Rules*, Itamar Turner-Trauring [explains several possible reasons](https://codewithoutrules.com/2017/06/21/why-company-want-long-hours/) why organizations might have unhappy developers unable to do their best work, and he offers some tips for how individual developers might be able to regain some control over their work lives.\n\nWhat are other scenarios you’ve experienced? Leave a comment and let us know.\n",[9,912],{"slug":4715,"featured":6,"template":698},"why-your-code-review-process-is-broken-and-how-to-fix-it","content:en-us:blog:why-your-code-review-process-is-broken-and-how-to-fix-it.yml","Why Your Code Review Process Is Broken And How To Fix It","en-us/blog/why-your-code-review-process-is-broken-and-how-to-fix-it.yml","en-us/blog/why-your-code-review-process-is-broken-and-how-to-fix-it",{"_path":4721,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4722,"content":4728,"config":4734,"_id":4736,"_type":13,"title":4737,"_source":15,"_file":4738,"_stem":4739,"_extension":18},"/en-us/blog/working-at-gitlab-affects-my-life",{"title":4723,"description":4724,"ogTitle":4723,"ogDescription":4724,"noIndex":6,"ogImage":4725,"ogUrl":4726,"ogSiteName":685,"ogType":686,"canonicalUrls":4726,"schema":4727},"How working at GitLab has changed my view on work and life","A glimpse of the things I've learned at GitLab since I joined.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678678/Blog/Hero%20Images/gitlab-effects.jpg","https://about.gitlab.com/blog/working-at-gitlab-affects-my-life","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How working at GitLab has changed my view on work and life\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Hazel Yang\"}],\n \"datePublished\": \"2018-03-15\",\n }",{"title":4723,"description":4724,"authors":4729,"heroImage":4725,"date":4731,"body":4732,"category":910,"tags":4733},[4730],"Hazel Yang","2018-03-15","\nI will have been at GitLab for two years in June of this year. Working at GitLab is a fresh experience for me. Joining a company outside of Asia and working 100 percent remotely was not something that I had previously done. It not only affects my work but my entire life. I am so grateful to have the opportunity to work with talented and friendly people around the world. I think it would be good to share my reflections about what I’ve learned during this 19-month journey.\n\n\u003C!-- more -->\n\nWe have an open source [handbook](https://handbook.gitlab.com/handbook/) that everyone can access, and it includes our six [values](https://handbook.gitlab.com/handbook/values/), (CREDIT) which support our everyday work. Keeping these values in mind benefits me a lot both in my work and in my life, and I would love to share them with you here:\n\n### Expressing oneself completely, clearly and without reservation\n\nCollaboration is essential in our everyday work. At GitLab, we prefer asynchronous communication instead of synchronous communication since we are spread around the world, from America, Europe, Africa, to Asia. We rely on text-based communication heavily. However, words are cold without the body language support, and they could easily lead to misunderstanding and conflict. So how we express our thoughts clearly and kindly in text becomes crucial.\n\nAfter joining GitLab, I always think twice before sending out messages or comments, even in my personal life. I started to choose my words more carefully both in English and Chinese. I also have tried to explain as much as possible. I found that if I did these two things, I can avoid the misunderstanding and increase the efficiency of communication. The most important thing is that people feel comfortable while discussing with you in the text. So don't be afraid to completely express your thoughts, in a careful and sensitive manner.\n\n### Don't be shy to show your gratitude\n\nWe have [\"Say thanks\"](https://handbook.gitlab.com/handbook/communication/#say-thanks) in our [values](https://handbook.gitlab.com/handbook/values/), and we often say \"Thank you\" to each other, especially in our \"Thanks\" channel on Slack.\n\n{: .text-center}\n![graphic-gratitude](https://about.gitlab.com/images/blogimages/working-at-gitlab/gratitude.png){:height=\"480px\" width=\"680px\"}\n\nDue to my personality and culture, at first I was shy to express my appreciation to my friends, family, and colleagues. At GitLab, we have a unique culture that encourages people to say “thanks,” so I try not to be too shy to show my gratitude. As I practiced this more and more, it became a habit and a natural thing to me. Now I say “thanks” very often, even for little things, and it feels positive and makes me happy every day.\n\nExpressing gratitude not only makes me feel satisfied, it also makes the person that I expressed my appreciation for have a beautiful mood.\n\n### Learning from failure\n\n\"Iteration\" is critical to our product improvement and development. We see what each of us produce initially as a draft. This helps us reduce the cycle time and have a prototyping mindset towards the features we are working on. We are not afraid of failure since we are always flexible in adjusting our products based on the feedback from both our external and internal communities.\n\n{: .text-center}\n![graphic-iterations](https://about.gitlab.com/images/blogimages/working-at-gitlab/iterations.png){:height=\"480px\" width=\"680px\"}\n\nI have applied this mindset to my personal life as well. In my culture, we value the smart person who never makes mistakes. So we try as hard as possible to avoid errors and losing face. However, the prototyping mindset changed my thoughts and reactions towards the things that previously may have made me feel embarrassed or uncomfortable. I became more open-minded in accepting positive and negative feedback from others. I no longer get upset or offended if someone corrects something that I did. I realized that my life is also a kind of product and it will be better and better in every iteration.\n\n### Trust your team and grow with them\n\nWhen you trust your team members, you will be brave enough to leave your comfort zone because you believe they will give you the support whenever you need it.\n\nA good example of trust concerns my English. English is my second language and therefore it is a weakness of mine. When you lack confidence in something, you often refuse to do the things outside of your comfort zone as you fear it would make you look stupid. This was exactly my situation when I joined GitLab. However, when I realized that the people around me weren’t as concerned about my shortcomings in English as much as they valued me for my contributions to the company. It gives me the courage to face my linguistic challenges.\n\nI am still not 100 percent as confident in English as I am in Mandarin, yet my confidence has increased from 30 percent to almost 70 percent if one puts a number to it. As you can see, I am writing this blog post in English to share my experience at GitLab now. This is only my second blog post.\n\nGitLab provides a very positive environment where I can improve and grow professionally as well as personally. I appreciate that my colleagues are always supportive and patient. I feel safe and comfortable while doing challenging things, not just concerning my English but in all of the tasks that I face at GitLab.\n\n### Befriend your manager and colleagues\n\nI felt that it was harder to befriend managers and colleagues at a company in Asia. I am not the sure what the reason is, but I think perhaps it is because of Confucianism which impacts our culture a lot.\n\nAt GitLab, I speak freely about numerous things to my manager, [Sarrah Vesselov](/company/team/#SVesselov), since I know she cares about our team and wants our team to grow. I also feel that GitLab is like a big family even though we are a large and distributed team. We try as hard as we can to get people together in both virtual and practical ways.\n\n{: .text-center}\n![image-summit](https://about.gitlab.com/images/blogimages/working-at-gitlab/summit.png){:height=\"480px\" width=\"680px\"}\n\nFor example, we have the [team call](https://handbook.gitlab.com/handbook/communication/#team-call), and people can share a bit about their lives. We also encourage our team members to join the [\"virtual coffee breaks\"](https://work.qz.com/1147877/remote-work-why-we-put-virtual-coffee-breaks-in-our-company-handbook/) to get to know each other. Moreover, we host a [summit](/events/gitlab-contribute/) to get together in person every nine months. This year we will meet in [Cape Town, South Africa](https://gitlab.com/summits/2018-Summit).\n\n### Embrace diversity\n\nGitLab promotes [diversity](/company/culture/inclusion/) and hires globally. We believe \"Culture add\" much more than \"Culture fit.\" We include different race, color, religion, gender, national origin, age, disability, or genetics. We also support inclusive benefits, for instance, [Transgender Medical Services](/handbook/total-rewards/benefits/general-and-entity-benefits/inc-benefits-us/) and [Pregnancy and Maternity Care](/handbook/total-rewards/benefits/general-and-entity-benefits/#parental-leave). We have a LGBTQ+ channel on Slack as well. Embracing differences powers our creativity.\n\n{: .text-center}\n![graphic-diversity](https://about.gitlab.com/images/blogimages/working-at-gitlab/diversity.png){:height=\"480px\" width=\"680px\"}\n\nWorking with people from diverse backgrounds is fantastic. I have learned from others’ communicative styles and different ways of thinking. I have broadened my views and now see the world from different perspectives. I am much more open-minded. The most important thing is that I completely understand that we are equal regardless of who we are.\n\n## Conclusion\n\nWorking at GitLab is a unique experience for me. I feel excited to start my work every day and enjoy the job I am doing.\n\nFor those that may be interested in working at Gitlab, we are currently hiring people from everywhere. If you want to join the journey, you can check out our [jobs](/jobs/) page and feel free to apply for the position if you feel that you are qualified. We are looking forward to hearing from you!\n",[934,9,737],{"slug":4735,"featured":6,"template":698},"working-at-gitlab-affects-my-life","content:en-us:blog:working-at-gitlab-affects-my-life.yml","Working At Gitlab Affects My Life","en-us/blog/working-at-gitlab-affects-my-life.yml","en-us/blog/working-at-gitlab-affects-my-life",{"_path":4741,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4742,"content":4748,"config":4754,"_id":4756,"_type":13,"title":4757,"_source":15,"_file":4758,"_stem":4759,"_extension":18},"/en-us/blog/zapier-pick-your-brain-interview",{"title":4743,"description":4744,"ogTitle":4743,"ogDescription":4744,"noIndex":6,"ogImage":4745,"ogUrl":4746,"ogSiteName":685,"ogType":686,"canonicalUrls":4746,"schema":4747},"Scaling communication at Zapier","GitLab CEO Sid Sijbrandij sits down with Zapier team members to chat about communication challenges in each growing company.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680279/Blog/Hero%20Images/zapier-pyb-post.jpg","https://about.gitlab.com/blog/zapier-pick-your-brain-interview","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Scaling communication at Zapier\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Noah Manger\"}],\n \"datePublished\": \"2018-01-08\",\n }",{"title":4743,"description":4744,"authors":4749,"heroImage":4745,"date":4751,"body":4752,"category":910,"tags":4753},[4750],"Noah Manger","2018-01-08","\n_On November 17, Mike Knoop and Noah Manger of Zapier [sat down with GitLab’s CEO Sid Sijbrandij](/handbook/eba/ceo-scheduling/#pick-your-brain-meetings) to discuss the way the two companies approach the challenge of scaling communication as a company grows. This transcript has been lightly edited for clarity._\n\n\u003C!-- more -->\n\n**The heartbeat of our organization is our weekly Friday Update posts that everyone at the company writes. The problem is that as we’ve grown, it’s become a tremendous amount of information. We’re really good at generating the firehose of content, but not as good at consuming it. So I’d love to learn what processes you use at GitLab and if you feel like you’ve got a good grip on this problem?**\n\nWe have a #working-on Slack channel but I’m working on killing it because I just don’t care what people in another part of the company are working on. I just don’t care. There are just too many people at 200 people.\n\nWhat works really well for us are the [functional group updates](/handbook/group-conversations/). Every day of the week there’s a presentation (for a maximum of 25 minutes) by a team lead with a slide deck of what they’re working on, and there's an opportunity to ask questions. So you get to stay updated about what all the development teams are doing, what sales is doing, what marketing is doing, what legal is doing, what partnerships is doing. It’s on a three-week rotation so 15 different functional areas and then we start over from the top.\n\n**Do you measure how many people consume this content?**\n\nLive in the call it’s about 50 but it differs on the matter. It’s planned for every single day. We hadn’t scheduled them for a month or two and everyone in the company reported feeling out of touch about where the company was going and what people were working on.\n\nWe are doing asynchronous stand-ups, but it’s just for something that’s a high priority project and there’s a chance of delay that we can’t afford. Right now there are three groups on asynchronous stand-ups that are super high-priority projects and we want to make sure that nobody’s blocked. So someone posts a message saying “Asynchronous stand-up for today” and then everyone posts in the thread what they’re working on and may be blocked on.\n\nNormally we don’t do it and we just work in [GitLab issues](https://docs.gitlab.com/ee/user/project/issues/). When you start working on something you assign your name to it, and so if you want to know what someone is working on you see what issues are assigned to them.\n\n**Why did you choose to do functional updates as videos rather than written?**\n\nIt allows for more interaction. Yesterday my update had three topics and I had a slide for each. People ask questions mostly in the chat feed in Zoom. Sometimes if they have an elaborate question I’ll ask them to explain more verbally. We spend 15-20 minutes on people asking questions. That’s what we want — it’s not typical — but that’s where we want to go. Sometimes people have a lot to present and talk for 20 minutes, but we want to try to split those up and constrain the presenting part to 10 minutes.\n\nAnd if they’re over in 10 or 15 minutes and nobody has any questions, that’s great.\n\nAnd one thing: the presentation slides have to be linked to in the invite before the presentation starts. People have to be able to invest one minute to click through the presentation to see if they need to join the call, or they can just say “This is great and I don’t need to join.” And obviously everything is recorded: it’s put into our Google Drive and you can see everything and the ones that are able to be public will be posted every Friday.\n\n**Is it typical for someone to join every update?**\n\nI join about two thirds of them.\n\n**So if someone were to join every one it’d be a two-and-a-half-hour time commitment every week?**\n\nYeah, but you won’t be asked any questions so you’re able to multitask and zone out if you don’t need to pay attention.\n\n**You’re global, so how do you deal with time zones? Do you rotate it around so other people are able to join?**\n\nYou’re not expected to join at all. These are optional; join them if you want to. But time zones are the bane of our existence. Most of our people are either in Europe or the Americas, so we do this in our most convenient time zones. So our functional updates are at 8am Pacific and our team call is at 8:30am Pacific. There’s been a trend of scheduling meetings over this but we’re trying to prevent that.\n\n**What percentage of content about the company do people consume over video versus writing?**\n\nIt depends. It depends on how they like to consume content. If you’re good with written content, you can get by with the handbook and the presentations. If you like to consume it by listening and hearing people interact, then the video calls are a good way to do it. What’s important is that we make both ways available and then people can do it as they please.\n\n>If you’re good with written content, you can get by with the handbook and the presentations. If you like to consume it by listening and hearing people interact, then the video calls are a good way to do it. What’s important is that we make both ways available and then people can do it as they please.\n\nAnd some people might not care so much! Some people are happy being an open source developer and don’t care about the machinations of a company and that is A-OK. We’re not going to force you to sit through this or check your attendance rate. That is just fine.\n\nBut some people really care and they care about all the aspects. They joined a startup because they want to know what’s happening. For example, when we were doing fundraising we had a fundraising Slack channel and people were asking questions like “What’s the liquidation preference?” And that’s great. If you’re interested we’re not trying to shield you; we don’t want you to get too distracted but it’s there if you want to dive in.\n\n**Do you find people have anxiety around keeping up with information and being concerned they’re not missing things?**\n\nWhat people report is that starting here is overwhelming. The first month is a dark place. We never have people quit during that time but everyone reports that it’s super hard on them. We have one onboarding issue that has about 100 checkboxes you need to check off. And we try to have it all go by what you do on Day 1, Day 2. But it’s very overwhelming. We try to figure out what to cut, but everyone says “No, it’s good to have it all there.” When you first join you have access to the entire map of GitLab so you have to constrain your view.\n\n**Are there other things that you do to help teams know what other teams are doing around the organization?**\n\nWell the [handbook](https://handbook.gitlab.com/handbook/) is really important. That contains all our processes, all the different departments, how they operate, who’s responsible, what Slack channels they’re on, which issue trackers they use; our definitions; our stages in the sales process. Everything should be in there. It’s hard to get right, so it’s a constant focus of my attention. But the idea is if you want to make a change to the company you propose an edit to the handbook, make a merge request, and then if you merge it you announce it. It’s the best handbook in the world; there’s lots of room for improvement, but it’s good and lets you see how lots of different parts of the company operate.\n\nAnd of course we use our own tools. So our customer success team uses an [issue board](https://gitlab.com/gitlab-com/customer-success/sa-service-desk/boards/339477?=) so you can see what they’re doing and what stage it’s in. So we try to use our issue boards and our static websites so you can peer into any part of the company.\n\nOne thing we’re still getting better at is how to expose metrics. We already have a good metrics sheet that’s up to date, consuming all the revenue models and everything we have, but I want that to be a real-time thing that looks a bit prettier and has some better graphs.\n\nAnother thing we do to keep everyone posted is everyone gets the investor update. So every single month, between the 10th and 15th, we send out an investor update about what was good, what was bad, and all our core metrics and everyone in the company gets it.\n\n**Do people find that helpful?**\n\nI think people find it helpful. I believe if you want people to invest in the company you have to treat them like investors – which they are, because they have options. I think what people pay attention to most is runway (months of cash remaining) and what’s bad.\n\n**One thing we’ve heard is that people want a weekly set of highlights of the things that they need to know. Do you do anything like that?**\n\nI’ve never heard that. If your communication is any good, you repeat yourself a lot. I have a #ceo Slack channel, so hopefully what I say there is congruent with what I say in the investor update is congruent with what the leaders in marketing and sales are saying, etc. We’re not trying to make it the same message, but in a perfect world it’d be the same message.\n\n>If your communication is any good, you repeat yourself a lot.\n\nSo no, I’ve never heard the need for a summary. If I ever need to go find what sales was doing two weeks ago, I’d go find their functional update from two weeks ago.\n\n**If I switched to a new product team and I wanted to know what my new team has been working on, what would I do?**\n\nYou’d look at the functional updates. And also you could join the kickoffs and retrospectives, which happen every month and are broadcast live on [YouTube](https://www.youtube.com/c/Gitlab). So that’s another channel you could use.\n\n**At which stage in your growth did you start doing those functional updates?**\n\nI don’t know exactly. About 50 engineers. But it’s also because this is an open source project and people who are contributing to the project but aren’t part of GitLab are wondering what’s in the pipeline and what’s happening.\n\n**Do you have any internal blog or tools that people log into to get information about what the company is up to?**\n\nNo. There’s the handbook, but for regular updates that’s what the functional team updates and issue boards are for.\n\n**Do you feel like there’s things that aren’t shared that should be? Are those functional updates high enough bandwidth or frequent enough to get everything across?**\n\nWith our kickoffs, because they’re live broadcast, some of our product managers would get into presentation mode, like “Everything’s going to be wonderful!” There’s going to be some of that, but I think it could be more measured and raw. In our retrospectives there’s a more of that. People are also used to asking hard questions and getting praised for that. You say things like “Wow, that’s a hard question. That’s the best question we’ve got.”\n\n**If I’m a product manager and I’m about to release something that will affect the product and I don’t have a functional update this week, what’s the best way to do that?**\n\nFor the company, post in the general chat channel that will be consumed by many people and you mention the related people. If you need it externally you could do a blog post, but usually you could just do it in the issue and then tweet it from your personal account and it will be retweeted by GitLab.\n\n**So you depend on Slack for urgent notifications?**\n\nSlack is great for urgency. It’s its downfall as well.\n\n**What have been either pain points or surprises as you’ve gone from 100 to 200 people?**\n\nI think a pain point we’re experiencing right now is our team call. It’s too many people. We try to rotate people now, but after about 150 people, people lost track. And if you lose track you lose interest. So we’re thinking about getting a smaller group of people together, maybe even 7-15, and having them talk every day for a sustained period so you get to know them and then you switch up the groups.\n\nAlso, overuse of @channel mentions is a pet peeve. It’s only allowed if it’s urgent *and* important but people use them if it’s *only* urgent or *only* important. Those should just be posted without an @channel or @here mention. If my Slack always has a constant red thing then I’ll stop paying attention. It’s a tragedy of the commons.\n\n**Do you have any tricks for organizing Slack?**\n\nThere’s a few special channels: #thanks where we call people out for helping that gets about 10 posts a day and that’s one of my favorite channels.\n\nThere’s an #emotional channel where you can just complain about shit. And that’s allowed and encouraged and we give teddy bear emojis back.\n\n**How many channels do you have?**\n\nHundreds. More channels than people.\n\n**How do people navigate that when they join? Do you do anything to help them figure out which channels to join?**\n\nIt’s organic. These people already feel overwhelmed, do you want to give them more channels? It just gets worse. And in the handbook you can see what the channels are for your group.\n\n**Since we’re talking about cross-team collaboration, can you tell us about your summit?**\n\nWe try to do it every nine months and it’s forbidden to organize functional meetings there. So you can’t meet with the just sales or marketing team. Instead we have an '[unconference](https://en.wikipedia.org/wiki/Unconference)' based on the Lobby Conference, that’s built on user-generated content. We have two half days where people propose subjects, people vote on them, and someone kicks things off for five minutes and then a group of 15-20 people discuss it for 50 minutes.\n\nYou know the people in your team already, so we said “Please, please, please meet with other people.” The top two sessions at the last one were on avoiding burnout and how to keep yourself motivated while working at home. I was glad to see people organized sessions like that because we can do the purely job-related stuff at other times.\n\n**Well thanks. This has been really great and has challenged some of our assumptions. We’ve been assuming that we’re generating all this content and we need to figure out what the right curation layer is. But it sounds like you’ve been very successful at reducing the amount of content that’s generated in the first place but forcing it all to go through those channels, which solves the curation problem that way.**\n\n\n## About the guest author\n\nNoah Manger is a product manager, designer and developer, currently leading the Internal Tools team at Zapier. He lives in Portland, Oregon.\n\nCover image by [Alexandr Bormotin](https://unsplash.com/@bormot) on [Unsplash](https://unsplash.com/photos/Hd8b_WtKIck).\n",[3045,1097,9],{"slug":4755,"featured":6,"template":698},"zapier-pick-your-brain-interview","content:en-us:blog:zapier-pick-your-brain-interview.yml","Zapier Pick Your Brain Interview","en-us/blog/zapier-pick-your-brain-interview.yml","en-us/blog/zapier-pick-your-brain-interview",{"_path":4761,"_dir":245,"_draft":6,"_partial":6,"_locale":7,"seo":4762,"content":4768,"config":4774,"_id":4776,"_type":13,"title":4777,"_source":15,"_file":4778,"_stem":4779,"_extension":18},"/en-us/blog/16-ways-to-get-the-most-out-of-software-documentation",{"title":4763,"description":4764,"ogTitle":4763,"ogDescription":4764,"noIndex":6,"ogImage":4765,"ogUrl":4766,"ogSiteName":685,"ogType":686,"canonicalUrls":4766,"schema":4767},"How to get the most out of software documentation","Want to get even more mileage out of your DevOps platform? Better software documentation is the answer. Here are tips to help you get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668339/Blog/Hero%20Images/a-tale-of-two-editors.jpg","https://about.gitlab.com/blog/16-ways-to-get-the-most-out-of-software-documentation","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to get the most out of software documentation\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2022-01-11\",\n }",{"title":4763,"description":4764,"authors":4769,"heroImage":4765,"date":4770,"body":4771,"category":757,"tags":4772},[734],"2022-01-11","\n\nIt’s not a glamorous part of a DevOps platform, but software documentation is easy, sometimes hands-free, and, if done correctly, can help speed up development and deployment. Here are some tips to refresh your software documentation practice.\n\n## Defining documentation\n\nSoftware documentation – which includes everything from manuals to system and design requirements, change lists, code comments, and alert records – is a way to unify efforts between projects and DevOps teams, and to share specialized knowledge and guidance. It’s also a way to standardize practices and benchmark metrics. There’s a direct correlation between creating clear, comprehensive, searchable, up-to-date, and well-organized documents and a DevOps team’s success.\n\nNeed proof? According to the [Accelerate State of DevOps 2021 report](https://gitlab.com/gitlab-com/www-gitlab-com/uploads/069ee8e2ee6af463cf0aafcd89eda33e/state-of-devops-2021.pdf) from DORA, the DevOps Research and Assessment team at Google, DevOps teams with solid documentation practices are 2.4 times more likely to meet or exceed their reliability targets, 3.8 times more likely to implement security practices, and 2.5 times more likely to fully leverage the cloud.\n\nMaking sure you have strong documentation actually is one of the six suggestions the DORA report gave DevOps professionals who [want to become elite team performers](/blog/how-to-make-your-devops-team-elite-performers/).\n\nAs you work on a [DevOps platform](/solutions/devops-platform/) and create new efficiencies and processes, you will want to document them so you can carry them forward. No continually reinventing the wheel for you.\n\n### Tips for creating solid software documentation\n\nSo how do you go about building good documentation? Here are some basic steps to follow:\n\n- You need to decide who is responsible for the documentation. What works best for your team and your organization? Does the project need a [technical writer](/handbook/product/ux/technical-writing/) or can one of your developers handle it? Give one person or just a few people ownership of documentation. You’re more likely to have quality software documentation when someone has clear responsibility and no one can pass the buck. \n\n- Don’t forget about incorporating user experience into your documentation. It will give you a different view on use cases and experiences and enable readers to have their success moment [more quickly](https://docs.gitlab.com/ee/ci/quick_start/). \n\n- Think about the security requirements for your software. For instance, when a project uses network communication over public transport, does it provide secure communication with TLS and/or https? Inform users about [support policies for security releases](https://docs.gitlab.com/ee/policy/maintenance.html), allowing to plan accordingly for upgrades and maintenance windows. Additionally, what measurements do you need to take to make sure it complies with company security policies? Note that information in your documentation.\n\n- Use your documentation to explain technical decisions and share insights into [reference architectures](https://docs.gitlab.com/ee/administration/reference_architectures/). When debugging a problem, it is helpful to learn about the decisions, and also have ‘get help’ and [‘troubleshooting’ sections](https://docs.gitlab.com/ee/ci/troubleshooting.html) in your documentation.\n\n- Provide details about issues you faced with the project and how you worked them out. Make sure the details are explained so that others can easily understand them. Add URLs to issues or epics into your documentation to allow readers to follow, for example the [version history for product features](https://docs.gitlab.com/ee/development/documentation/styleguide/#version-text-in-the-version-history) in the GitLab documentation.\n\n- There should be specific rules about how to change, expand and update documentation. Create [documentation style guides](https://docs.gitlab.com/ee/development/documentation/styleguide/), including requirements, examples, use cases and specifications for writing for a global audience. If changes are made creating inconsistent data formats, it can be more difficult to organize and search documents.\n\n- Don’t just document at the end of a project. It should be done continuously throughout the development and deployment lifecycle – from planning through monitoring and feedback. (We’ll give you more tips about this below.)\n\n- Give people who are responsible for documentation the [training](/handbook/product/ux/technical-writing/fundamentals/) they need in how to collect data, write, organize, and maintain it.\n\n- Make sure the [people responsible for documentation](/handbook/product/ux/technical-writing/#designated-technical-writers) are included in all aspects of the DevOps lifecycle. Bring them into planning, design, and testing meetings. They can’t write about or collect information about what they don’t know is happening.\n\n- Make use of data created by automated processes. (Again, there’s more information on this below.)\n\n- Make sure your documentation isn’t just paraphrasing what the source code flow does. Explain the “why” as well as the use case for the project. Dependending on the size and users, your audiences may differ, and the introduction needs an [overview with different navigation routes](https://docs.gitlab.com/ee/index.html).\n\n- There’s no one right way to handle documentation. What you need for documentation may vary depending on things like the size and nature of your organization, the scope of your software projects, and compliance issues. A hospital or financial institution’s documentation needs might differ from those of a small, private company.\n\n## Continuous software documentation\n\nMuch like there are continuous integration and deployment, there also can be continuous documentation. You can make the automated processes on a DevOps platform do a good chunk of your documentation work by having them capture key information throughout the DevOps lifecycle and funnel it into your documentation stores. Make it part of your development workflow by approaching documentation with a DevOps mindset. Software documentation is easier and more helpful when it’s done continuously.\n\nYou can leverage existing tools to generate, convert and present documentation. GitLab provides an extensive REST API, which allows to [update the wiki](https://docs.gitlab.com/ee/api/wikis.html) programmantically, or modify a Markdown file in the Git repository from your CI/CD pipelines. If you want to present the documentation on a website, you can use [MkDocs](https://www.mkdocs.org/) to generate a static documentation website [served with GitLab Pages](https://gitlab.com/pages/mkdocs) for example. Code documentation with [Doxygen](https://www.doxygen.nl/manual/docblocks.html) can be generated in the same way as a [website reference documentation](https://gitlab.com/pages/doxygen). \n\n### Tips to make documentation easier and more continuous\n\n- The DevOps platform’s automated systems, which govern processes and monitor everything from system to software configurations, generate logs that can create a real-time, ongoing stream of documentation.\n\n- Scripts and configuration files that control automated processes, like testing, hold important configuration data that can be fed into documentation.\n\n- Issue and alert logs, which generally contain information about problems, can be automatically documented. \n\n- Integrated [Observability](/direction/monitor/) keeps track of performance and availability of the software and also can add to documentation by providing access to metrics, traces and log dashboards and panels. \n\nThese are just a few ways to automatically feed your continuous documentation operation. Sure, there are forms of documentation that will need some hands-on, but there are a lot that can be generated as part of the ongoing process. The data is there, so make good use of it.\n\n“Good documentation is foundational for successfully implementing DevOps capabilities,” the DORA report noted. “Teams with high quality documentation are better able to implement technical practices and perform better as a whole… From security to testing, documentation is a key way to share specialized knowledge and guidance both between these specialized sub-teams and with the wider team.” \n\n_[Michael Friedrich](/company/team/#dnsmichi), Senior Developer Evangelist, contributed to this blog post._\n",[4773,912,9],"DevOps platform",{"slug":4775,"featured":6,"template":698},"16-ways-to-get-the-most-out-of-software-documentation","content:en-us:blog:16-ways-to-get-the-most-out-of-software-documentation.yml","16 Ways To Get The Most Out Of Software Documentation","en-us/blog/16-ways-to-get-the-most-out-of-software-documentation.yml","en-us/blog/16-ways-to-get-the-most-out-of-software-documentation",24,[678,703,724,745,766,794,815,836,857],1758326238106]